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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list