Guest pre-boot check cycle of .vmdks with raw disks does not detect mismatch in drive geometry

[Daniel Smedegaard Buus]

Hi! :)

I asked a question about this on the forums (​http://forums.virtualbox.org/viewtopic.php?f=6&t=38285&start=0), and then did some testing to try to satisfy my concerns.

Issue at hand: If I have set up my VBox guest on a Windows host to access disks using raw device .vmdks, what will happen when I add a new controller, change BIOS drive order, remove a drive, or similar, which would cause Windows' \.\PhysicalDriveX links to point to physical devices different to what has been described in the .vmdks. E.g. that a 2TB physical disk is referenced to by a .vmdk describing the geometries of the 1TB disk that used to be at that PhysicalDriveX path.

<Copy/paste from my post in the forums> First test: I picked out two .vmdks, one pointing at a 1TB drive, the other pointing at a 2TB drive. I then switched them around, i.e. renamed them.

The "Storage" list in the main manager window did not pick up on this change. It still listed the "old" settings, i.e. the sizes for the previously corresponding \.\PhysicalDrive targets. However, upon booting, the OS report I/O errors on the drives in question.

This suggests that VB kept the geometry info from when the drives were attached, but read in the new \.\PhysicalDrive paths. Not good. Had I set up md and zfs already, I'm guessing this would not have been good for my data.

Second test: I edited the two .vmdks to switch around physical drives.

Again, there's no update in sizes in the "Storage" list, and again, booting results in "Buffer I/O error" messages in logs and TTYs. No warning from VB. </Copy/paste from my post in the forums>

With these raw disk .vmdks, VBox is spending quite a bit of time doing its checks before booting a VM the first time. I believe this time should also be spent comparing the geometries registered in the .vmdk with the actual, current, geometries of each drive, and when finding a mismatch either aborting (seems sane) the process with an error, or at least warning the user and blocking the boot until the user has determined what to do.

The way it works now, a broken power line to a drive could cause complete reordering of a list of drives upon reboot (possibly initiated automatically by the BIOS subsequent to a crash on behalf of the failing drive). If the VM is set to automatically boot, and ignores the discrepancies in geometries, you might find yourself starting RAID systems or ZFS pools on drives that have bad geometries and will I/O error out on everything, possibly causing severe data corruption.