Concern about \\.\PhysicalDriveX paths for raw disk .vdmk
Posted: 20. Jan 2011, 22:52
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
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