> I did some MORE testing. I obtain a domain object to a domain in two
> separate python processes. I begin migrating the domain in one of these
> processes, and then I call migrateSetMaxDowntime() on the domain in the
> other process. Unsurprisingly, the call is blocked and does not return
> until the migration finished. At that point it returned 0, but I have no
> idea whether the call had any impact on the running migration.
>
> Even more confused about how this is supposed to work now,
Hmm, the behavior you get is really weird. Most of libvirt APIs are
synchronous so they only return after the operation has finished. If you need
to do something else while the operation is running, you need a separate
connection to libvirt (opened in a separate process or thread) which you can
use for manipulating with other domains or, to some extent, even with the same
domain. In the migration case, you can use the second connection to monitor
migration progress (virDomainGetJobInfo), cancel the migration
(virDomainAbortJob), turn live migration into non-live migration
(virDomainSuspend), or setting maximum downtime
(virDomainMigrateSetMaxDowntime).
It's quite strange, that as you say you have two python processes and
virDomainMigrateSetMaxDowntime doesn't finish until the migration itself
finishes. I would suggest to start with a simple setup and try with virsh
migrate and virsh migrate-setmaxdowntime started from separate terminals, but
in your first email, you said you can't even run virsh list while migration is
running, right?
So could you make sure you have debug info libvirt packages installed or in
case you compile libvirt yourself that you compile with -g (should be there by
default) and don't strip binaries. Then try to get into the state, when a
migration is running and virsh list (or virsh migrate-setmaxdowntime) from
another terminal is blocked and attach gdb to libvirtd
gdb -p $(pidof libvirtd)
and type "thread apply all bt" in the gdb and send us the result.
I'm curious why it doesn't work for you.
Jirka
