Getting rid of disk-space hungry snapshots on VMware Server isn't a push-button task and requires a bit of creativity. This tip will offer some creative ideas for removing a snapshot chain in VMware Server in order to reclaim lost disk space.
Both VMware Workstation 5 and ESX 3 have snapshot managers that allow the creation of many snapshots. A series of snapshots is known as a snapshot chain, and each member of this chain is required, or else the chain is broken and the virtual machine (VM) will no longer function.
The snapshot managers in Workstation and ESX can remove older snapshots by collapsing the delta information back into the previous snapshot until at last there are no more snapshots. However, many people forget to delete these snapshots before moving a VM from Workstation or ESX to VMware Server, and VMware Server has no solution for deleting beyond the most recent snapshot. Many snapshots can consume large amounts of disk space; and because of the way snapshot chains work, it is not possible to simply delete the snapshot files.
Inside snapshots
To understand why it is not possible to simply remove snapshot files that belong to a snapshot chain requires a basic understanding of how snapshots work. When a snapshot is created in VMware Workstation, ESX, or VMware Server (Server) a new virtual hard disk file (VMDK) is created. All subsequent write operations are written to this new file; these are delta operations off of either the VM's original VMDK file or the previous snapshot.
The VM continues to function normally because, even though write operations are being flushed to a delta file, the underlying virtualization software is aware of the previous VMDK files. So, the snapshots that make up the snapshot chain and will read information from them as if all the data was grouped in a single container.
However, if any member of this snapshot chain were to be deleted then the virtual machine may be rendered unusable. Both Workstation's and ESX's snapshot managers can remove older snapshots by recombining these delta writes back into the previous snapshot or finally into the VM's original VMDK file. VMware Server does not possess the ability to create more than one snapshot at any given time and therefore it cannot remove more than the most recent snapshot.
Workstation 5 workarounds
The easiest way to recombine these snapshots into a single virtual hard disk file is to download a 30-day trial version of VMware Workstation 5. Using Workstation it is possible to clone a virtual hard disk or collapse a snapshot chain back to one virtual hard disk file. There may be cases though where Workstation is not an option, and since members of a snapshot chain cannot simply be erased, a little creativity is required.
These steps were validated by removing the snapshots from a VM running Windows XP SP2, but they will work for any guest operating system (OS) as long as the "dd" program has been ported to that OS.
- Shutdown the guest OS and power off the VM.
- Add a second hard drive to the VM that is the same size as the first hard drive. When adding the hard drive please do not add it in the same location as the original hard drive (this would be the directory that contains the VM's files). Instead, create a sub-folder called "disk1" in the VM's
directory and add new hard drive there. This will make it easier to differentiate the two hard drives' files later. It will be possible to differentiate the two hard drives in the guest OS because the hard drives will be labeled "Disk 0" and "Disk 1" in Windows and "/dev/sda" and "/dev/sdb" in UNIX or Linux.
- Power on the VM and wait for guest OS to boot.
- Log into the OS and initialize and format the new disk using the same
file system type as the original disk.
- Use "dd" to block-copy the contents of the original disk to the new disk.
"dd" is included with UNIX and Linux, but not Windows. There is a program
called WinDD for Windows that provides the same functionality and is freely
available at WinDD - Disk Dump for Windows.
- Shutdown the guest OS and power off the VM.
- Remove both hard drives from the VM.
- Create a sub-folder called "disk0" inside of the VM's directory and move
all of the VMDK files from the VM's directory into it.
- From a command line use the command "vmware-vdiskmanager" to expand the
new hard disk to the desired size. The syntax for this is:
vmware-vdiskmanager -x SIZE VMDK_FILE_PATH
This command is found in Windows at "C:\Program Files\VMware\VMware
Server\vmware-vdiskmanager.exe" (or whatever path VMware Server was
installed in) and in Linux at "/usr/bin/vmware-vdiskmanager".
Although VMware warns that this command should not be used to expand a
Windows system disk, it works fine. And if there is a problem, the original
hard disk files have not been deleted yet.
- Add the new hard drive back to the VM (leaving it in its own directory
for now).
- Mount a Windows XP/Vista ISO image if the VM's guest OS is Windows or a
Linux Live CD if the guest OS is Linux or Windows.
- Power on the VM and be sure to press the "ESC" key at boot time in order
to bring up the prompt that allows the boot device to be chosen. Boot from
the mounted ISO image.
- Both the Windows XP and Windows Vista installers have the ability to exit to the command prompt. Linux Live CDs can all access a terminal. Once at a command line use a disk utility program such as "diskpart" for Windows or "parted" for Linux to mark the first partition on the VM's new hard disk as active. The syntax for marking the first partition of the first disk active with "diskpart" is:
diskpart
select disk 0
select partition 1
active
The syntax for marking the first partition of the first disk active with
"parted" is:
parted
set 1 boot on
Please remember that these commands assume the hard disk has exactly one partition and that partition is the active/boot partition. The ideas behind these steps are still sound even with other partition schemes, but the actual commands must be edited to reflect the partition scheme in use.
- Unmount the ISO image and reboot the VM.
- The VM should now boot the guest OS from the new hard disk. If this does not happen then power off the VM and remove the new hard drive. Add the original hard drive and power on the VM. The guest OS should have no problems booting off the original hard drive. At this point please email this author at akutz at lostcreations dot com so that we can figure out what went wrong.
- If the VM boots successfully please go ahead and shut down the guest OS and power down the VM.
- Remove the new hard drive from the VM. Move the new hard drive's file from the "disk1" sub-folder into the root level of the VM's folder. Delete the "disk1" directory. Add the new hard drive back to the VM.
- At this point it is safe to delete the original hard drive's VMDK files by deleting the "disk0" directory. It may be a good idea to back these files up to an external hard drive and keep them around for a few weeks in case any problems with this operation crop up.
- Power on the VM, and watch the guest OS boot.
-
If you've stuck with the process all the way, lall the old snapshot files have been removed, freeing up precious disk space, and the guest OS was never the wiser.
If there any questions feel free to e-mail this author at editor@searchservervirtualization.com
About the author
Andrew Kutz is deeply embedded in the dark, dangerous world of virtualization. He is a Microsoft Certified Solutions Developer (MCSD), a SANS/GIAC Certified Windows Security Administrator (GCWN), and a VMware Certified Professional (VCP) in VI3. Andrew also recently submitted a security practical entitled "Sudo for Windows (sudowin)" to the SANS organization where it was accepted, thereby granting Andrew SANS GOLD status.
