a virtual machine on dual boot systen

This is for discussing general topics about how to use VirtualBox.
Post Reply
rsperduta
Posts: 7
Joined: 8. Aug 2009, 02:09
Primary OS: MS Windows XP
VBox Version: OSE other
Guest OSses: Windows XP & Ubuntu

a virtual machine on dual boot systen

Post by rsperduta »

I have a dual boot Windows8/LinuxMint system.

I find virtual box very useful for running a set of tools like libreoffice in a consistent environment with the necessary printer drivers etcetera, but after I had used the same virtual machine under both Linux and Windows I had a corrupted virtual disk.

Is using the same virtual machine on different host operating systems and different hardware supported and if so, are there recommendations of things I should or should not do?
mpack
Site Moderator
Posts: 39134
Joined: 4. Sep 2008, 17:09
Primary OS: MS Windows 10
VBox Version: VirtualBox+Oracle ExtPack
Guest OSses: Mostly XP

Re: a virtual machine on dual boot systen

Post by mpack »

I don't know about "supported", but I can't think of any fundamental reason why it shouldn't work.

Without knowing the nature of the "corruption" then it's hard to say what your exact problem was. To work on different host OS there would have to be two different VMs (*) sharing a common disk. That should be fine provided you absolutely avoid the use of snapshots (the disaster scenario would be one of the VMs directly accessing the VDI, the other VM using the same VDI as the base of a snapshot chain).

There has also been incidences of disk corruption with Linux hosts in the past, to do with disk cacheing, hence the ability to turn host I/O cache off in the VM Storage settings.

(*) You couldn't use the same .vbox file because Linux and Windows use different path names in the media registry, and different names for host devices.
rsperduta
Posts: 7
Joined: 8. Aug 2009, 02:09
Primary OS: MS Windows XP
VBox Version: OSE other
Guest OSses: Windows XP & Ubuntu

Re: a virtual machine on dual boot systen

Post by rsperduta »

mpack wrote:I don't know about "supported", but I can't think of any fundamental reason why it shouldn't work.

Without knowing the nature of the "corruption" then it's hard to say what your exact problem was. To work on different host OS there would have to be two different VMs (*) sharing a common disk. That should be fine provided you absolutely avoid the use of snapshots (the disaster scenario would be one of the VMs directly accessing the VDI, the other VM using the same VDI as the base of a snapshot chain).

There has also been incidences of disk corruption with Linux hosts in the past, to do with disk cacheing, hence the ability to turn host I/O cache off in the VM Storage settings.

(*) You couldn't use the same .vbox file because Linux and Windows use different path names in the media registry, and different names for host devices.
Thank you for your reply. :)

In deed the paths was a problem, especially where I had shared folders and .iso images attached, so what I did was to copy the .vbox file: one to the Linux and one to the Windows system and both referring to the same .vmdk

All I know is that the 'grain table' was corrupted and the disk unusable. I will turn off host I/O caching because I think that may have been the problem: I'm not sure I closed the virtual machine properly and may have just powered it off. Then the snap shot would not restore... but I see what you mean about differencing snapshots if I have the same virtual drive referred to by more than one machine - even if they are on different host OSes used at different times: They will get out of sink and so my duplicate .vbox files is a definite no-no :oops:

- Something for the wish list of virtual box might be to use environment variables to set a root path for these files folders as it would also help when importing appliances made on a different system by someone else and let different users have different settings.
- Something for the Linux wish list might be support for drive identifiers... I personally really do like knowing which file system stuff resides on... but I doubt that will ever happen. :wink:
Post Reply