6:32 a.m.
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.
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?
What whould be the whole QMP/Monitor sequence of commands to handle the
process?
--
Nicolas Sebrecht
9:40 a.m.
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
10:33 a.m.
New subject: [libvirt] Re: understanding managedsave
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
4272
days inactive
4272
days old
2 comments
2 participants
participants (2)
-
Eric Blake -
Nicolas Sebrecht