Hi,
I have found to my dismay a couple of times when i delete the snapshots of a VM (2 snapshots - 1 being a child of the other) and the VM returns to the original VM with no current data saved ..
Am I doing something wrong. It is causing a problem in that i can't rely on this.
Regards
WB
Hi
the vmdk-type you use is "twoGbMaxExtentSparse"
That is a vmdk-format used by Workstation and Fusion.
ESXi can NOT handle this correctly- actually the way ESXi treats that format is really inconsistent.
Apparently ESXi allows you to use it in spite of the fact it can not handle snapshots correctly.
It can add snapshots but it can not merge them back into the basedisk if you use the snapshotmanager "delete" function.
Some time ago the base-vmdk must have been copied to the ESXi by someone who was not aware that you must first convert this format to the ESXi-native format.
I would suggest that you convert the basedisk to the native "vmfs" - format either with vmkfstools -i base.vmdk new.vmdk - or if that does not work you can do that step on Workstation.
Once you have the correct format you should be able to re-attach the 2 snapshots manually and then use "delete" again.
Do not use Datastorebrowser when investigating problems like this !!! Use commandline or WinSCP - Datastorebrowser does not display VMDKs correctly.
Hey wiillsson,
I am not sure if understand what you are facing but basically snapshots works like this, when you "Revert To" you will go back to the state where your VM was at that time. If you "Delete" an snapshot, all the changes from that snapshot will be consolidated to the VMDK of the Virtual Machine.
I recommend you to go over the next Deep Dive to have a full understanding on how the Snapshots work: Deep Dive - The Ultimate Guide to Master VMware Snapshot
Hi,
You can post the "vmware.log" log file:
/vmfs/volumes/datastore/virtual machine/vwmare.log
a suggestion ... is to schedule an upgrade to the latest version available for Esxi 6.5.0U3A
https://my.vmware.com/web/vmware/downloads/details?downloadGroup=ESXI65U3A&productId=614
ARomeo
Hi, thanks .. I was definetly not reverting to snapshot and specifically selected to delete , and as this has happened before I knew to watch out for this. I will upload my VM Ware log as requested by AlessandroRomeo68, which is redacted for certain information .
W
Hi Alessandro, have attached the vmware.log - i have replaced some info such as IP , uuids , paths with '...'
some of the entries in the log such as 'failed to open (Object type requires hosted I/O). ' and 'Unsupported or invalid disk type 7 for 'ide0:0'. Ensure that the disk has been imported.' may explain the issue- i don't know ..
When the vm was imported I had issues with the disk type - I don't think it like 'scsi:0' and would not bootup , coming up with some error. I got around this by changing this to 'ide:0' and the vm booted up . Not sure if it sheds light on anything.
Thanks
W
So if you deleted the snapshot all your changes got consolidated into the disk so that state is no longer available and i do not think there is a way to go back unless you have a backup of your VM.
I would like to check this log file as well:
/var/log/vmkernel.log
ARomeo
Hi , i deleted the snapshots as they were no longer required expecting the VM to stay in the current state , however it reverted to the original state of the VM -when it was created with none of the changes since having been consolidated.
W
There are a couple of things that do not look right.
The .vmdk data file name (...-s001.vmdk) looks like one from e.g. VMware Workstation, i.e. a file format that's not supported on ESXi.
To get some more details, please run
hexdump -C -n 32 "KafkaBus Debian Template-disk1-s001.vmdk"
and post the ouput.
In addition to this, attach the descriptor file "KafkaBus Debian Template-disk1.vmdk" to your next reply.
André
I agree with A.P.
You can add an image of the files that are inside the virtual machine folder.
ARomeo
Hi, i attach the hex dump as well as list of contents of VMs folder.
The VMDK that is requested is 3.67 GB - and that's the VMs contents data file -which i can't upload
I think that the VM OVA was created by a different product but those who created it for me are not forth coming on this but I think this could be the issue.
Thanks
W
The VMDK that is requested is 3.67 GB - and that's the VMs contents data file -which i can't upload.
The file that I've asked for should only be a few hundred bytes in size. The datastore browser shows the descriptor file's name along with the data file's size, which may have confused you.
You can see the real sizes by running ls -lisa from the command line (this command's output would also be helpful).
Assuming that it's only a few hundred bytes large, you may run
cat "KafkaBus Debian Template-disk1.vmdk"
and post the output.
André
Hi
the vmdk-type you use is "twoGbMaxExtentSparse"
That is a vmdk-format used by Workstation and Fusion.
ESXi can NOT handle this correctly- actually the way ESXi treats that format is really inconsistent.
Apparently ESXi allows you to use it in spite of the fact it can not handle snapshots correctly.
It can add snapshots but it can not merge them back into the basedisk if you use the snapshotmanager "delete" function.
Some time ago the base-vmdk must have been copied to the ESXi by someone who was not aware that you must first convert this format to the ESXi-native format.
I would suggest that you convert the basedisk to the native "vmfs" - format either with vmkfstools -i base.vmdk new.vmdk - or if that does not work you can do that step on Workstation.
Once you have the correct format you should be able to re-attach the 2 snapshots manually and then use "delete" again.
Do not use Datastorebrowser when investigating problems like this !!! Use commandline or WinSCP - Datastorebrowser does not display VMDKs correctly.
Thanks for the diagnosis and recommendations - It explains everything about this VM and I will disseminate this to the dev that provided me with the OVA as well as try the conversion using vmkfstools. Currently I am using a data store backup. I will also try to use winscp and putty more for trouble shooting in future .
W