VMware Snapshot Overview

This post will talk about how VMware snapshots work, what they should and should not be used for, and provide a demonstration. A snapshot preserves the state and data of a virtual machine from a specific point in time. You can create multiple snapshots to save the virtual machine in different stages of a work process. Snapshots are managed using Snapshot Manager in the vSphere web client, or with PowerCLI. You should not manually alter any of the snapshot files as this may compromise the disk chain, with potential for data loss.

What happens when I take a snapshot?

When you take a snapshot of a virtual machine a number of files are created; a new delta disk (or child disk) is created for each attached disk, in vmdk format. The delta disks follow a naming convention and sequence of vmname-000001.vmdk, vmname-000002.vmdk and so on. These files are stored with the base vmdk by default. Any changes to the virtual machine are written to the delta file(s), preserving the base vmdk file. Think of this delta file as a change log, representing the difference between the current state and the state at the time the snapshot was taken. A .vmsd file is created to store the virtual machine snapshot information defining the relationships between child disks. A .vmsn file and corresponding .vmem file is created if the active state of the virtual machine memory is included in the snapshot. These configuration files are all stored in the virtual machine directory.


When should I use a snapshot?

Use a snapshot as a short term restore point when performing changes such as updating software versions or for testing software or configuration with unknown effects. You can create multiple snapshots of a virtual machine; VMware recommend no more than 32 snapshots in a chain, however best practise for performance is to keep it low, i.e. 2-3 snapshots.

Do not use a snapshot as a backup. Although it provides a restore point a snapshot relies on the base disk(s), without this the snapshot files are worthless. If you need a restore point for more than a few days then consider other options such as traditional backup, or cloning the virtual machine. According to vSphere best practises a single snapshot should not be used for more than 24 – 72 hours. There are a number of factors that determine how long a snapshot can be kept, such as the amount of changed data, and how the application will react to rolling back to a previous point in time. Some disk types and configurations are not supported by snapshots, you can see a full list of limitations here.

What are the risks of using a snapshot?

The more changes that are made within the virtual machine the more data is written to the delta file. This means the delta file grows quickly and in theory can grow as large as the virtual disk itself if the guest operating system writes to every block of the virtual disk. This is why snapshots are strictly a short term solution. Ensure there is sufficient space in the datastore to accommodate snapshots, if the datastore fills up any virtual machines residing in that datastore will be suspended.

How do I take a snaphot?

From the vSphere web client right click the virtual machine to snapshot, select Snapshots, and Take Snapshot. Note that vCenter Server is not a requirement, snapshots are also supported through the local ESXi host web UI.


Enter a name and description for the snapshot. The contents of the virtual machines memory are included in the snapshot by default, retaining the live state of the virtual machine. If you do not capture the memory state, then the virtual machine files require quiescing, otherwise should the virtual machine be reverted to a previous state; then the disks are crash consistent. The exception to this is taking a snapshot of a powered off virtual machine, as it is not possible to capture the memory state, or quiesce the file system.


To view active snapshots locate the virtual machine in the vSphere web client and select the Snapshot tab. Snapshots are listed in order with ‘you are here’ representing the current state, at the end of the snapshot chain.


It is possible to exclude disks by changing the disk mode to independent, covered here. However please use this option with care as it may have other implications. For example if your backup software uses snapshots as part of the backup process then setting independent disks may inadvertently exclude these disks from backups.

 How do I revert back to a snapshot?

Select the snapshot you want to revert back to, and click the revert icon in the top left of the snapshot menu. The icon dialog reads ‘revert the VM to the state it was in when the snapshot was taken’.


Review the confirmation message. The virtual machine state and data will be reverted back to the point in time when the selected snapshot was taken. The current state of the virtual machine (changes made since the snapshot was taken) will be lost unless you have taken a further snapshot. Click Yes to continue.


If you have multiple snapshots you will see the ‘you are here’ marker move to the point in the chain you have reverted to. Snapshots taken after this point are still valid and can be reverted to if required. After you have reverted to a snapshot you are happy with you need to save, or commit, the state of the virtual machine. More on this below.


How do I keep the state of the virtual machine?

When you keep the current state of the virtual machine the delta disks are merged with the base disks, committing the changes and the current state of the virtual machine. This is done by using the delete snapshot options in Snapshot Manager.

  • Delete All – deletes all snapshots from the virtual machine. This merges the delta disk(s) with the base disk(s) to save, or commit, the virtual machine data and configuration at the current point in time. If you have reverted to a snapshot you still need to delete all snapshots to start writing to the base disk again.
  • Delete – deletes individual snapshots from a chain; writing disk changes since the previous snapshot to the parent snapshot delta disk. If only a single snapshot exists then deleting this snapshot is the same as a Delete All for multiple snapshots; the VM state is committed and data is written to the base disk as normal.

Right click the virtual machine in the vSphere web client and select Snapshots, Manage Snapshots. From the All Actions menu select Delete Snapshot to delete the selected snapshot, or Delete All Snapshots. In this example we are deleting all snapshots, so click Yes to confirm.


All snapshots are now removed and the current state of the virtual machine is committed to the base disk. Any changes made from here on in are written to the base disk as normal, unless another snapshot is taken.


What is snapshot consolidation?

Snapshot consolidation is useful if a Delete or Delete All operation fails; for example if a large number of snapshots exist on a virtual machine with high I/O, or if a third party tool such as backup software utilising snapshots is unable to delete redundant delta disks. Using the consolidate option removes any redundant delta disks to improve virtual machine performance and save storage space. This is done by combining the delta disks with the base disk(s) without violating a data dependency, the active state of the virtual machine does not change.

To determine if a virtual machine requires consolidation browse to the vCenter Server, cluster, or host level in the vSphere web client and click the VMs tab. Right click anywhere in the column headers and select Show/Hide Columns. Tick Needs Consolidation and click Ok.


If a virtual machine requires consolidation right click and select Snapshots, Consolidate. There is also a default alarm defined at vCenter level for virtual machine consolidation needed.


From vSphere 6 onwards the snapshot consolidation process was improved. You can read more about the specifics, and testing, in this blog post by Luca Dell’Oca.

The snapshot functions described in this post can also be managed using PowerCLI, this blog post by Anne Jan Elsinga covers the commands you’ll need.

VMware Auto Deploy 6.x Guide

Auto Deploy has some great new features in vSphere 6.5 including a hugely improved and feature rich GUI built into the web client. The Auto Deploy Guide has been updated for vSphere 6.5 including a walk through of the Auto Deploy GUI and step by step creation of a custom ESXi image with deploy rules to boot ESXi hosts.


What is Auto Deploy?

VMware Auto Deploy works with Host Profiles to provision and customise your ESXi estate. When a host is deployed using Auto Deploy the state information is loaded to memory upon boot, the state is not permanently stored on the physical host by default. In theory this means there is no requirement for local storage, however we can configure stateless caching or stateful installs for use with a local drive if required.

What are the benefits?

After the initial setup you’ll benefit from quick and easy ESXi deployments, patches, driver updates, etc. provisioning of hosts on a mass scale all running the same version of code, huge savings in configuration times for new hosts and a more reliable and stable environment.

What do I need to make it work?

  • An Active Directory DNS, DHCP infrastructure already in place, you’ll need to enable DHCP options 66 and 67…

View original post 2,568 more words

VMware Update Manager 6.5 Install Guide

VMware vSphere 6.5 is scheduled to reach end of general support 15 October 2022, referenced in the VMware Lifecycle Matrix. See also How to Install vSphere 7.0. Upgrade to vSphere 7 can be achieved directly from vSphere 6.5.0 and above, whereas vSphere 6.0 requires an intermediate upgrade to 6.5 or 6.7 first. For more information see the VMware Upgrade Matrix. Finally, the Windows vCenter Server is now depreciated and not available with vSphere 7.0.

VMware Update Manager provides centralised patch and version management for ESXi hosts, virtual machines, and virtual appliances. Update Manager can be used to upgrade and patch ESXi hosts, install and update third-party software on hosts, upgrade virtual machine hardware, VMware Tools, and virtual appliances. This guide will cover the installation of VMware Update Manager 6.5 on Windows Server 2016. For further information on Update Manager performance and best practises, or for implementing an advanced topology in a large environment, see also the vSphere 6.5 Update Manager Performance and Best Practices post.


Architectural Considerations

  • Update Manager 6.5 is installed on a Windows server, this can be the same server as vCenter. The Update Manager Download Service can be used for secure environments with no internet access.
  • For the vCenter Server Appliance a separate installation is not required since Update Manager is now bundled into the VCSA.
  • Update Manager must be registered with a vCenter Server instance.
  • The following Windows deployment models are recommended by VMware:
    • All-in-one model; embedded database for small environments.
    • Medium deployment mode; Update Manager and vCenter Server installed on the same Windows server with separate external databases. Recommended for most environments.
    • Large deployment model; dedicated Windows server for Update Manager, separate to vCenter Server, with external database. Recommended for deployments where datacentre instances contain over 100 hosts and 1000 virtual machines each.

Software Considerations

  • Update Manager 6.5 requires vCenter Server v6.5, can be used to upgrade and patch hosts running ESXi 5.5 and above, and install VMware Tools for Windows and Linux guests.
  • Update Manager 6.5 requires a 64-bit version of Windows; Windows Server 2008 SP2 64-bit or later.
  • Microsoft .NET Framework 3.5 SP1 should be installed on the Windows server.
  • An external database should be Microsoft SQL Server 2008 R2 SP2 or above, or Oracle 11g or 12c. You can review a full list of compatible versions at the Database Interoperability Matrix.
  • The user requires Oracle DBA role, or SQL sysadmin server role, or db_owner fixed database role on the Update Manager and MSDB database.
  • For environments with up to 5 hosts and 50 VMs the bundled internal installation of SQL Server 2012 Express can be used.

Other Considerations

  • A dedicated Windows server requires a minimum of 2 GB RAM for Update Manager, where Update Manager is installed on the same Windows server as vCenter there should be a minimum of 8 GB RAM.
  • VMware recommend at least 120 GB of free space on the drive where the patching repository will be stored. Use the VMware Sizing Estimator to work out how the capacity required for your environment.
  • Update Manager connects to vCenter Server on TCP port 80. ESXi hosts connect to Update Manager using ports 9084 and 902. A full list of network port requirements can be viewed in this kb.
  • FA reboot is not required post-installation of Update Manager so there is no down time.
  • Official resources – Update Manager 6.5 Documentation Centre, vSphere 6.5 Release Notes

Create Data Source

Before beginning if you intend to use Update Manager with an external SQL database be sure to install the SQL Server Native Client (if vCenter Server is installed on the same Windows server using an external database then this is likely to be already installed).

You must also configure a 64-bit ODBC data source. Data sources can be configured in Windows Server via Control Panel > Administrative Tools > ODBC Data Sources (64-bit).


Click System DNS, Add and input the details for the external database, test the data source before continuing.


Download the VMware vCenter Server and modules for Windows VMware Downloads; this includes VMware Update Manager 6.5. Mount the ISO and right click autorun.exe, click Run as administrator. Select Server under the vSphere Update Manager menu, tick the Embedded Database Option to include the Microsoft SQL Server 2012 Express installation. Do not select this box if you intend on connecting to an external database. Click Install.


Select the installation language and click Ok, then click Next to begin the install wizard.


Accept the license agreement and click Next.


Review the support information, if the Update Manager instance will not have access to the internet untick Download updates from default sources immediately after installation, otherwise click Next.


Enter the information for the vCenter Server and click Next.


If you are using an external database select the Data Source Name for the database and click Next. Select how Update Manager should be identified, host name or IP, accept the default ports and configure a proxy server if required, then click Next.


Review the default installation locations, change if necessary, and click Next.


If the installation destination has less than 120 GB of available space you will receive the warning below, click Ok to continue.


Click Install to begin the installation.


The installation progress status bar will be displayed.


Once installation is complete click Finish.



After the installation has completed an Update Manager option will be added to the vSphere web client home page in the navigation panel.

Select the newly installed Update Manager. Here you can configure basic settings such as a download schedule, the default settings are pre-configured to get you up and running. Let’s have a quick look through the other tabs.


Hosts Baselines and VM Baselines tabs list Baselines which are attached to hosts or virtual machines. A baseline contains patches, an upgrade image, etc.


The Patch Repository contains downloaded patches, these can be attached to a baseline.


ESXi images can be imported via the ESXi Images tab, these are uploaded as an ISO and can be vanilla ESXi images, vendor provided images, or custom created images. For assistance with creating custom ESXi image using the ESXi Image Builder see the VMware Auto Deploy Guide.


The Update Manager settings are all fairly intuitive; download updates or upload an ESXi image, and create a baseline. Once you have a baseline go to the hosts and clusters view, select the host or virtual machine to update and browse to Manage > Update Manager.

Here you can attach baselines, check compliance, scan for updates, stage patches (downloads but doesn’t install), remediate patches (installs, host will be rebooted), or return to the Update Manager admin view.


The Windows client cannot be used to administer Update Manager 6.5 since it is not supported in vSphere 6.5 onwards.