Raise your hand if you love dealing with virtual machine snapshots in vCenter? No? How about trawling through all your organisations many VMs to find those old snapshots taking up space and slowing down your on-premises infrastructure? Still no? Same here at CT4!
From our many years’ experience with managing virtual machines using VMware vCenter, we have discovered a couple of common and important issues when managing virtual machine snapshots. One problem is unknown snapshots (where you can’t tell what you have), and another is stale snapshots (where older snapshots increase disk usage and IO times).
At CT4, we use vSphere internally, and for our clients, so we have experience managing many VMs and their snapshots across many different clients. Our Service Desk often needs to manage snapshots created for many different purposes:
- Testing new software
- In preparation for operating system updates
- As part of the backup process
We have found that manually checking each VM, finding snapshots to tidy up, ranges from monotonous as you do the same clicking over again, to rage inducing as you lose count. Work stress issues aside, this process takes time and could be error-prone simply with machines easily missed.
When we were building Canopy, we worked with our internal Service Desk and their team members to understand how they use Snapshots in vCenter. Canopy makes it easy to find which virtual machines have snapshots by showing a simple icon beside the VM in the list.
From there you can:
- view all the snapshots hierarchy associated that VM,
- create new snapshots,
- delete existing snapshots,
- and (planned availability soon after Canopy’s public release) revert to the state of a snapshot
This simple UI will make it much easier to audit snapshots within your virtual machine infrastructure, even if (like us) you have a large number of assets and several snapshots within each asset.
Snapshots aren’t backups, and within the on-premises virtualisation community, there is a school of thought that they shouldn’t be kept around longer than a day or so. Having too many snapshots cause a performance overhead because vCenter must maintain RAM and disk changes in a more complex manner than normal. Of course, this performance overhead is acceptable if the snapshot is needed, but after it becomes “stale” (outlived its usefulness), writing to the snapshot is an unnecessary bottleneck.
After that time some action should be taken, or at least there should be a specific reason why they kept. Of course, what you may do with the snapshot depends on the asset and the reason the snapshot was created.
We have found within the community several causes of snapshots being left around after they should have been deleted or merged:
- that sometimes a snapshot is created as part of the backup process, but it isn’t merged when the backup is successful, and no one notices the error.
- a snapshot is created in preparation for an operating system update but isn’t merged when the stability is confirmed a couple of days later.
In Canopy, we have built a widget that simply shows any snapshots across all vSphere VMs older than a user-selectable time frame.
From this view you can easily “expand” a listing to see all the newer snapshots based on the oldest snapshot and go straight to that asset to manage it and the snapshots.
We originally started developing Canopy for the CT4 service desk to help them manage our clients’ virtual machines. We need to be able to see an overview of our assets and management easily. Snapshot Management is one of the features of Canopy our service desk is most excited about as it will help them to manage snapshots more efficiently.
Canopy will be available to the public later in 2018, in the meantime, you can request more information or a demo at Canopy Support.