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