Please open a support case with relevant vdsm.log and engin.log for the time of snapshot deletion. We will be able to check where it was spending time.

The minimum time to finish the snapshot deletion would the time to merge this 60GB disk to another disk and may be convert it from qcow2 to raw. So if the storage is slow in write operations (like an nfs server on an overloaded RHEL system), it can potentially take this much of time. It all depends on the time it took to copy this 60GB to another disk.

Oh wow.

> The minimum time to finish the snapshot deletion would the time to merge this 60GB disk to 
> another disk and may be convert it from qcow2 to raw. So if the storage is slow in write
> operations (like an nfs server on an overloaded RHEL system), it can potentially take this much
> of time. It all depends on the time it took to copy this 60GB to another disk.

Hey Sadique - 

If I follow what you're saying, when you delete a RHEV snapshot and all the blocks merge back together again, you end up with one single virtual disk image file, right?  

If so, for Jan, even though RHEV snapshot deletion takes much longer than VMware, it might still be an advantage over VMware.  I know this seems nuts, but I have a quick story might change your mind.  

I was doing some V2Vs a couple years ago, migrating some VMware virtual machines to a RHEV environment.  Nothing worked and I was getting more frustrated by the day.  The VMware virtual machines had been snapshotted, but all the snapshots had been deleted.  Yet the V2V migration was still failing as if the source VM had snapshots.  Looking at the VMware storage with my vCenter client, I could see the .VMDK file and all the rest of the files describing that VM.  Each virtual disk had its own .VMDK file - but the names looked funny. 

The VMware host was a standalone ESXi machine and something told me to look at it from a different point of view.  So I booted it from a Fedora Live CD, mounted its filesystem and found those .VMDK files were  **NOT** single, individual files.  Each virtual disk image really consisted of several little VMDK files.  The VMware vCenter client presented each virtual disk as a single file, but looking at the raw directory from my Fedora Live CD, each of them was in fact several little files.  

That was why my V2Vs were failing - my V2V expected a single VMDK file, not a bunch of little files linked together by an index somewhere.  The cure - from the vCenter client, copy each VMDK disk image to a new directory.  This put my copied disk image back into a single file again and fixed my V2V migration.  The copy operations took a very long time btw.  

So apparently, when you get rid of a VMware snapshot, that snapshot virtual disk file stays in place.  It seems every time you make a new snapshot, you create a new virtual disk file and ***it stays around forever***, even after you delete the snapshot.  The stuff never merges back into the base image; VMware just presents it as if it does.  

There ain't no free lunch - when you delete a snapshot, you can either wait several  minutes one time for everything to merge back together again with RHEV, or you can slowly fragment your virtual disk across lots and lots of tiny little files and pay the price a little bit with each new snapshot.  

This could get really good.  One big-time use for snapshots is disaster recovery prep.  You have base images at both sites, then copy the snapshots periodically so the source site and DR site are reasonably close.  Let's say you do a snapshot every day and then delete the old snapshot after, say 5 days.  After one year with RHEV, you'll have one virtual disk file with 5 snapshot files.  I wonder if you really end up with 365 little .VMDK files with VMware?  

Think about the fragmentation if you have lots of virtual machines, each with lots of snapshots.  This might make for some interesting benchmark tests for the Red Hat marketing department.  :)

- Greg

> If I follow what you're saying, when you delete a RHEV snapshot and all the blocks merge back together again, you end up with one single virtual disk image file, right? 

It depends upon how many snapshots you have created. If you have created 3 snapshots, then there will be 4 images/lvs (base image + 3 snaps) in the qcow2 chain. If you delete 2nd snapshot, then second image will be merged to 3rd one before it's removed. So that makes the vm to have 2 snapshots with 3 images/disks.

To get the vm back entirely to a single image, you have to remove all snapshots.

So yes, below statement is 100% correct.

"Let's say you do a snapshot every day and then delete the old snapshot after, say 5 days.  After one year with RHEV, you'll have one virtual disk file with 5 snapshot files."