[forgot list]
On 07/13/2010 08:21 PM, Cole Robinson wrote:
On 07/13/2010 01:12 PM, Daniel P. Berrange wrote:
On Tue, Jul 13, 2010 at 06:56:53PM +0200, Thomas Treutner wrote:
So my question: Would it be possible to extend the migrate() method
resp. virDomainMigrate() function with an optional maxDowntime parameter
that is passed down as QEMU_JOB_SIGNAL_MIGRATE_DOWNTIME so that
qemuDomainWaitForMigrationComplete would set the value? Or are there
easier ways?
That approach really desirable IMHO, because it is already possible
todo this using threads, which is already neccessary for the other
APIs you can invoke during migration. If you care about the
max downtime parameter, then you almost certainly need to care about
calling virDomainGetJobInfo() in order to determine whether the
guest is actually progressing during migration or not.
Also sounds like it would be handy to allow globally configuring the
default migration downtime in /etc/libvirt/qemu.conf
Yep, that would be at least something. I'd even doubt that the qemu
default value makes sense at all, in more than one way:
1) When I set 100ms, the last jobinfo I see says approx. 80MByte
remaining. Over Gbit Ethernet, it would take about 0.5s to transfer
that, in the ideal case. A flooding ping says about 800ms max delay.
Maybe there's a bit/Byte-bug lurking around somewhere in qemu? (100ms
vs. 800ms)
2) Even if there's no bug, the 30ms look far too optimistic to me. As I
said, unless the VM is only moderately loaded (<50%), migrations never
finish and would run forever, I assume. I suggest that the default value
should be higher and/or some action should be taken if the migration can
not be done within some time or iteration limit (IIRC Xen takes the
iteration approach). One can argue whether the action should be abortion
or just-do-it, but I think there should be definitively *some* action to
have a sane default without tracking a migration process in each and
every software built on libvirt/qemu. (Yes, it's primarily a qemu issue,
but there are lots of other optional, driver-specific things in libvirt
too).
I'd find it even more interesting to have the downtime as a part of the
domain config, with choices/values for timeouts and the respective
action, but that's a lot of wishes and would need hypervisor support.
regards,
-t
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list