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