VMware Communities
rhvm
Contributor
Contributor

parentfilenamehint - randomly uses absolute path

Had a problem with moving VM's around recently and just discovered parentfilenamehint.  I never use clones, just copy the physical machines and it's always worked until recently.  Under what circumstance would the .vmdk files have entries of parentfilenamehint that use absolute paths? 

Reply
0 Kudos
6 Replies
a_p_
Leadership
Leadership

This happens if a VM's configuration file contains a "workingDir" entry to create snapshots in a different location.

André

Reply
0 Kudos
rhvm
Contributor
Contributor

I assume you mean the .vmx file.  I checked all the .vm* files < 50k and that string is not there.

Outside of a user specifically configuring a VM in such a manner, I can't imagine why the default behavior would ever BRAND a VM to a specific drive/folder.  So now I've got to write a script to run regularly and check for that.

In testing, I've noticed that VMware (after the VM is copied) will most of the time update the Disk DescriptorFile(s) and remove the path part when the VM is started - presumably since it finds the files in the local directory.  However, in a couple of scenarios it did not do this.  As a result, when I started the copied VM, it "reached' into the path it came from and whacked those files.  I don't know what logic VMware uses to determine that the Disk DescriptorFile needs updating. 

I tried removing the path part myself but that didn't work.  It reported it could not find a file - but that file did exist.  I didn't know what to do about the CID in the Disk DescriptorFile or uuid.location in the .vmx file.  So that might have been why it didn't work.

Now I know to HIDE my source VM after copying it until I've booted the copy and checked the Disk DescriptorFile(s) for any reference to the source VM.  I've NEVER had to do this in the past 10 years though.  Strange.

Reply
0 Kudos
continuum
Immortal
Immortal

Virtual disks store binary data and m can be very very large. The chance that a manual edit of such a large file goes wrong is high.
So the developers made sure that normally there is no need to edit the binary part and located everything that occasionally has to be edited into a small textfile - which we usually call descriptorfile.
The next few lines in red are an example for a descriptorfile of a basedisk:

# Disk DescriptorFile

version=1

encoding="windows-1252"

CID=ef2d6d3b

parentCID=ffffffff

isNativeSnapshot="no"

createType="twoGbMaxExtentSparse"

# Extent description

RW 65536000 SPARSE "esxi6-reference-1tb-filled-with-30000-files-s001.vmdk"

RW 65536000 SPARSE "esxi6-reference-1tb-filled-with-30000-files-s002.vmdk"

RW 65536000 SPARSE "esxi6-reference-1tb-filled-with-30000-files-s003.vmdk"

RW 65536000 SPARSE "esxi6-reference-1tb-filled-with-30000-files-s004.vmdk"

RW 65536000 SPARSE "esxi6-reference-1tb-filled-with-30000-files-s005.vmdk"

RW 65536000 SPARSE "esxi6-reference-1tb-filled-with-30000-files-s006.vmdk"

RW 65536000 SPARSE "esxi6-reference-1tb-filled-with-30000-files-s007.vmdk"

RW 65536000 SPARSE "esxi6-reference-1tb-filled-with-30000-files-s008.vmdk"

RW 65536000 SPARSE "esxi6-reference-1tb-filled-with-30000-files-s009.vmdk"

RW 65536000 SPARSE "esxi6-reference-1tb-filled-with-30000-files-s010.vmdk"

RW 65536000 SPARSE "esxi6-reference-1tb-filled-with-30000-files-s011.vmdk"

RW 65536000 SPARSE "esxi6-reference-1tb-filled-with-30000-files-s012.vmdk"

RW 65536000 SPARSE "esxi6-reference-1tb-filled-with-30000-files-s013.vmdk"

RW 65536000 SPARSE "esxi6-reference-1tb-filled-with-30000-files-s014.vmdk"

RW 65536000 SPARSE "esxi6-reference-1tb-filled-with-30000-files-s015.vmdk"

RW 65536000 SPARSE "esxi6-reference-1tb-filled-with-30000-files-s016.vmdk"

RW 65536000 SPARSE "esxi6-reference-1tb-filled-with-30000-files-s017.vmdk"

RW 65536000 SPARSE "esxi6-reference-1tb-filled-with-30000-files-s018.vmdk"

RW 65536000 SPARSE "esxi6-reference-1tb-filled-with-30000-files-s019.vmdk"

RW 65536000 SPARSE "esxi6-reference-1tb-filled-with-30000-files-s020.vmdk"

RW 65536000 SPARSE "esxi6-reference-1tb-filled-with-30000-files-s021.vmdk"

RW 65536000 SPARSE "esxi6-reference-1tb-filled-with-30000-files-s022.vmdk"

RW 65536000 SPARSE "esxi6-reference-1tb-filled-with-30000-files-s023.vmdk"

RW 65536000 SPARSE "esxi6-reference-1tb-filled-with-30000-files-s024.vmdk"

RW 65536000 SPARSE "esxi6-reference-1tb-filled-with-30000-files-s025.vmdk"

RW 65536000 SPARSE "esxi6-reference-1tb-filled-with-30000-files-s026.vmdk"

RW 65536000 SPARSE "esxi6-reference-1tb-filled-with-30000-files-s027.vmdk"

RW 65536000 SPARSE "esxi6-reference-1tb-filled-with-30000-files-s028.vmdk"

RW 65536000 SPARSE "esxi6-reference-1tb-filled-with-30000-files-s029.vmdk"

RW 65536000 SPARSE "esxi6-reference-1tb-filled-with-30000-files-s030.vmdk"

RW 65536000 SPARSE "esxi6-reference-1tb-filled-with-30000-files-s031.vmdk"

RW 65536000 SPARSE "esxi6-reference-1tb-filled-with-30000-files-s032.vmdk"

# The Disk Data Base

#DDB

ddb.adapterType = "lsilogic"

ddb.geometry.cylinders = "130541"

ddb.geometry.heads = "255"

ddb.geometry.sectors = "63"

ddb.longContentID = "a435d83b5f5c406172cad6d1ef2d6d3b"

ddb.uuid = "60 00 C2 93 77 95 b6 15-77 13 7a 89 c6 de 4b b3"

ddb.virtualHWVersion = "12"

DEscriptorfiles for a snapshot have the parameter you were lokking for - see example in green:

# Disk DescriptorFile

version=1

encoding="windows-1252"

CID=45e13899

parentCID=3652de6a

isNativeSnapshot="no"

createType="monolithicSparse"

parentFileNameHint="G:\_vms_\MASTER-viewlivecd-hamburg-remastersys\baseinstall-cl2.vmdk"

# Extent description

RW 16777216 SPARSE "baseinstall-cl2-000001.vmdk"

# The Disk Data Base

#DDB

It does not matter if the path used for parenFileNameHint is a relative one or an absolut one - only thing that matters is the question if the path is ok or not.
So while troubleshooting strange errors - keep in mind that the descriptorfile may have a bad path to the associated binary part.
Error messages that suggest a bad path in the descriptor are among others :
"file not found"
"vmdk is not a virtual disk"
"parent file has been changed ..."
just to name a few.
For troubleshooting errors in a snapshotshot chain we usually recommend to find all descriptorfiles first.
Then read the one that is referenced in the vmx-file first.
Then check the parewntfile of the one you started with.
Check if the parentfilenamehints and the path to the binary parts match what you actually have one disk.
If anything does not line up - adjust the descriptorfiles with a good texteditor like notepad++.
BUT IN MY CASE THERE IS NO DESCRIPTORFILE ....
Wrong ! - its there but you cant find it as it is embedded in the large binary vmdk.
The virtualdisktype "monolithcSparse" - also referred to as "growing one pice vmdk" is one of two specialcases where the descriptor is embedded.
That is not neccessarily so - it could also be external which would be much more userfriendly.
Now you should visit my website - and read a little bit about this stuff - see VMDK-Handbook ...
especially check the section:
How to safely edit embedded vmdk-descriptions    Read This !

Do yourself a favour - use the procedure I describe there when ever you have to work with embedded descriptors !
This dsfo,exe with the dsfi.exe allow us - to fix your descriptors and is the only safe way to help remotely.
If you try to use a hexeditor and only add a single bit - the vmdk is garbage !!!!

Ulli


________________________________________________
Do you need support with a VMFS recovery problem ? - send a message via skype "sanbarrow"
I do not support Workstation 16 at this time ...

Reply
0 Kudos
rhvm
Contributor
Contributor

Regarding your statement - "It does not matter if the path used for parenFileNameHint is a relative one or an absolut one"

Sometimes it DOES matter.  Like in my case.  I had copied a VM to another location.  When I started the copy, the absolute path in one of the .vmx files meant that this COPY of the VM used the virtual disks from the original.  If I did not have tools to monitor disk activity, I likely would have never known I was whacking the original VM while running the copy.  I never bothered to start the original to see how badly it was whacked.  I just ID'd the whacked VM's, restored from a backup, and HID them. Then I did the maintenance on the copies - paying special attention to those that used absolute paths. 

The solution is to HIDE (rename folder) the original VM BEFORE starting the copied VM.  When the absolute path can not be resolved, it seems to find the same file in the copied one and updates the .vmx file to reference it.  So far these updates have never been as absolute paths. 

I created a VM from scratch, booted it, powered off, created snapshot.  A .vmx file associated with the snapshot now contains an absolute path.  Don't know why that would be desired.  If you copy this machine and for some reason the absolute path does not get automatically changed to reference the copy, when you boot it, you're using the disks from the original.

Now, answering the I Moved it or I Copied It question is probably supposed to prevent this from happening by updating the paths (regardless of type) to point to the copied VM.  If you hide the originals, it will always update the .vmx files to point to the copy and produce paths that are not absolute.  In my case for some reason it did not.  Don't know that logic is in place to decide if a VM has changed - been copied or moved.  Could be the ones I was working on were originally on the same host disk - just in a different path - and that wasn't enough for it to think it had been altered. 

Reply
0 Kudos
continuum
Immortal
Immortal

> Regarding your statement - "It does not matter if the path used for parenFileNameHint is a relative one or an absolut one"
You missunderstood - for the WS-application it makes no difference wether the path is absolute or relative as long as it is valid.
During troubleshooting it is best to expect both variants and understand the consequences of each option.
While using linked clones it of course makes a big difference.
For the question did you copy or move - check the vmx-parameters uuid.bios and uuid.location
http://sanbarrow.com/vmx/vmx-advanced.html#uuid


________________________________________________
Do you need support with a VMFS recovery problem ? - send a message via skype "sanbarrow"
I do not support Workstation 16 at this time ...

Reply
0 Kudos
rhvm
Contributor
Contributor

Oh, but as I described, for the WS application it CAN make a huge difference.  True, as long as the path is valid, the machine WILL boot.  But if you study my scenario carefully you'll see that when I booted the COPY, it was using the virtual disks from the original location since the path in the .vmx was absolute and somehow didn't get updated when I booted the COPIED VM.

I updated about 8 machines, most I'm sure I said "copied", I might have said "moved" on a couple by mistake.  Copied updates the bios and maybe the location whereas move only updates the location.  Not sure why that location change was not sufficient for WS to update the .vmx and strip the absolute path.  Unless, my theory of the VM having been on the exact same physical media before, only in a different folder, had something to do with it.  Though you'd think moving to a different folder would qualify as a "move".  Speaking of that, I did have one machine with an absolute path which refuse to boot if I moved it to another folder on the same disk.  So I copied it to another disk, booted it, copied it back to the folder on the other disk I wanted it in, booted, all OK.  Just needed VM to do it's magic by updating the location CID and strip the path then I can put it anywhere.  My stripping the path alone was not sufficient.

In my case, no linked clones.

Reply
0 Kudos