Managing snapshots for Linked Clone Pools

[tacticsbaby]

Greetings,

I am working with a linked clone pool that currently has a large number of snapshots. We want to keep the number of snaps as small as possible. What I want to know is what makes sense for managing snapshots on LC pools? We want to keep the snaps to a minimum, but not end up deleting a needed snap. What are best practices for managing these snapshots? Thanks in advance.

[VMMikeC]

I typically only keep the current snapshot and one previous snapshot. If I make changes to the Parent VM and take a new snapshot and then recompose my pool to that new snapshot.....after a few days or week, if nothing has broken, then really I shouldn't need previous snapshots.

I'm interested to see what others have to say

Mike

[kgsivan]

You can keep the snapshot in mutiple VMs too.

If you are planning to set 10 snapshots per VM , then at the 10th snapshot state make a full clone of the parent in the VC itself. Power on the cloned full clone and make necessaory changes and create a new snapshot. (This will become your 11th snapshot, being the first snapshot in a 2nd Parent VM).

Now while recomposing select the new parent VM and snapshot.

[tacticsbaby]

Thanks for the info. My main concern is that I am not backing myself into a corner when I have a number of pools that rely on those snaps. Am I missing something?

[mittim12]

I follow the same protocol as Mike.  I have my current snapshot and then I keep the previous snapshot until I am comfortable that everything is working correctly.   I find that having multiple layers of snapshots often gets confusing and could easily lead to trouble if you have multiple people creating and updating pools. 

[VMMikeC]

tactics,

I think you'll be fine. The only reason I can see having so many snapshots is if you're snapshots are containing different programs and certain pools are using a particular snapshot...For instance, Snapshot A has Firefox and Snapshot B has Internet Explorer...which personally, I'd like to hope is not the case. Although, it is possible, i think it would become way too confusing

Mike

[jsopper]

Vmware recommends keeping your snapshot count as low as possible, I would follow the previous recommendations of just keeping the current and one previous. If you need major difference base those snaps off different VMs. There have been occurrence with View where on VMs with very long snapshot chains that you can get a different image than the one you think you pointed to in the pool creation process. 

[enriquePulido]

How is that possible? Does this happen due to user error? Or does the system actually get confused? Also, what other negatives exists with having a long snapshot tree?

Is the replica affected in its creation or in the creation of linked clones?

[mchadwick19]

I believe the VMware training books say no more than 8 - 10. I took a class a year ago and it was mentioned that if the snapshot tree in string form gets too long, composer can fail.

On top of that, the longer the snapshot tree is, the longer the replica creation takes. The clone process needs to consolidate the snapshot disks as part of the cloning process and then vCenter needs to create the disk digest for that replica which does take longer the more snapshots you have. On a 70GB VM  with 2 snaps on all-flash storage, it takes 2 - 5 minutes, and then with 4 snaps it can take nearly 10.

We used to have a 300GB linked-clone image (CAD software suite) and we could only keep 2 snaps on it because the disk digest would take almost 90 minutes to complete and hit the Composer timeout.

In practice, I tend to keep previous, current production, and then while I'm working on changes I'll take multiple snaps for a test pool. Once the test image is vetted, all snaps between prod and prod.next get removed. Once the pool is pushed, usually a few days later I'll go and delete the "previous" snapshot.

Also, check you datastore(s) to make sure that your snaps aren't keeping other snaps that have been deleted in the past since they are part of that old chain. If that does happen you either need to get some maintenance time to disable provisioning for a bit, delete all snaps, take a new one, and then recompose your pool.