VMware Horizon Community
Suiname
Enthusiast
Enthusiast
Jump to solution

Snapshot bloat using linked clones

I currently have a VMware view test environment setup as follows:

1 ESXi 4.1 host

netapp SAN with a 250GB volume provisioned

1 120GB lun for linked clones, 1 60GB lun for the parent VMs

vCenter vsphere running on a windows server 08 R2 vm (also houses view composer)

1 view connection server running on a windows server 03 R2 vm

1 view security server running on a windows server 08 R2 vm

So far, I've been able to get the view environment running just fine. This is a pilot in its very infancy, so there are not a lot users (Usually 1 or 2 at a time max, with maybe 5 users overall). I've recently noticed that the storage I've allocated is being eaten up way more than I thought it would.

There are two VM parents, which have 2GB of RAM with a 25GB HD and 1GB of RAM with a 15GB HD, respectively. These are sitting on their own separate LUN. The first VM (2GB/25GB) has 2 clones and the second has 3 clones in a 120 GB LUN. When I browse this datastore in vSphere, I find this:

When looking at this chart, I see the virtual disk size is 32GB, which is just fine for 2 Replica VMs and 5 linked clones. The part that I find confusing is that the Snapshots are taking up 31.75GB. Upon further investigation by browsing the actual data store, I can see this:

This clone also has a snapshot file, which is about 7GB in size. I checked each clone, they all have this snapshot file. Furthermore, even the clones which are in the pool but not currently provisioned have this snapshot file sitting on the LUN.

Is there a setting within view that I have set which is unintentionally enabling this behavior, or does every linked clone have/need this snapshot? If this is not possible to disable, can someone explain to me its relevance/importance and whether or not I can delete these files? It seems to me that to have a snapshot of a linked clone is redundant and a waste of space, I already have a snapshot of the parent which I can revert to at any point if I need to.

0 Kudos
1 Solution

Accepted Solutions
mittim12
Immortal
Immortal
Jump to solution

Andre he is talking about the snapshot that is created on the clone in 4.5. This snapshot allows for a quick revert to base image when doing refreshes where as in previous versions it would have to delete the clone and build it new.

Suiname if you were to delete (commit) the snapshot it would place all the changes that had accumulated onto the initial VMDK so I don't think you would be saving any space there. If you were to revert to that snapshot it would clear out all of the space but that's the same as a refresh.






If you found this or any other post helpful please consider the use of the Helpful/Correct buttons to award points

Twitter: http://twitter.com/mittim12

View solution in original post

0 Kudos
7 Replies
Suiname
Enthusiast
Enthusiast
Jump to solution

Bump

0 Kudos
mittim12
Immortal
Immortal
Jump to solution

You haven't done anything wrong in your setup. When using linked clones the clone is based off the replica but the changes made inside the clone are kept and will grow over time. This is why it's vital to keep the virtual desktop as lean as possible in regards to installing applications, patches, and profiles. If you want to shrink the clone back down you can choose to refresh the clone which takes it back to the original state. This will lower the amount of storage being used but will also discard any changes that were made inside the clone. This website does an excellent job of explaining how clones work, http://myvirtualcloud.net/?p=1237.






If you found this or any other post helpful please consider the use of the Helpful/Correct buttons to award points

Twitter: http://twitter.com/mittim12

Suiname
Enthusiast
Enthusiast
Jump to solution

Thanks for your link, that was a very detailed step by step description of the provisioning process of linked clones. My specific question is about the snapshot files that are created on the clone. In your link, it shows during step 8 of the provisioning process "The View Manager Server powers off the clone and takes a snapshot of

the customised, powered off clone. The snapshot is called

“vdm-initial-checkpoint." I realize that this vdm-initial-checkpoint is what allows for refresh operations to occur, but it is also what is bloating my VMs (each of these vdm-initial-checkpoint snapshots is 7GB in size). I am wondering if I can safely delete these snapshots and just not use the refresh operation.

0 Kudos
AndreTheGiant
Immortal
Immortal
Jump to solution

During a pool deployment, the specified snapshot is cloned in a "special VM" called replica-*

Then linked clones are build on this VM.

So you can delete snapshots from golden image, but in this way you will not able to deploy new pool.

Andre

Andrew | http://about.me/amauro | http://vinfrastructure.it/ | @Andrea_Mauro
0 Kudos
mittim12
Immortal
Immortal
Jump to solution

Andre he is talking about the snapshot that is created on the clone in 4.5. This snapshot allows for a quick revert to base image when doing refreshes where as in previous versions it would have to delete the clone and build it new.

Suiname if you were to delete (commit) the snapshot it would place all the changes that had accumulated onto the initial VMDK so I don't think you would be saving any space there. If you were to revert to that snapshot it would clear out all of the space but that's the same as a refresh.






If you found this or any other post helpful please consider the use of the Helpful/Correct buttons to award points

Twitter: http://twitter.com/mittim12

0 Kudos
Suiname
Enthusiast
Enthusiast
Jump to solution

Thanks for your help, that answers my question.

0 Kudos
admin
Immortal
Immortal
Jump to solution

I am wondering why the snapshot is so big,  it seems to me quickprep does not do much things in terms of personalization.

Could anyone please explians why the vdm-initial-checkout is so  big?

Thanks in advance!

Rgds

Ted

0 Kudos