On 11/02/2012 07:48 PM, Eric Blake wrote:
+++ b/include/libvirt/libvirt.h.in @@ -3872,6 +3872,7 @@ typedef enum { VIR_DOMAIN_SNAPSHOT_REVERT_RUNNING = 1 << 0, /* Run after revert */ VIR_DOMAIN_SNAPSHOT_REVERT_PAUSED = 1 << 1, /* Pause after revert */ VIR_DOMAIN_SNAPSHOT_REVERT_FORCE = 1 << 2, /* Allow risky reverts */ + VIR_DOMAIN_SNAPSHOT_REVERT_STOPPED = 1 << 3, /* Revert into stopped state */
Hmm, this might even be the argument I was looking for earlier about whether it makes sense to mix QUIESCE and memory state (still, using QUIESCE only makes sense for non-LIVE checkpoints). If we are going to revert into a stopped state, that means that we are going to be using the disk state without any memory and so no in-flight I/O; if that is to be allowed, we want a way to quiesce then pause the domain then save state, so we can make up our mind whether to restore just the disk state or everything; but it would also mean that the saved ram state needs to flag that it was done while the guest was quiesced, so that the first thing done on a non-stopped revert is to thaw the guest file system.
On the other hand, I don't know how many people will revert to just disk state and not also load up the associated RAM state. This flag might not get much use.
I thought about it a bit more; this flag is useful after all for reverting to the point of a snapshot without running, because we can then inspect disk state, and when ready to run, do yet another revert without the flag to restore any in-flight I/O. Again, I don't know how often it will be used, and whether we should worry about allowing one to mix quiesce with non-live external snapshots, but I agree with adding the flag. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org