Re: [Qemu-devel] [PATCH v7 2/6] Introduce "save-devices-state"

[Stefano Stabellini]

On Fri, 16 Mar 2012, Eric Blake wrote:
> On 03/16/2012 06:13 AM, Stefano Stabellini wrote:
> > - add an "is_ram" flag to SaveStateEntry;
> > 
> > - register_savevm_live sets is_ram for live_savevm devices;
> > 
> > - introduce a "save-devices-state" QAPI command that can be used to save
> > the state of all devices, but not the RAM or the block devices of the
> > VM.
> > 
> 
> > +QEMU has code to load/save the state of the guest that it is running.
> > +These are two complementary operations.  Saving the state just does
> > +that, saves the state for each device that the guest is running.
> > +
> > +These operations are normally used with migration (see migration.txt),
> > +however it is also possible to save the state of all devices to file,
> > +without saving the RAM or the block devices of the VM.
> > +
> > +This operation is called "save-devices-state" (see QMP/qmp-commands.txt)
> 
> Is there a complimentary load-devices-state?

The generic loadvm function can be used with the device state on Xen,
see below.


> Just to make sure I'm clear, there are three things to save before you
> have a complete picture of a running VM:
> 
> disk state (can be saved with 'savevm' to internal qcow2 snapshots, or
> with 'transaction' and 'blockdev-snapshot-sync' by creating external
> snapshots, or by 'migrate' to a file)
> 
> RAM state (can be saved with 'savevm' to internal qcow2 snapshot, or
> with 'migrate' to a file; it is also possible to start qemu with a
> command line parameter telling which backing file tracks RAM state)
> 
> device state (can be saved with 'savevm' to internal qcow2 snapshot, or
> with 'migrate' to a file, and now with 'save-devices-state')
> 
> That is, 'migrate' does all three at once to an external file, 'savevm'
> does all three at once to an internal qcow2 snapshot, and you are now
> making it possible to do any one of the three independently to an
> external file while the VM continues to run.
> 
> Is this something that libvirt should be exposing in the near future?

I don't think so. It is useful under Xen where the RAM state and the
disk state are saved elsewhere. Libvirt is going to be a consumer of
this interface but only through libxenlight.


> Can we at least reserve something for future extension to add things
> like 'fd:name' to refer to a named fd received earlier via 'getfd'?  You
> could do that by documenting up front that if "filename" does not start
> with "/", then any pattern of letters followed by a ':' as the initial
> pattern of the filename is an error (and you avoid the error by using
> ./foo:... or an absolute path).
 
Yes, that can be done.