Concern about \\.\PhysicalDriveX paths for raw disk .vdmk

[DanielSmedegaardBuus]

Hi!

First post here. Just gave up on VMware Server, as it is unable to use my ICH10R connected drives as raw disks or scsi pass-through devices, and now I'm astonished at how great VirtualBox has gotten with the new version 4.

I'm attaching 12 drives as raw devices. I can't get my ICH10R drives to work on the SATA controller, but they work on SCSI controllers, and even if the speed is <30% of that when they're connected to IDE, this is a huge win when compared to VMware which doesn't want to interact at all -not even as IDE devices, this just throws errors in my Ubuntu guest OS.

ANYWAY! My concern is with the .vmdk files and how they associate a physical path to a raw device for VBox. I see nothing in the .vmdk that uniquely identifies a hardware component by uuid or anything similar. Like you'd do in Linux through /dev/disk/by-uuid/... I.e., something that takes into account that paths have a gruesome tendency over time to lead to something new. Like when you add a new drive, you edit you boot order in the BIOS, you move controllers around, etc.

My worries are about this happening in the host (Windows XP x64). Something I'd do, like add new hardware or switch around SATA cables, would cause \\.\PhysicalDrive2 to no longer be my 2TB Seagate SATA, but my 320 GB WD ATA, but VBox would use the same .vmdk indiscriminately, with the same "virtual hardware" settings, and somehow cause havoc when the guest boots.

There's no problem with drives being out-of-order, as all of the raw devices I'm using are recognized by partition ids inside the guest, I'm just worried about what would happen if a .vmdk that was referring to, and describing the geometries of, a ½TB drive, suddenly points to a 2TB drive on the host. The uuid would stay the same, but the parameters in the .vmdk for accessing it would be wrong.

What would happen? Would VBox recognize this discrepancy before booting and throw a "mismatch" error, or would it continue, leaving the fate to the guest?

Thanks in advance,
Daniel

[DanielSmedegaardBuus]

Okay, so I just tested this.

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.

One thing that puzzles me is what's going on when you're waiting for (Normal, Checking...) to complete in the manager window. I would expect that "checking" would involve matching the geometry in the .vmdk with the actual geometry of the drive, among other things.

Gonna report this as a bug.