can someone break this down so we can understand what we are disabling and any caveats, getting confused by quiesce , microsoft vss, vmware vss , vmware snapshot providers etc.
we have 2019 servers, they were created with GPT (as we went went with uefi default bios which means gpt).
I am getting quiesce error when trying to clone a VM, not sure if this means file system quiesce or application VSS quiesce
If we follow the KB article and do this vss.disableAppQuiescing = true
what do we loose, I assume it will get rid of the error but then I ask what benifit are we losing as its the default option..
Also disabling the service as others have mentioned - is that exactly the same effect as the setting above.
This gets worse you know, disabling the service, as suggested by VMware, gives a false positive.
if you try and take a quiesced a snapshot from within VMware it fails with an error - expected
A non quiesced snapshot works without error - expected
A snapshot with memory works - expected
A clone fails with an error - expected (as it uses snapshots I suspect which default to quiesce)
then you disable the service "" vmvss"" within windows (Im GUESSING the hack config file does the same thing ?)
you then specifically do a quiesced snapshot,, hey presto it works,, no errors or warnings that there was no quiescing at all..??
Can some from VMware clarify this (non-consistent backups when VMware Snapshot Provided disabled). We have several non-2019 servers too where this "fix" has been applied and the assumption is that the snapshots are app consistent as long as the app "can be quiesced", not that we were removing the possibility of it being quiesced and being fooled into thinking all is good.
Also where in this architecture if so would this service sit.
Same problem happened to me: windows server 2019, GPT disk with recovery partition (hidden), ESXi 6.7.
Taking a quiesced snapshot of windows server 2019 with ESXi failed with
An expected hidden volume arrival did not complete because this LUN was not detected.
My workaround was:
- Boot the VM with gparted live ISO x64
- Remove diag and hidden flag from the recovery partition (it was the 1st partition). msftdata flag will automatically be set.
- Boot on windows, open disk manager and remove drive letter
We had the same issue, fix for us was to convert the Main Drive to a Dynamic Disk.
This allowed us to keep EFI and GPT.
It seems that the problem has now been corrected by Microsoft. I've done several tests and everything works for me. Does anything confirm this?
https://kb.vmware.com/s/article/60395 = we will need KB4534321
Greetings to all and good luck for the future.