Why does it take so long to delete a virtual machine with snapshots? [Hyper-V]

Why does it take so long to delete a virtual machine with snapshots? [Hyper-V]

  • Comments 8

You may have noticed that if you try to delete a virtual machine with snapshots associated with it – it can take quite a long time for the virtual machine to complete deleting.  The reason for this is that we are “cleaning up” the snapshot files – which may involve merging AVHD files.

Let’s imagine that you had performed to following steps:

  1. Created a blank virtual machine
  2. Installed Windows Vista
  3. Taken snapshot “Windows Installed”
  4. Installed Microsoft Office
  5. Taken snapshot “Office Installed”
  6. Written your life's memoirs
  7. Taken snapshot “Finally done”
  8. Installed Windows Live
  9. Taken snapshot “Live installed”
  10. Applied snapshot “Finally done”

It is our belief that if you were to delete the virtual machine at this point in time – you would expect the virtual hard disk that is left over to contain Windows, Office and your memoirs – but not Windows Live.  To do this we need to merge in all of the changes from the first three snapshots, which can be quite a time consuming operation.  Essentially what we are doing is deleting each of the snapshots first (which can result in merging of AVHDs) and then deleting the virtual machine when that operation is finished.

The alternate options would be:

  1. Discard all the AVHD files.  Which in this case would leave you with a VHD with just Windows installed on it.
  2. Leave the AVHD files where they are.  Unfortunately – you may not always know where these files are, which could be quite problematic for cleaning up later.

If you have a virtual machine with snapshots that you want to delete quickly – and you do not care about the data that is stored in the virtual machine snapshots – you can do so by simply applying the first snapshot (in the above case “Windows Installed”) before deleting the virtual machine.

Cheers,
Ben

Leave a Comment
  • Please add 2 and 4 and type the answer here:
  • Post
  • I believe the best way to find the .avhd files is editing one of the XML files from the \Snapshots and searching for .avhd.

    The .avhd path would be included in each one of the associated snapshot's XML file.

    I am trying this solution now. Thanks one more time for your help!

    Denise Beadle

  • There's no need to find and delete the avhds manually as long as you take Ben's advice and apply the first snapshot.

  • The correct thing for any system to do when you click "delete the files" is delete all the files. There is no "undelete" in scvmm so it does not need a quick way to get back. It is absolute lunacy for it to spend an hour merging all the avhd files into one nice vhd file, which it then deletes!

    To think that people expect any files to be left over after you choose "delete" is just WRONG!

  • I have a complex image that I want to nuke as I have already backed it up to an external hard drive. Now it has been deleting for over an hour now and I'm not even at 1%,  does anyone at M/S actually use the delete function or do they hack the files manually which I'm tempted to do but now that I've started the delete I don't know what state my host will be in if I stop it. Might be time to swap back to VMWare...

  • And to add insult to injury, there's the whole import/export debacle. In any other virtualisation platform you can just "copy the files and start the vm". Not so with hyper-V! you have this silly import/export thing that creates ludicrous .EXP files, you have empty folders that have to exist or the import fails, and you have a completely unnecessary internal user-token-per-vm / ACL thing going on all of which adds up to a complete inability to move vms between servers unless you use SCVMM and ALL your hosts are on the same version. To me, it looks like deliberate obfuscation to keep you tied into a proprietary platform

  • It's been 9 months since my original post on this and still no sign of a fix for this appalling flaw. I have 5 hyper-v hosts managed by SCVMM. I'm trying to move a small (16Gb) VM from one host to another. It moved the files in 4 minutes but now it's been taking 39 minutes to "remove" the original, just because it has snapshots and hyper-v is now merging all those snapshots into one vhd file, which SCVMM will then immediately delete! There should be a new option ("destroy" would be a good choice), which plain and simply deletes the files. Like the AOL user who couldn't cancel his subscription because they kept trying to find reasons not to cancel the subscription... when i say "delete" I mean "delete" ! why is that so hard? Guess why am I moving my VM from one host to another? because the original host is short of disk space! but now it's going to run out completely (and pause ALL the vms so everyone is now going to shout at me) because we are in this wacky situation where deleting a VM is temporarily consuming more space as it merges all the snapshots.

  • Simple scenario - my VMs are taking up space and I need to delete one of them.

    I do not care about preserving snapshots - thats like saying whether you want to clean your house before it is buldozed.

    And I have started the delete process unaware of this complexity.

    Now I have to wait 5 hours before I get back my space and the worst part is you cant hack by delteing the vhd files as they are now being held open by hyper v. I am sure if I break the link and delete the vhd files, hyper v will freak out and my fear is that the rest of my VMs shouldnt get damaged when that happens.

  • Try this:

    1. stop the hyper-v service;

    2. goto the VM folder and delete it;

    3. restart the hyper-v service, delete the VM.

Page 1 of 1 (8 items)