VMware Cloud Community
continuum
Immortal
Immortal

Feature Suggestion for a pop-up warning message when a VM is started with a non snapshotable vmdk

Before ESXi starts a VM it checks wether all vmdks referenced in the vmx-file are using one of the allowed VMDK-formats.
Average user expects that a VMDK that passes this pre-launch test can be snapshotted.
This assumption is incorrect but if a user does not know this he will run into avoidable problems soon.
This problems could be avoided if ESXi would popup a "just for your information" message like:
"VMDK uses a format that can not be snapshotted.
If you want to use snapshots import it first via
vmkfstools -i vmdk-xy snapshot-ready.vmdk -d thin"

The problem usually occurs like:
"I have ten VMs, 9of them can be backupped by Veeam - one fails. What is wrong ?"
"Cant use automatic backups for a newly imported VM. What is wrong ?"

In more technical terms ....:
please popup a info message if a VM is started that uses one or more vmdks of type "monosparse"

Risk of current behaviour:
users expect that all acceptable vmdk-types behave the same.
When it is not documented that "monosparse" does not allow snapshots normal users will try things that will not work.
Next they will waste hours and hours with unnecessary troubleshooting.

Severity: low

Best solution: display exact vmdk-type in datastorebrowser and provide documentation about features of the different vmdk-types
Good enough solution: popup up a info message when a vmdk-type with unexpected behaviour is used.

Why change anything if this is a rare issue ?
Any user that runs into the issue nowadays will typically waste a lot of time before he comes to the conclusion that:
either ESXI should warn in advance or the documentation is not good enough - maybe both. So a user either loses data or realizes that the documentation is incomplete. Both cases leave unhappy users ...

Side-effects: to be able to exchange VMs between platforms with ease a basic knowledge about the different vmdk-types is necessary.
This knowledge is not part of the current documentation - which results in folks that run into unexpected behavior and waste hours for unnecessary troubleshooting - all of which could be easily avoided.

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
2 Replies
continuum
Immortal
Immortal

monosparse ??? - never heard about that type ???
Right - but you probably know this type  by its original name "monolithicSparse" - this term has been used in Workstation - documentation for many years.
In Workstation context this type appears in 2 flavours: with embedded descriptor and with external descriptor.
As far as I know current esxi -7s version of vmkfstools accepts 3 typical workstation formats for the -d parameter.
Only one of them is listed in the  vmkfstools-buildin-help and that is the split-sparse type which in vmkfstools slang is labelled "2gbsparse"
The other 2 undocumented output formats are labelled "monosparse" and "monoflat"

Here are examples for the three different descriptorfiles ...

2gbsparse creates descriptor like this:

# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=fffffffe
parentCID=ffffffff
createType="twoGbMaxExtentSparse"

# Extent description
RW 8323072 SPARSE "2gbsparse-s001.vmdk"
RW 8323072 SPARSE "2gbsparse-s002.vmdk"
RW 8323072 SPARSE "2gbsparse-s003.vmdk"
RW 8323072 SPARSE "2gbsparse-s004.vmdk"
RW 8323072 SPARSE "2gbsparse-s005.vmdk"
RW 8323072 SPARSE "2gbsparse-s006.vmdk"
RW 8323072 SPARSE "2gbsparse-s007.vmdk"
RW 8323072 SPARSE "2gbsparse-s008.vmdk"
RW 8323072 SPARSE "2gbsparse-s009.vmdk"
RW 8323072 SPARSE "2gbsparse-s010.vmdk"
RW 8323072 SPARSE "2gbsparse-s011.vmdk"
RW 8323072 SPARSE "2gbsparse-s012.vmdk"
RW 8323072 SPARSE "2gbsparse-s013.vmdk"
RW 8323072 SPARSE "2gbsparse-s014.vmdk"
RW 8323072 SPARSE "2gbsparse-s015.vmdk"
RW 8323072 SPARSE "2gbsparse-s016.vmdk"
RW 8323072 SPARSE "2gbsparse-s017.vmdk"
RW 8323072 SPARSE "2gbsparse-s018.vmdk"
RW 8323072 SPARSE "2gbsparse-s019.vmdk"
RW 8323072 SPARSE "2gbsparse-s020.vmdk"
RW 8323072 SPARSE "2gbsparse-s021.vmdk"
RW 8323072 SPARSE "2gbsparse-s022.vmdk"
RW 8323072 SPARSE "2gbsparse-s023.vmdk"
RW 8323072 SPARSE "2gbsparse-s024.vmdk"
RW 8323072 SPARSE "2gbsparse-s025.vmdk"
RW 1638400 SPARSE "2gbsparse-s026.vmdk"

# The Disk Data Base
#DDB

ddb.adapterType = "lsilogic"
ddb.deletable = "true"
ddb.geometry.cylinders = "13054"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.longContentID = "77cb484d23a17f8c410449ccfffffffe"
ddb.uuid = "60 00 C2 93 26 59 8d f0-90 31 cd e9 f9 28 ae 9d"
ddb.virtualHWVersion = "14"

 

monosparse looks like:

# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=fffffffe
parentCID=ffffffff
createType="twoGbMaxExtentSparse"

# Extent description
RW 209715200 SPARSE "sparse-s001.vmdk"

# The Disk Data Base
#DDB

ddb.adapterType = "lsilogic"
ddb.deletable = "true"
ddb.geometry.cylinders = "13054"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.longContentID = "77cb484d23a17f8c410449ccfffffffe"
ddb.uuid = "60 00 C2 99 c1 a8 33 b7-15 6c 2d 9e 80 62 e4 54"
ddb.virtualHWVersion = "14"


and finally monoflat looks like:

# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=fffffffe
parentCID=ffffffff
createType="monolithicFlat"

# Extent description
RW 209715200 FLAT "monoflat-flat.vmdk" 0

# The Disk Data Base
#DDB

ddb.adapterType = "lsilogic"
ddb.geometry.cylinders = "13054"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.longContentID = "72e80a6c861a95cfe55c8f59fffffffe"
ddb.uuid = "60 00 C2 90 1b 42 33 55-5e d7 99 a3 8c 78 4f b4"
ddb.virtualHWVersion = "14"

This appears to be inconsistent - and it is indeed is inconsistent.

To get the whole picture you also need one more piece.
As far as I know we can assume that with descriptortypes created by ESXi 6 and later the line "createType"appears to be "for your info only" !!!
By the way - this also appears to be a valid assumption for all the ddb.* parameters.
I believe they are all optional these days.
CreateType still looks like a required parameter - but rules are lax.
Good enough seems to be if this parameter does NOT list a value that is out of bounds.

Still needs to be tested by me so take the next bit with caution and check back later.

Assumption: monosparse, 2gbsparse and monoflat ( labelled in vmkfstools-slang)  probably pass the pre-boot check in ESXi but none of the 3 can be snapshotted. If that turns out to be correct than the picture is complete again.

If you are aware of this - troubleshooting a VM that cant be snapshotted is a painless straight forward task.
If you are NOT aware of this, troubleshhoting the same VM can easily end with  lots of wasted hours.
Another big advantage for an admin that knows this stuff:
Inter-platform migrations dont need to rely on the sunny-weather OVF/OVA tool.
Now you know that you can acchieve the same results with the way more reliable vmkfstools ...

Why is this stuff undocumented ? -  ... just kidding 😎

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 ...

continuum
Immortal
Immortal

Here is another small bit  ... a must know for Workstation-users !
Do NOT assume that the vmdk-type that in Workstation slang goes   by the term "one piece growing" or by the "createType" name:monolithicSparse is compatible to monosparse format used by ESXi 7.

It is not !!!
Workstation uses one piece growing format in the subtype "one piece growing with embedded descriptor"
ESXi 7 uses  the subtype "one piece growing with external descriptor" - and both are incompatible on ESXi.

To be precise Workstation uses an embedded descriptor like:

# Disk DescriptorFile
version=1
encoding="windows-1252"
CID=fffffffe
parentCID=ffffffff
isNativeSnapshot="no"
createType="monolithicSparse"

# Extent description
RW 2097152000 SPARSE "onepiecesparse1000gb.vmdk"

# The Disk Data Base
#DDB

ddb.adapterType = "lsilogic"
ddb.geometry.cylinders = "130541"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.longContentID = "25486c0e0f76b70eaab764f5fffffffe"
ddb.uuid = "60 00 C2 93 02 1c 7b 77-08 ae e0 e1 ac e7 38 7b"
ddb.virtualHWVersion = "8"


You think this is confusing ??? - I agree ... but wait .. here is another piece to add to the puzzle.
https://www.virtuallyghetto.com/2012/09/2gbsparse-disk-format-no-longer-working.html

To sum it up - until esxi 5.1 ESXi and Workstation had one reasonable exchange format that worked on both platforms.
"2gbsparse" in vmkfstools slang or ""twoGbMaxExtentSparse" in Workstation slang.
The only assumption that gives a reasonable explanation for disabling a known-to-work exchange format is: the format was too tricky to use for most users and because of those problems it was replaced by a superior GUI tool.
Could this be the OVF/OVA tool ? - or am I missing another piece of the puzzle ?

I always assumed that flawless migration betwwen ESXi and  Workstation is a good selling argument and quite high on the priority list.
But that assumption must be flawed - as the only way to learn how to migrate flawlessly requires to use hexdumps and reading the strings from ESXi binaries.

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