When trying to do detached migration with exec, I found that
the monitor wouldn't always return in a timely manner. I
tracked this down to exec_start_outgoing_migration. It
appeared we were setting the fd to NONBLOCK'ing, but in
point of fact we weren't.
This bugfix should also go onto the stable 0.10 branch
Signed-off-by: Chris Lalancette <clalance@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Glauber Costa <glommer@redhat.com>
Since migration returns right away, starting the VM right
after calling qemu_start_incoming_migration is wrong even
if -S is not passed. We have to do this after migration
has completed.
Cc: Glauber Costa <glommer@redhat.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Glauber Costa <glommer@redhat.com>
-S is not honored by qemu on incoming migration. If a domain is migrated
while paused, thus, it will start running on the remote machine; this
is wrong.
Given the trivial patch to fix this, it looks more like a thinko
than anything else, probably dating back to the qemu-kvm merge.
The interesting part is that the -S mechanism was in fact *used* when
migrating (setting autostart = 0) and the incoming migration code was
starting the VM at the end of the migration.
Since I was removing the vm_start from there, I also corrected a related
imprecision. The code was doing a vm_stop "just in case", but we can
be sure that the VM is not running---the vm_start call in vl.c has not
been reached yet. So the vm_stop is removed together with the vm_start.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
All,
I've recently been playing around with migration via exec. Unfortunately,
when starting the incoming qemu process with "-incoming exec:cmd", it suffers
the same problem that -incoming tcp used to suffer; namely, that you can't
interact with the monitor until after the migration has happened. This causes
problems for libvirt usage of -incoming exec, since libvirt expects to be able
to access the monitor ahead of time. This fairly simple patch allows you to
access the monitor both before and after the migration has completed using exec.
(note: developed/tested with qemu-kvm, but applies perfectly fine to qemu)
Signed-off-by: Chris Lalancette <clalance@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
In TCP migration, prevent an endless loop trying to retrieve error status. In
exec migration, set the close pointer in the FdMigrationState structure.
Color me embarrassed.
Signed-off-by: Charles Duffy <charles_duffy@messageone.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5713 c046a42c-6fe2-441c-8c8c-71466251a162
KVM's live migration support included support for exec: URLs, allowing system
state to be written or received via an arbitrary popen()ed subprocess. This
provides a convenient way to pipe state through a compression algorithm or an
arbitrary network transport on its way to its destination, and a convenient way
to write state to disk; libvirt's qemu driver currently uses migration to exec:
targets for this latter purpose.
This version of the patch refactors now-common code from migrate-tcp.c into
migrate.c.
Signed-off-by: Charles Duffy <Charles_Duffy@messageone.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5694 c046a42c-6fe2-441c-8c8c-71466251a162
Chris Lalancette