Switch from WinHost/LinuxGuest to LinuxHost/WinGuest

[jonha]

I have long used VBox under Win7Pro64 as the host for various Linuxes on three separate machines. I am now getting to the point to reverse this setup. The plan is to install a slim 64-bit Linux (Arch?), install 64-bit VBox and then move an existing 32-bit Win7 install into VBox. (I am even toying with the idea to install the much smaller WinXP as guest since the guest system will have no exposure to the internet... the programs running on the guest do not require net access. And the long-term plan is to move away from Win* anyway.)

Whatever, I assume this should be pretty straightforward.

One problem is that on two machines I have relatively big amounts of data (photos, video clips etc. to the tune of 100s of GB) that will have to be shared between the host (ie Linux) and the guest (Win7 or WinXP). I see two ways here:

• a. via shared folders
  b. via raw access to one or more HD partitions

I am not very clear about the relative merits or otherwise of these two approaches. There may even be other, better ways to achieve that.
(And an additional question, if I go down route b., is what filesystem to use for the raw HD partition(s). Windows can't read ext* out of the box but I have a driver that does that (though I am not sure this works reliable). OTOH, Linux can read NTFS. So I am tempted to format this partition as NTFS.)

Thoughts?

[Brutalizer]

If you are going to share files, why not samba/cifs as a network drive? I am using raw access and it works fine, but very slow. I get ~25MB/sec write speed under Solaris 11.2 as host, and Win7 as guest.

[jonha]

What is the advantage of Samba/CIFS over shared folders?

I was always under the impression that raw access is the fastest, if perhaps not most secure, way of accessing a partition?

[scottgus1]

If I recall right, raw disk access takes the partition away from the host and puts it in the guest. So you'd not be able to have both OS's accessing the data at the same time. Additionally, raw disk access is reported by forum gurus to be an experts-only feature, and is very easy to use wrong and destroy data.

If you want both OS's to get to the data and don't want to risk data loss with unusual setups, real shared folders is the way to go.

[mpack]

I was always under the impression that raw access is the fastest, ... , way of accessing a partition?

Why would anyone think that bypassing host OS file caching might give you faster disk access?

In any case what Scottgus mentioned is correct. Operating systems don't expect non-shared filesystems to in fact be shared, meaning there will be no synchronization of updates and you can expect complete and total corruption of the disk contents. I guess that would qualify as the biggest downside of this approach. In any case raw disk access only possible if the disk is unmounted from the host OS and all other VMs, and hence is quite useless for sharing files.

Raw access is for very specialized circumstances only, e.g. a filesystem that the host OS doesn't recognize and therefore can't mount and share. Otherwise you should use shared folders. Best performance will probably come from using a true network share (not GA shared folders), on a VirtIO-net network connection.

[jonha]

Why would anyone think that bypassing host OS file caching might give you faster disk access?

Well, people think the weirdest things. Strange but true.

In any case what Scottgus mentioned is correct. Operating systems don't expect non-shared filesystems to in fact be shared, meaning there will be no synchronization of updates and you can expect complete and total corruption of the disk contents. I guess that would qualify as the biggest downside of this approach. In any case raw disk access only possible if the disk is unmounted from the host OS and all other VMs, and hence is quite useless for sharing files.

Understood. I have so far used raw access only for testing a WinPE install in a VM. For the setup I have in mind this is obviously a big no-no.

Otherwise you should use shared folders. Best performance will probably come from using a true network share (not GA shared folders), on a VirtIO-net network connection.

I just did a quick test (WinHost and WinGuest) and for copying large files (1gb+) a shared folder seemed to be faster (around 25%) than a network share. If this is similar with a Linux host I'll probably stick with shared folders. I will further investigate.

Thanks for the input so far.

[Perryg]

I might mention that what ever the host uses as a format will always be the fastest, due to translation overhead.

Ext4 to Ext4 I get around 250MB/sec but if I go Ext4 to NTFS I can only get about 100MB. (RAW of course ) but I don't mount a RAW partition that have an OS on it. Much better to partition out a local storage and safer too.

[FrederikB]

I've used raw disks in my (one) LinuxVM guest on (one) Windows host for a number of years and it works really fine (well actually up to the Win10upgrade the other day, when VBox suddenly couldn't handle anymore) - I just felt Linux was more appropriate for handling 7TB of data. I started using Linux in the days that Samba was 5x faster than WinXP networking. But indeed each raw disk is assigned to only one (could be disk:OS as n:1 of course) OS. The beauty of ext4 is that Win doesn't even bother looking into those disks / partitions. However multiple VMs trying to access the same raw disk (1:n) is asking for a lot of trouble. Using raw disk in Vbox is not really difficult, dive into 'vboxmanage create rawdisk', the only catch is that Windows assigns the disk order not always in the same way, depending on the way you boot. Usually if the physical disk definitions are done wrong then the Vbox graphical UI will display an error since either the UUIDs don't match or at least after booting you'll see the problems. So I'd say rawdisk is really OK but indeed, never let more than one OS of whatever physical or virtual nature access the same disk. But now you consider Linux as host, just mount your current ext or ntfs disks (of course that's also raw disk access, but then now directly controlled by Linux alone) and happily serve them with Samba to your whatever Windows guests. Looks like a fine setup.

[mpack]

Usually if the physical disk definitions are done wrong then the Vbox graphical UI will display an error since either the UUIDs don't match

The UUIDs are embedded in the VMDK descriptor, not the physical disk, so that can't be true. If a Windows host juggles the drive letters as it is wont to do, then in the best case the VM will fail to boot and that will be that. However in the worst case the VM will mount the wrong host drive or partition and get far enough into the boot to destroy the contents of the wrong disk.

Seriously, people who don't thoroughly understand filesystems and virtual disk formats - and the consequences of getting things wrong - should not IMHO be using raw disk access. So lets say the assumptions are correct that VDI is 10% slower. So what? That's a 1000% better that full speed access to corrupted data.