Description of problem:
Currently it is only possible to delete one VM snapshot at a time. Depending on snapshot state the delete operation can take a non-trivial amount of time, which can add up quite a bit if you want to delete multiple snapshots (for example before reinstalling a Rawhide VM) as you have to delete one, confirm deletion, wait for the operation to finish - over and over again up to the last snapshot.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. make 2 or more snapshots for a VM
2. try to delete the snapshots
You can only delete the snapshots one by one.
You can select multiple VM snapshots (say using shift or "rubber band" selection) and delete them at once.
This is not possible at the qemu level, snapshot operations are currently synchronous and block all qemu monitor usage while they are being invoked.
That could possibly be 'fixed' by making the commands async, which there are vague plans to do, however two snapshot delete operations still likely wouldn't be able to take place automatically, since the data for all snapshots is stored in one file (the guest's qcow2 disk image). So really this fundamentally isn't possible given the way internal snapshots are architected. Closing this CANTFIX
However given all that, there's probably things we can do in virt-manager to make this more clear, since there's issues like your other bug reports
Well, I think I should have been more clear in my RFE - I didn't mean asynchronous snapshot removal (which would be indeed nice, but as I agree it is not doable at the moment) but "batch snapshot removal":
1) select a bunch of snapshots
2) click delete
3) confirm the deletion
4) Virt Manager deletes the snapshots sequentially
The main improvement being that the user does not need to manually delete & confirm deletion of every snapshots he wants to delete (not to mention the time spent checking if the current removal has finished so that the next one can be started) - thus saving the time of the user even though the deletion process itself running in the background still takes the same time.
Oh, sorry for the misunderstanding. That sounds feasible, at least worthy of investigating. Reopening, moving to the upstream tracker
fixed upstream by:
Author: Giuseppe Scrivano <firstname.lastname@example.org>
Date: Thu Jul 31 14:28:54 2014 +0200
snapshots: allow deleting multiple snapshots
Signed-off-by: Giuseppe Scrivano <email@example.com>