Please remove https://kb.vmware.com/s/article/1002511

[continuum]

Please remove or fix https://kb.vmware.com/s/article/1002511

The instructions for recreating a missing descriptorfile are contra-productive and often make matters worse than they already are.

Ulli

 

[Valentin Bondzio]

Hi Ulli,

I haven't looked at that KB in years but I'll ask for it to be reviewed, do you have any specific feedback on what you'd like to see improved?

Cheers,

Valentin

[continuum]

Yes - the article suggests to recreate a missing descriptorfile by creating a  "dummy" vmdk, thin provisioned and using the same name.
This is a bad idea !
The smarter approach is to explain how to create a new descriptorfile from scratch.
To do that all you need is to look up the original size in sectors - which is trivial if the associated flat.vmdk still exists.
A descriptor for a flat.vmdk just needs 3 parameters: size-of-flat.vmdk, name-of-flat.vmdk, name-of-descriptor.vmdk
Creating a new flat.vmdk just to produce a small textfile is completely unnecessary - and it very often interferes with any recovery attempts.

I have posted better instructions a couple of times - if you want I will rewrite the article for you - just let me know ....

Ulli

[a_p_]

I still have the link to the old PHD stub file generator bookmarked.
http://web.archive.org/web/20120101132638/http://forums.phdvirtual.com/wrapgen

Something similar in the KB article would be nice.

André

[continuum]

Wow - nice find.
In that time I had my first IT-job for PHD-germany. Actually I had to work 2 days in 10 months .... LOL

Andre - for a complete KB-entry we would need 2 very simple calculators:

size in bytes / 512 = size in sectors
size in sectors / 16065 = geometry value
that would do for flat.vmdks

To do the same for delta and sesparse.vmdks is less trivial ...

 

Ulli

[Valentin Bondzio]

Hi Ulli,

Some colleagues and I had some downtime during a Zoom call and went through the KB / Video. There certainly are a few things that can be improved (flow, formatting, typos / grammar, minor updates / warnings) but we don't see the same problems that you do.

First of, if the VMware Knowledge Base could host a simple JS "generator" for the descriptor I'd agree that it would be best to generate the vmdk, lacking that the generation of a new, thin provisioned disk (with a _different_ name, not sure where you saw us using the same one) is not less safe (i.e. using vi / mv / rm) than potentially messing up some basic math.

The only major risk vector (besides fat fingering commands, it would be just as easy to accidentally cat echo the descriptor over the flat though) I could think of is creating additional files / names on potentially compromised volumes. If you are at that stage without backups then you have a bunch of other problems though.

I'll put it on my list to polish the wording / formatting / flow and add some additional warnings but I don't see how generating a new vmdk is significantly more safe than re-creating it via vmkfstools and editing it. Can you maybe expand on the what you'd like to see with restrictions / warnings and perspective on why creating a dummy vmdk is inherently more risky than manually creating the descriptor?

Cheers,

Valentin

[continuum]

Hi Valentin

First of all thank you very much for reacting to this request at all !
Thats great progress - I am trying to discuss this issue since years and almost gave up hope.
Thank you !

Let me show you first what I would suggest to replace the complete KB-entry.
Not nice - but 100% doing the job !

------------------------------------------------------------------------------------------------------------

###### sample descriptorfile for a basedisk
######
###### instructions:
###### 1. look up the name of the flat.vmdk
###### 2. look up the size of the flat.vmdk in bytes
###### use a calcular and do 2 calculations:
###### <size of the flat.vmdk in bytes> / 512 = XXX
###### XXX / 16065 = round down the result = YYY
###### now you have 3 parameters:
###### XXX - size in sectors
###### YYY - geometry value for cylinders
###### ZZZ - path of flat.vmdk
######
###### once you got those 3 parameters use the following
###### sample-file and replace XXX, YYY and ZZZ
###### with the values you figured out before
###### if the flat.vmdk was labelled "name-flat.vmdk"
###### store the small snippet as a plain textfile called "name.vmdk"
######
###### cut here:
# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=12345678
parentCID=12345678
createType="vmfs"

# Extent description
RW XXX VMFS "ZZZ"

# The Disk Data Base
#DDB

ddb.adapterType = "lsilogic"
ddb.geometry.cylinders = "YYY"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"

------------------------------------------------------------------------------------------------------

Afdditionally to this text you could offer several downloadable textfiles such:

sample-vmdk-descriptor-file-esxi6.txt
sample-vmdk-descriptor-file-esxi5.txt
sample-vmdk-descriptor-file-esxi6-china.txt  for countries that use different encoding ....

I think the instructions in the samplefile are self-explaining so I dont rephrase / explain it here - unless someone asks for that.

 

My reason for this suggestion are:

In my experience with recovery in the past I noticed one thing:
For the majority of vsphere-users seeing a flat.vmdk for the first time is a traumatic experience.
This means that while dealing with such a problem there is a high chance for panic-reactions like:

- rename the name-flat.vmdk to name.vmdk - now everything looks normal again
- delete the flat.vmdk
- move files - rename files ....

Often enough such a user will not even completely remember what he tried in the first panic reaction.
In the majority of the cases creating a new descriptorfile is really as easy as setting those 3 parameters in a sample-file.
So it is without doubt the most "minimal invasive" approach to resolve the problem.

The suggestion to create a new complete vmdk with vmkfstools is not minimal invasive - as IMHO every modification on a VMFS should be ...
Editing a sample-file and saving it is way less intrusive.

Now to the selfish reason why I ask for this in the first place:
When folks contact me for VMFS-recovery tasks I often see that combination of users in panic-mode + the KB instructions have severe negative impact on the chances of my recovery work.
I often have to search for deleted files and the only search parameter is the nominal size of the vmdk.
In this case every additional large flat.vmdk - thin or thick does not matter - makes my task more difficult.
Even worse is when folks try to create the dummy vmdk using the same name - even worse if it is created in the same path ...

I hate to answer to desparate users: sorry - I cant help you - you spoiled every chances we had by following that KB.
Dont get me wrong: the KB itself is not the real problem !
The problem is the panic mode that typically takes over when users have to  recreate a new descriptorfile for the first time.
So I had to find safe AND easy instructions to help them WITHOUT spoiling the chances for eventually necessary recovery work later.

Editing a sample file may take 2 minutes with almost zero risk.
The instructions in the KB are more "tricky" and the chance to make mistakes along the way is way larger.

And the educational effect for the users while following the KB is highly questionable.

I am aware that providing such a sample-file does not help to solve all problems with missing descriptor-files - but the KB also only addresses the most trivial cases.

Just an offer: if you are interested lets join forces and create a KB-entry that also deals with : create missing descriptors for snapshots and other more advanced cases.

Regards Ulli

[continuum]

Here is another KB that needs an update:

https://kb.vmware.com/s/article/1020645

Missing information: dump-size is way too small for ESXi 6 and 7.

 

Ulli

[Valentin Bondzio]

I'll look at your feedback in more detail when I can reserve an hour or two to work on the KB, thanks again for the conversation!

Many KB articles need updates, or at least too many for me to handle

Definitely leave feedback, the box pops up after clicking on either "Yes" or "No" under "Was this article helpful?". If the article is mostly correct but needs improvement I'd select "Yes". If nothing happens, open a thread here on the communities.

P.S.
Maybe at one point we have a dedicated threaded / weighted community thread per KB article that make (public) feedback discussions easier.