can vBox be a shared resource?

[bad sector]

I just installed w10 in a Tumbleweed vBox, all the files going to a data
drive under .../vBoxes/w10p. To have the same access to this virtual
windows from Slowroll or from Devuan for example, do I just point
VirtualBox to that same directory? Will this cause issues if the vBox
version in those distros is different?

[Grant Taylor]

I don't know. But if you don't have anything to loose (or have a backup
of the vBox files), I'd definitely give it a try.

I'd create things in the oldest vBox version and open them in the newer
versions. This is to make sure that you don't accidentally create
something using a feature in a newer version that an older version can't
use.

That being said, I doubt there are many things that would qualify like this.

I think it should work.

Try it and find out.



--
Grant. . . .

[bad sector]

I had it installed and running a w10 under Suse Tumbleweed, convinced
that once installed the w10.iso file was no longer be needed. So I also
installed vBox under AvLinux, pointed it to the same folder and the only
thing needed was to place the w10.iso file back where I had removed it
from. It now works. Tried slpkg to install it to Slackware with similar
intentions but got

"No such package virtualbox-kernel-6.1.44: Can't build"

--
Life's just like toilet paper, the closer to the end the faster it unrolls.

[Paul]

Dependency at bottom of page.

https://slackbuilds.org/repository/15.0/system/virtualbox/

https://slackbuilds.org/repository/15.0/system/virtualbox-kernel/

There are materials for download, near the bottom of the page.

Paul

[J.O. Aho]

I wouldn't do this, virtualbox can be iffy with a bad matching virtual
guest addition.

--
//Aho

[Grant Taylor]

On 2/4/24 10:11, J.O. Aho wrote:
> I wouldn't do this, virtualbox can be iffy with a bad matching virtual
> guest addition.

There is some concern about this.

But I think that you're fairly safe if you install and use the add-ons
from the oldest of the hosting virtual box instances.

Every VirtualBox, et al., that I've ever used would happily use guest
additions from an older version of VirtualBox. It might encourage you
to upgrade them, but that's a different annoyance.

[J.O. Aho]

On 04/02/2024 21.42, Grant Taylor wrote:
> On 2/4/24 10:11, J.O. Aho wrote:
>> I wouldn't do this, virtualbox can be iffy with a bad matching virtual
>> guest addition.
>
> There is some concern about this.
>
> But I think that you're fairly safe if you install and use the add-ons
> from the oldest of the hosting virtual box instances.

There can be things that breaks in this case too, copy'n'paste between
host/client has many times stopped working when having older guest
add-on and also the shared folders can stop working on those with newer
virtualbox version.

> Every VirtualBox, et al., that I've ever used would happily use guest
> additions from an older version of VirtualBox.  It might encourage you
> to upgrade them, but that's a different annoyance.

I tend to use virtualbox only for testing stuff, kvm för instances I
want more seriously run as I can then give dedicated graphics cards.

--
//Aho

[Paul]

Don't mix major versions.

Don't run a V6-prepared VM with 6.1.44 additions, in a V5 VirtualBox.
The graphics model is different. V5 has one choice. V6 has three choices.

A VBox with 6.1.38 Additions may receive a warning when run on a 6.1.44 Virtualbox.

Working with Appliances (.OVA) is also littered with hazards
too numerous to mention. Just because you Exported a VM to an OVA,
does not mean a damn thing :-)

This is like herding turtles. All the turtles will try to install the
version of VirtualBox they want to install, you'll be wanting to do
something else. Like, say you had six boot OSes, all with various
package managers. Would you be able to lock all the versions
and avoid trouble ? You'd need to be a very patient Wizard to do that.

And in your container, *never* put unnecessary materials. In one other
group a few days ago, someone is telling me they've done a P2V
on a 2TB drive. Don't do that! The maintenance downsides are infinite.
A dynamic container between 10GB and 20GB, is where you want to be.
Absolutely, there are cases where more support materials end up in
the container, but then the work done in the container was never
that practical in the first place. A VM is not suited to every use case.

Paul

[Grant Taylor]

On 2/4/24 15:11, J.O. Aho wrote:
> There can be things that breaks in this case too, copy'n'paste between
> host/client has many times stopped working when having older guest
> add-on and also the shared folders can stop working on those with newer
> virtualbox version.

There's always a possibility of something breaking.

Aside: I've never found copy and paste between host and guest to be
reliable even with a single host OS.

> I tend to use virtualbox only for testing stuff, kvm för instances I
> want more seriously run as I can then give dedicated graphics cards.

I too have viewed VirtualBox as a wonderful labing / experimenting
resource and used other options for production.

That being said, I did run VirtualBox and PHP VirtualBox web interface
for a while. I ended up switching to VMware because I thought it's
VMware Remote Console to be better for my use case (at the time). -- I
think it was a combination of a slightly better user experience and much
easier administration wherein I didn't need to bother with VNC server
port reservation for highly dynamic guest inventory. -- I question if
I might change that decision the next time I need to tangle with licenses.

[bad sector]

Just as well, with all the warnings received I think I'll just forget
this one. The vBox package itself is an almost unique version in every
installed distro, I can just as easily set up a dedicated w10 in each.