Ways to Troubleshoot VMware Snapshots

Virtualization administrators can use snapshots on VMware ESX to go back to their previous state and find out what went wrong with the virtual machine. In the first part of this series, we discussed how to use VMware snapshots. In the second part, I explained how to delete a snapshot without wasting disk space. However, what should I do if the snapshot fails? In this article, TechTarget China's special virtualization expert Eric Siebert will address potential issues when using snapshots on ESX.

Locating a virtual machine with snapshots

Trying to find out which virtual machine has a snapshot is a challenge. There is no centralized way to find snapshots in VMware Infrastructure Client or VirtualCenter, so you should periodically check the ESX server for old snapshots that need to be deleted. Here are some ways:

Method 1 - Use the Find command of the server console

1. Log in to the server console.

2. Change the /vmfs/volumes/directory.

3. Type find -iname "*-delta.vmdk" -mtime +7 -ls to find the snapshot file that has not been modified within 7 days or type find -iname "*-delta.vmdk" All snapshot files.

Method 2 - Use Dominic Rivera's free script called Snapalert. This script uses the VI Perl toolkit to talk directly to VirtualCenter and ensures that no components need to be installed on each host (also for ESXi). You can also choose to have the script generate an email report.

Method 3 - Using Xtravirt's free tool called Snaphunter, it can report snapshot status of virtual machines from multiple ESX Servers, as well as send email reports.

Method 4 - Query the VirtualCenter SQL database. VirtualCenter keeps track of all snapshots on each host in its VPX_SNAPSHOT table. I have written a VBS script that requires this table to display a list of virtual machines running snapshots. This method is good. However, it relies on database tables, which may change in future versions of VirtualCenter.

Handling Snapshots That Are Not Deleted Correctly

Occasionally, a snapshot is not deleted correctly and is still an active snapshot in the virtual machine. This happens when you use VMware Consolidated Backup or delete a snapshot with Snapshot Manager. In most cases, snapshots won't appear in Snapshot Manager for you to delete. The indication that the snapshot still exists is displayed in the delta file of the virtual machine directory.

If you have a running snapshot that is not in Snapshot Manager, you can try to delete it in one or two ways. The first method is to create a new snapshot using the VI Client and then delete all snapshots from Snapshot Manager. Or log in to the ESX Service console, switch to the virtual machine directory, type vmware-cmd createsnapshot to create a new snapshot. Wait for the creation and type vmware-cmd removesnapshots. When finished, check to see if the delta file has been deleted. If it has been deleted, the deletion is successfully completed.

If the delta file is not deleted, check the virtual machine vmx file. If this virtual machine is configured with only one virtual disk and finds the line starting with SCSI, it is usually scsi0:0. The .fileName should use the original disk file name created with the virtual machine, usually the same as the virtual machine name. If so, your virtual machine does not use snapshot files. If there is -00000# in the file name, it means that a snapshot file is currently in use.

The following example clearly illustrates this:

VM with no snapshots: scsi0:0.present = "true" scsi0:0.fileName = "myvmname.vmdk" VM with snapshots: Scsi0:0.present = "true" scsi0:0.fileName = "myvmname-000001.vmdk" .

If the above operation fails, you can only choose to copy the virtual machine or copy the virtual machine disk file. You can use VMware Converter to create a copy of an existing virtual machine, and when the creation is complete, shut down and delete the old virtual machine.

Another method is to shut down the virtual machine, log in to the server console, switch to the virtual machine directory, and copy the virtual machine disk file by using vmkfstools and specifying the snapshot file as the resource disk, for example, "vmkfstools –i myvmname- 000001.vmdk myvmnamenew.vmdk" , once this setting is completed, remove the hard drive (not delete), add a new hard drive and browser to the newly created disk file. Start the virtual machine and everything is working before you delete the old disk and the delta file.

By default, snapshots are written to the home directory of each virtual machine. Sometimes you need to change its location without taking up space on the volumes that belong to the virtual machine. It is possible to specify a new directory for the snapshot on each virtual machine. When you do this, the snapshot and vswp files are written to this directory.

But note that if your virtual machine is on shared storage, you will not be able to use features like VMotion/HA/DRS if you specify local storage as the address. The steps to change the method are as follows:

01. Shut down the virtual machine and log in to the server console.

02. Edit the virtual machine VMX file using Nano or Vi.

3. Add a new line using the following statement: workingDir = "/vmfs/volumes/SnapVolume/Snapshots/" .

4. If you want to keep the vswp file in the virtual machine directory, add the following to the VMX file: sched.swap.dir = "/vmfs/volumes/VM-Volume1/MyVM/". This step is optional. In addition, you don't need to worry about updating the existing "sched.swap.derivedName" parameter because it is generated by the virtual machine and is written to the config file each time the virtual machine is powered on.

5. Start the virtual machine, the vswp, vmsn and snapshot (delta-vmdk) files are now in this directory.

Using VMotion with Snapshots

If you want to move a virtual machine running a snapshot from one host to another, you will receive the following warning: "At the destination host Reverting to a snapshot may result in an error (warning). This warning occurs if you change the default location of any file on the virtual machine (like the snapshot or vswp file mentioned above), and the virtual machine will crash when the migration is complete. This can happen if the destination host cannot access the storage in the file on the resource host.

So, if the virtual machine is on shared storage and configured, the snapshot file is on local storage, then if you move the virtual machine to another host, there will be problems. If all of the virtual machine's files are on shared storage and accessible on all ESX hosts, the virtual machine is working. VMware recommends committing all snapshots before moving the virtual machine. But if you don't, you can work.