On 03/13/2013 05:32 AM, Nicolas Sebrecht wrote:
Hi,
I'm trying to understand how the managedsave and restoration features work at the libvirt/qemu level.
I'd like to write a little python script to reproduce the feature to learn how it works. So, I start a kvm guest by hand with
qemu-kvm [...] -qmp tcp:localhost:4444,server
and connect to the QMP with telnet or the qemu qmp-shell for my tests.
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).
From what I've read, libvirt internally does a migration to a file: qemuDomainSaveMemory() -> qemuMonitorToFile() -> qemuMonitorMigrateToFd().
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.
What whould be the whole QMP/Monitor sequence of commands to handle the process?
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. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org