The VMWare KB and multiple blogs state that long running snapshots are bad for both performance reasons and integrity. They have valid points.

Granted this is not with ESXi but rather Workstation\VirtualBox on a *NIX server I do see many blogs touting using LVM (or even ZFS) snapshots. Assuming LVM they essentially store their VMDKs on an LVM volume and take all the snapshots they want.

I don't see how this solution is practically any different than simply using the VMDK snapshots but VMWare mentions nothing bad about it from a performance or integrity perspective. A lot of blogs tout this as a snapshoting solution.

With that being said are Long running VMWare snapshots bad if they are not true VMWare snapshots but rather the VMDK on an LVM\ZFS volume?


A long-running snapshot is a snapshot that runs for a long time, even continuously. Let's assume I set up a few Windows VMs, snapshot them at the LVM level, and run them for a few weeks or months (perhaps even shapshotting throughout). When I want to roll back I simply roll back the snapshot to return to a previous version.

The VMWare KB specifically states (for native VMWare snapshots)

"Use no single snapshot for more than 24-72 hours. Snapshots should not be maintained over long periods of time for application or Virtual Machine version control purposes."

As we all know people run LVM\ZFS snapshots for enormous amounts of time with no ill effects.

  • It depends. Can you give more information about what you're trying to do? What is a "long-running snapshot" in your opinion?
    – ewwhite
    Nov 26, 2014 at 13:08
  • @ewwhite Clarified Nov 26, 2014 at 13:14
  • Why do you want to "roll them back"? You're very focused on wanting to do that. Being more specific on your reasoning can help see if there's a better solution to what you're trying to accomplish.
    – ewwhite
    Nov 26, 2014 at 13:16
  • 1
    Snapshots at the storage level are not the right solution for this. What version and license level of VMware are you using?
    – ewwhite
    Nov 26, 2014 at 14:29
  • 1
    VM_Storage_inception - @ewwhite has provided more or less the correct answer based on info provided. Basically you just have some bad assumptions going in regarding what snapshots are for. :) The gist of it, is regardless of virtualization solution (VMWare, KVM, Virtualbox, Xen) - create your "gold" template (thin provision to save on space) and then deploy your new VM(s) off of it. Snapshotting is for point in time rollbacks to real live data. Also keep in mind, you CAN'T EVER snapshot an AD Domain Controller, or any other clustered servers.
    – Jeff Burns
    Mar 8, 2015 at 16:24

3 Answers 3


Don't focus on snapshots. It's clouding your judgment :)

VMware has templating and cloning functionality built into vCenter. You need a $600 vSphere Essentials license to enable this.

You can create a VM to your taste, then clone it to a template. That template can then be used to generate new virtual machines.

This allows you to have a "clean state" but also create long-running or permanent VMs from that master image. No snapshots needed.

  • The problem with templates is you have to store a large OVA file for the template. Plus you have to redeploy the template. With snapshots it's a simple rollback. What are the issues with snapshots? Nov 26, 2014 at 14:57
  • I've given you the steps to do this the right way, as sanctioned by vmware. You don't have to listen or heed the advice...
    – ewwhite
    Nov 26, 2014 at 15:18
  • Also, I said nothing about OVA templates. Please read the linked documentation.
    – ewwhite
    Nov 26, 2014 at 15:26

I think that the root of this question is that there are two fundamentally different methods of doing snapshots.

A VMWare snapshot means that is halts writes to its primary disk and instead puts all writes into a separate snapshot disk. Reverting to this snapshot means discarding all the writes since it was taken (which causes very little overhead), however deleting it means applying the separated writes to the primary disk. This can be IO intensive, and can cause storage congestion because there's no way I know of to make this traffic have a lower priority than regular IO.

A storage snapshot can be done many ways, but none of them are like the above VMWare snapshot. They all have some sort of tradeoff, but none of them require a mass of updates to be sent as unprioritizable host IO to a storage device. Some examples of storage snapshots are copy-on-write, copy-after-write, and Netapp-style write anywhere snapshots.

  • Thank you for the clarification. In your opinion would Storage based snapshots cause an issue with VMDKs being stored on them? Nov 26, 2014 at 15:31
  • Assuming block based storage (iSCSI or FC LUNs), then snapshots are on the hardware and don't care whether the ones and zeros you write are a VMDK or a boot sector. If it's NFS, then snapshots will likely be more granular. The issues about snapshots depend on the method being considered. Copy-on-write snaps on a LUN, for example, will begin to degrade performance if you have too many snapshots, but not based on how long you keep them.
    – Basil
    Nov 26, 2014 at 20:42
  • 1
    @VM_Storage_Inception But if VMware isn't aware of the storage and the snapshotting technology, then yes, there's a problem. You'll have duplicate virtual machine IDs, and complications with registering the virtual machines with the ESXi host. Please try to understand the advice I'm giving you.
    – ewwhite
    Nov 28, 2014 at 23:23

Yes ZFS snapshoting works well for that, with no performance penalty for adding them as you please. (also easy to replicate for backup, etc)

However there isn't any coordination with vmware though so you do need to remove and re-add them to the inventory manually when you revert snapshots. Whether it is a particularly good solution for you depends very much on your workflow.

Also with any major time difference there are the usual restore issues with time syncing/domain auth, etc.

  • I was thinking of ZFS (allocating a large chunk of my VMFS datastore to a vSAN running ZFS), however doesn't ZFS require a lot of RAM\CPU? I'de rather not waste those resources on a vSAN. That's a good suggestion though. Dec 5, 2014 at 15:23
  • It is kind of a given that you can't have a storage solution without using the resource of a storage solution.
    – JamesRyan
    Dec 5, 2014 at 15:33
  • Heh I understand. The DAS for example is low overhead as far as CPU\Memory are concerned because it is DAS on a RAID card. Unfortunately VMWare snapshots suck!! Dec 5, 2014 at 15:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .