How to use UUID for Physical Drives When Bypassing Host: VMWare Workstation on Win7

[claytontstanley]

Can an expert here answer this question?

How to use UUID for Physical Drives When Bypassing Host: VMWare Workstation on Win7

Much appreciated for the help. This is the last configuration issue I'm having with VMWare Workstion 8.

Thanks!

-Clayton

[continuum]

Hi
AFAIK that is not possible
in ws8 the line in the vmdk that references the physical device looks like

RW 1953525168 FLAT "\\.\PhysicalDrive0" 0 partitionUUID \\?\ide#diskwdc_wd1002fbys-02a6b0___________________03.00c06#4&1f15beb7&0&0.0.0#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}

the blue part can be skipped but AFAIK the red part is required

[claytontstanley]

The blue part looks like partition information (partition UUID). So there isn't a drive UUID that can replace the drive #?

[WoodyZ]

AFAIK that is not possible

in ws8 the line in the vmdk that references the physical device looks like

RW 1953525168 FLAT "\\.\PhysicalDrive0" 0 partitionUUID \\?\ide#diskwdc_wd1002fbys-02a6b0___________________03.00c06#4&1f15beb7&0&0.0.0#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}

the blue part can be skipped but AFAIK the red part is required

FWIW The red part is required however at least under VMware Fusion if the part in red changes on the Host the part in blue is supposed to adjust for the fact the position changed.  I'd assume the same should hold true for VMware Workstation however I haven't tested it although I am curious to know if it does work like it does in VMware Fusion.

[claytontstanley]

The blue part isn't listed in my vmdk files. I can change the red area, and that does have a direct effect on the mapping in VMWare Workstation to the physical drives on the system. I have to do this after every reboot of Windows 7; to fix the fact that the drive order is scrambled after each reboot. Very annoying, and very dangerous, since the physical drives are mapped to two different clusters of RAID arrays.

Which is why I'm posting here; hoping that VMWare Workstation has a way to handle this, without me having to edit vmdk files by hand.

[continuum]

why does the drive order change in your machine ?

do you boot via grub4dos ?

dont you get the blue part if you create a new descriptor ?
do you use Workstation 8 or 7 ?

@ WoodyZ
the way I understand the new behaviour the blue part was added to make sure that if the drive order has changed the VM will not start.

[WoodyZ]

@ WoodyZ
the way I understand the new behaviour the blue part was added to make sure that if the drive order has changed the VM will not start.

Okay I just tested this under OS X and it does now put up an error message where in the past it hadn't.  It would try to initialize the disk as a Boot Camp partition if it was a FAT32 or NTFS partition containing Windows.  Which was often the case in that I have several USB/FireWire Enclosures that I put drives pulled from physical machines in to retrieve User Data if the system died.  The message stated...

Cannot open the disk '/Virtual Machines/Temp/RawDiskTest.vmwarevm/RawDiskTest.vmdk' or one of the snapshot disks it depends on.

Reason: The partition table on the physical disk has changed since the disk was created. Remove the physical disk from the virtual machine, then add it again.

I was under the impression that VMware Fusion was supposed to be able to dynamically adjust based on the information in the blue part however I guess I misunderstood discussions on this issue that for many years was a real problem with Mac's and Boot Camp or external disks because the disk order is not guaranteed and changes.  That might sound like a fundamental flaw in the Host OS however after researching it a bit I then understood at the time why it was happening but now forget where I stood on the issue at the OS Lever, flaw or reasonable design concept.

What I did in the past, several years ago, I created a .vmdk for each of my disk used in the USB/FireWire Enclosures and then started the VM that used theses disks via a script that checked the current disk number assigned and the swapped out the .vmdk in that VM and then started it.  It was a bit of a pain because back then I was doing a lot of work that required using quite a few raw disks and it was the only way around VMware's issue with the disk number changing.  A least I didn't have to stop and recreate the .vmdk or edit it for the raw disk each time since I pre-created them and used a script to run the VM's that were using them.  I find scripting solutions so much easier under Unix/Linux then Windows Hosts.

[claytontstanley]

Thanks for the detailed responses.

I created the vmdk files using VMWare Workstation 7. I afterwards migrated to 8.

Interesting to hear that there are other cases where the physical drive order scrambles, other than Win7 and my specific configuration. Maybe this is enough motivation for VMWare to fix this issue?

I was thinking about scripting a solution to this problem last night. Reassuring to hear that others had to go down the same route. Question though. Can I add a comment within a .vmdk file? I would like to store the UUID of the drive in the .vmdk (as a comment), even if VMWare doesn't support this. I can then use that information in the script, to fix all of the drive mappings after a reboot.

To VMWare developers: If having me write a script that uses sed to replace text in a vmdk file makes you uneasy, then please consider having the vmdk files reference the UUID of the drive (instead of the drive number), so that I don't have to hack around the problem.

[continuum]

yes - you can store comments in a vmdk file
actually you already have 4 commented lines in a vmdk already

# Disk DescriptorFile
# Extent description
# The Disk Data Base
#DDB

as you see a commented line starts with #

[claytontstanley]

Thanks.

If I don't receive any additional posts about other options/ideas in the next few days, I'll write the script.

[WoodyZ]

I'd probably start writing the script because continuum is one of the most knowledgeable users here and if he doesn't have a different solution to offer, other then my scripting scenario, then scripting you should go.

[continuum]

just thinking loud ...
to create a real safe script you could  use the UUID of the disk and the size in sectors.
Compare it with a value that you preset in the script and if both match  create the descriptor from scratch and overwrite the old vmdk.

[claytontstanley]

Here's my script. There's no error checking, and it's not portable, etc. This is just for documentation, if you're interested.

[claytontstanley]

Updated script. This one is a bit more configurable, and has some comments.

[claytontstanley]

Final update. I've been using this one for the past few months, and it seems to be working fine.

[EEdev]

Thankyouthankyouthankyou

I had a VM on a physical disk, and somehow the <vmname>.DiskParts file got corrupted.  idk why I had that type instead of a .vmdk, but that's the way it'd always been.  Recently wouldn't start the VM, just a cryptic message that it failed to open the disk.  Looked into the logs, and had to dig way in there to see that it failed to convert the UUID path or some such.  These key words led me to your post

After deleting the blue section you marked, it started right up again!

Hopefully this helps someone else struggling with physical disks in vmware

fwiw, I'm not going to be using a physical disk anymore.  RAW disks you can't get into, migration is a pain, and vmware has some other limitations like running the vm in the background (they do this with 'shared' VMs, although I did get it to start as a windows process on boot (not user login) using Task Scheduler).  Also you can't snapshot a vm on a physical disk.  Plus .vmdk files are easily portable, you can back them up, etc.  I don't see any advantage to a physical disk after all this

[continuum]

>> Also you can't snapshot a vm on a physical disk.
Hmmm - I would expect that you can create snapshots for rawdisks even with recent versions.
Of course you only should use that if you really know what you are doing.
In the past the workaround was to NOT to use the flag you would normally set for a rawdisk:

scsi0:0.deviceType = "PhysicalDrive0"

or

scsi0:0.deviceType = "rawDisk"