VMware Cloud Community
sahirmemon
Contributor
Contributor
Jump to solution

Getting error: The capacity of the parent virtual disk and the capacity of the child disk are different (67).

Hi,

I was trying to increase the hard disk space of a 10GB linux vm to a 20GB. I shut down the vm then ssh'd into the ESXi server. From there I ran the command:

vmkfstools -X 20G Apatite.vmdk

The command ran successfully. Then, when I powered up the vm I got and still am getting:

Reason: The capacity of the parent virtual disk and the capacity of the child disk are different.
Cannot open the disk '/vmfs/volumes/503fd5b8-d1cef086-eb4a-10bf487b38db/Apatite/Apatite-000001.vmdk' or one of the snapshot disks it depends on.

I have tried numerous things such as cloning the Apatite.vmdk to Apatite-repaired.vmdk. That works, however, I am getting an older version of the VM. i am not getting my changes from either Apatite-000001.vmdk or Apatite-000001-delta.vmdk.

I have some really important work on my VM that I am trying to restore. I should have backed it up before doing anything but I did. Now it seems like I am paying the price.

Can anyone help me recover my VM? Is there a way to increase the size of the snapshot (Apatite-000001.vmdk) or reduce the size of the parent so they match and the vm starts up?

Please help.

Thank you

Reply
0 Kudos
1 Solution

Accepted Solutions
continuum
Immortal
Immortal
Jump to solution

Apatite-000001.vmdk
# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=79c3c056
parentCID=cf2ec09b
isNativeSnapshot="no"
createType="vmfsSparse"
parentFileNameHint="Apatite.vmdk"
# Extent description
RW 41943040 VMFSSPARSE "Apatite-000001-delta.vmdk"
# The Disk Data Base
#DDB
ddb.longContentID = "11ad79de6b5a5fe9218cfd7179c3c056"
ddb.toolsVersion = "9216"

edited entries are marked red

after you made the changes - do NOT start the VM
instead remove it from inventory and run

vmkfstools -i "Apatite-000001.vmdk" "consolidated.vmdk" -d thin

when done edit the vmx file and replace
scsi0:0.filename = "Apatite-000001.vmdk"
with
scsi0:0.filename = "consolidated.vmdk"

now you can register the VM again.

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

View solution in original post

Reply
0 Kudos
14 Replies
continuum
Immortal
Immortal
Jump to solution

Expanding a vmdk with snapshots is a bad idea.

I would do the following: adjust the snapshot descriptor so that it uses the same capacity as the basedisk.
Then clone the snapshot + basedisk into a new vmdk.

If unsure post both descriptor vmdks so that I do the edits for you


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

sahirmemon
Contributor
Contributor
Jump to solution

Thank you for your response.

You are absolutely right that it is a bad idea. I have definetly learned my lesson.

However, I am not sure how to adjust the descriptors. Will you please help me edit them?

Here are the descriptors:

Apatite.vmdk

# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=cf2ec09b
parentCID=ffffffff
isNativeSnapshot="no"
createType="vmfs"
# Extent description
RW 41943040 VMFS "Apatite-flat.vmdk"
# The Disk Data Base
#DDB
ddb.virtualHWVersion = "8"
ddb.longContentID = "2b33991afece97ba38c002d7cf2ec09b"
ddb.uuid = "60 00 C2 99 22 e3 ac ff-f6 93 1e 2d 0c c9 b0 84"
ddb.geometry.cylinders = "2610"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.adapterType = "lsilogic"
Apatite-000001.vmdk
# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=79c3c056
parentCID=19be0de2
isNativeSnapshot="no"
createType="vmfsSparse"
parentFileNameHint="Apatite.vmdk"
# Extent description
RW 20971520 VMFSSPARSE "Apatite-000001-delta.vmdk"
# The Disk Data Base
#DDB
ddb.longContentID = "11ad79de6b5a5fe9218cfd7179c3c056"
ddb.toolsVersion = "9216"

Thanks again for your help.

Reply
0 Kudos
continuum
Immortal
Immortal
Jump to solution

Apatite-000001.vmdk
# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=79c3c056
parentCID=cf2ec09b
isNativeSnapshot="no"
createType="vmfsSparse"
parentFileNameHint="Apatite.vmdk"
# Extent description
RW 41943040 VMFSSPARSE "Apatite-000001-delta.vmdk"
# The Disk Data Base
#DDB
ddb.longContentID = "11ad79de6b5a5fe9218cfd7179c3c056"
ddb.toolsVersion = "9216"

edited entries are marked red

after you made the changes - do NOT start the VM
instead remove it from inventory and run

vmkfstools -i "Apatite-000001.vmdk" "consolidated.vmdk" -d thin

when done edit the vmx file and replace
scsi0:0.filename = "Apatite-000001.vmdk"
with
scsi0:0.filename = "consolidated.vmdk"

now you can register the VM again.

________________________________________________
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
memaad
Virtuoso
Virtuoso
Jump to solution

Hi ,

Just FYI... When we change size of  virtual disk, in vmdk,  "RW" value get changed. So snapshot disk and Original disk should have same vlaue.

Regards

Mohammed

Mohammed | Mark it as helpful or correct if my suggestion is useful.
Reply
0 Kudos
continuum
Immortal
Immortal
Jump to solution

you are right - but I fail to see why you post that now ???


________________________________________________
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
sahirmemon
Contributor
Contributor
Jump to solution

It worked!

Thanks for all your help!

Reply
0 Kudos
thenightfly
Enthusiast
Enthusiast
Jump to solution

Dear Forum Members! continuum
Hopefully somebody will see this..

I ran into the same problem but I have multiple "snaphots".

here are three descriptors:

w2k8r2-flat.vmdk

# Disk DescriptorFile

version=1

encoding="UTF-8"

CID=fffffffe

parentCID=ffffffff

isNativeSnapshot="no"

createType="vmfs"

# Extent description

RW 2147483648 VMFS "w2k8r2-flat.vmdk"

# The Disk Data Base

#DDB

ddb.adapterType = "lsilogic"

ddb.geometry.cylinders = "133674"

ddb.geometry.heads = "255"

ddb.geometry.sectors = "63"

ddb.longContentID = "589d15de4396b582f68371f0fffffffe"

ddb.thinProvisioned = "1"

ddb.uuid = "60 00 C2 91 cb 03 8f 31-d8 73 ed 99 b2 5e eb c2"

ddb.virtualHWVersion = "11"

~

w2k8r2-000001.vmdk

# Disk DescriptorFile

version=3

encoding="UTF-8"

CID=c6e62876

parentCID=c6e62876

isNativeSnapshot="no"

createType="vmfsSparse"

parentFileNameHint="w2k8r2.vmdk"

# Extent description

RW 419430400 VMFSSPARSE "w2k8r2-000001-delta.vmdk"

# Change Tracking File

changeTrackPath="w2k8r2-000001-ctk.vmdk"

# The Disk Data Base

#DDB

ddb.longContentID = "94850e7daf77885ea3b242a7c6e62876"

~

w2k8r2-000002.vmdk

# Disk DescriptorFile

version=3

encoding="UTF-8"

CID=c6e62876

parentCID=c6e62876

isNativeSnapshot="no"

createType="vmfsSparse"

parentFileNameHint="w2k8r2-000001.vmdk"

# Extent description

RW 419430400 VMFSSPARSE "w2k8r2-000002-delta.vmdk"

# Change Tracking File

changeTrackPath="w2k8r2-000002-ctk.vmdk"

# The Disk Data Base

#DDB

ddb.longContentID = "94850e7daf77885ea3b242a7c6e62876"

Can you please advise what to change?

Thank you!

Reply
0 Kudos
continuum
Immortal
Immortal
Jump to solution

Did you already expand the partition inside the basedisk ?
If not I would rather revert the expand of the basedisk.


________________________________________________
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
thenightfly
Enthusiast
Enthusiast
Jump to solution

Unfortunately I did nothing with the VM. I have Unitrends Backup which failed once (it works via Snapshots) and then I was not able to stat the VM.
I did not do any manual thing with the VM.

Reply
0 Kudos
marvinjulz
Contributor
Contributor
Jump to solution

Hi Can you help with this?

Reply
0 Kudos
continuum
Immortal
Immortal
Jump to solution

Hi

provide some input please


________________________________________________
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
dkpsycho
Contributor
Contributor
Jump to solution

Hi, im having the same problem as in this post, just resized a vm with 4 snaps in it. atm im doing what you did on the "awnser", edited the snaps decriptors and cloning them. problem is, its taking too long. cant i just remove the snaps from vmx and make it sound like there is no snap? sorry if what im saying doesnt make sense, im not very knowledgeable of vmware. Ty in advance,. 

Reply
0 Kudos
dkpsycho
Contributor
Contributor
Jump to solution

Actually, just noted that each snap vmdk should have parentcid of previous snap, right? so i should edit each vmdk with the previous vmdk cid and clone the last one? 

ie: VMS22_0.vmdk CID=xxxx

VMS22_0-000001.vmdk CID=yyyy parentCID=xxxx
VMS22_0-000002.vmdk CID=zzzz parentCID=yyyy

and so on..

also, the last vmdk has parentcid of itself?, can i ignore that file and clone the previous one? 

 

Reply
0 Kudos
continuum
Immortal
Immortal
Jump to solution

Hi
short answer: yes
better answer: now wait a minute !
A valid snapshot chain requires that 4 parameters of each descriptorfile use the expected value - if only a single one of them is off - the VM will not start.
Your questions and actions show me that you have not yet understood how a snapshot chain really works. No offense intended !
Please attach the vmx-file and all the vmdk-descriptorfiles to your next post.
Then I explain how to deal with this.

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