[libvirt] Re: understanding managedsave

[Nicolas Sebrecht]

The 13/03/13, Eric Blake wrote:

> TCP QMP connections don't allow you to pass an fd via SCM_RIGHTS; that
> is only possible with a Unix socket.  If you insist on controlling your
> qemu with TCP instead of using libvirt, you'll have to use a slightly
> different approach (such as the exec: protocol instead of the fd:
> protocol as the destination for the qemu migration).

Ah, indeed! I'll switch to the Unix socket, then. :-)

> > Why do a migration instead of QMP stop/memsave?
> 
> Because memsave doesn't save enough information - to restore a guest
> from the same point, qemu needs to save device state in addition to
> memory contents.  The only qemu commands that do this are migration and
> savevm; but savevm has some severe limitations on usability, so our only
> option was to use migration to file.

Ok.

> You can ask libvirt to trace the exact sequence of QMP monitor commands
> that it issues, if that helps.  Run libvirtd with
> LIBVIRT_LOG_FILTERS=1:monitor set in the environment, or with
> log_filters defined in /etc/libvirt/libvirtd.conf (restart libvirtd to
> pick up on conf file changes), and the logs will then include details.
> 
> But in short, libvirt is using 'addfd' to pass a named fd to qemu, then
> using 'migrate' with type 'fd:name' to use that named fd as the target,
> on the save side.  On the restore side, libvirt uses the -incoming
> fd:nnn argument to tell qemu to read the incoming data from a stream.

This is usefull informations. I'll use the libvirt log trick to
trace what's happening.

Thank you very much Eric!

-- 
Nicolas Sebrecht