Use same VM from different host OSes?

[mpack]

Do you actually have a link which details "the specs"?

That would be the user manual.

The definition of a bug is a claimed feature which does not work as described. You'll find all feature descriptions in the user manual.

[socratis]

I think in today's multifaceted world it is entirely to be expected that some people might want to develop a desire to share VMs between hosts.

Absolutely, by all means. The same although could be told for a USB device or a HDD (and I mean in physical form). Problem is they were not designed to do that, that is "to be shared".

The need for such a "feature" is completely understood. But unless it becomes a priority big enough, in order to mandate a rewrite of the whole core VirtualBox "philosophy" that allows safe and intrinsic use of a VM between shared hosts, all the efforts are going to be "hacks".

Which I also use, I simply don't expect it to be "supported"...

[jonha]

Do you actually have a link which details "the specs"?

That would be the user manual.

I see.

If a user manual passes as a specification these days then we are not talking about the same thing and belabouring this point would be flogging a dead horse.

For me, a specification is something like a BNF for a programming language or a similar, complete and exact but concise definition of a complex system. My bad.

[socratis]

You're overthinking it. A specification usually talks about things that are included, not things that are excluded. And if the manual or any other documentation doesn't specifically say "supports multi-user access, here's how" or "supports multi-computer sharing, here's how", you can safely assume that it does neither of those.

[mpack]

No. A specification primarily talks about what you want software to do in the future. A manual talks about what it actually does right now.

A specification is not typically seen by a user. The user manual is what tells a user what is and isn't supposed to happen.

I have been a full time professional software developer since 1980. I do know whereof I speak.

[jonha]

First, all this brouhaha comes about because Socratis used the word "spec" instead of "user manual" in another post, raising hopes that there might be an actual document detailing the... well, the specs. It is now clear this was a misnomer or a misunderstanding.

No. A specification primarily talks about what you want software to do in the future.

I disagree, as that's only one possibility among many. However, this is a dead horse and further discussions will only bloat the thread.

I have been a full time professional software developer since 1980. I do know whereof I speak.

So what? One can do a thing for a lifetime and still do it in incorrect ways (I am in no way implying you do as I know nothing about that. I am just highlighting that such a statement in itself is utterly spurious). Take Intel: I am pretty sure that some hardware engineers are working there since 1980... look at the mess they've produced over decades.

If I look at the general state of IT hardware and software, I am almost ashamed to admit that I once wrote software for a living.

[mpack]

The fact remains that a specification is a design document for developers, not a contract for users.

I mentioned my employment history as a guide, I made no claim that it made me infallable, I do however expect that it puts my comments in a certain context. If you really want to judge my competence then you are free to work your way through my 25000+ previous posts. Apparantly your only claim of comparable understanding is that you once failed to cut it as a coder, for which you somehow fault the whole IT industry?? In that case I admit to feeling a quiet confidence should we ever have a battle of CVs for some employer.

[jonha]

Not gonna happen, I'm sort of a pensioner these days, after decades in software development (FWIW I did write my first assembler programme for a 6502, a machine called KIM-1).

As to the performance of the IT industry... just watch into what a great mess the Meltdown/Spectre set of bugs is blossoming, both on the hard and soft sides. Or the way security has almost always played second fiddle to other design choices. How most (all?) big IT companies consistently ignore their users, to further their own agenda.

IT is (mostly) rotten and I stand by that statement.

But before I get my knickers in a twist, BFN.

[arQon]

Not to disagree with socratis too much, but I think this isn't the best way to handle this case. Rather than copy the .vbox file and then putz around with it on the second host, I'd advise simply creating the "MACHINE" anew on each host, and just pointing the machines at a common VDI. That way you don't have to worry about any potential "obscure" settings being significantly sub-optimal for any given host and you missing them when you try to migrate the .vbox files around.

[socratis]

Oh, it's not a matter of disagreement at all, it's more a matter of "taste", either works. In the first case (existing recipe) you've got to correct what's incorrect. In the second case (recipe from scratch) you got to make sure that you got the details right. Either, or...

If you're going for the new recipe, a quick and dirty trick would be to compare the output of "VBoxManage showvminfo <1>" and "VBoxManage showvminfo <2>" with a text editor that can do diff.

[arQon]

Yeah - either will get there in the end, and I doubt there's any significant difference in effort really.

One thing I remembered later and should have mentioned before is that while a Linux VM will basically Just Work no matter what; if you're moving a *Windows* VM around like this I expect you'd want to make sure you've got the same "devices" for all the configurations, or it'll probably want to reinstall drivers and reboot etc every time you move it across hosts. So for those, I probably WOULD start with the original vbox file after all, just to save keeping track of them myself. I'd also favor NAT over Bridged for the same reason. (Disclaimer: I don't have any "modern" Windows VMs, so maybe it's gotten better about hardware changes over the last few years).

I can say that I've been moving Linux VMs between Windows and Linux hosts for many years now without any problems, so that scenario at least is certainly workable, regardless of which approach you take.

[socratis]

if you're moving a *Windows* VM around like this I expect you'd want to make sure you've got the same "devices" for all the configurations, or it'll probably want to reinstall drivers and reboot etc every time you move it across hosts.

What devices are you referring to? I move/copy/run my VMs between my Mac and my oldie Win hosts all the time, with no changes in the devices at all. The host devices don't matter; the guest is host-device agnostic...

[arQon]

I mean that e.g. if the config file on one of the hosts has the network card as PCnet and another host has it as Intel, etc.

[socratis]

If you're "moving" a VM, the devices don't change because they feel like it. That could happen in your other scenario that you proposed, where you create a new VM around the VDI. That's why my personal favorite is the "move, correct" rather than "create from scratch".

[Brutalizer]

A question. I have tried out WMware workstation Pro 14.1 a while, for the correct DX10 implementation, and gaming works mostly fine. However, I have some unstability problems using Ubuntu LTS 16.04.4 and also there is no seamless mode in WMware, so I am reverting back to Solaris + VirtualBox. So I have a question now about using same VM on different host OSes.

In WMware Workstation, I have installed Guest Additions in Windows7 VM together with Ubuntu as host. And when I reboot into Win10 as host and using the same Win7 VM - I had to reinstall GA because I changed host OS from Ubuntu to Win10. So each time I reboot into another host OS, I have to reinstall GA. How is this solved in VB? Do I need to reinstall GA when rebooting into another host OS?