On Tue, Jul 13, 2010 at 09:23:37PM +0200, Thomas Treutner wrote: > [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). People have argued for the iterative + adaptive approach Xen uses to be applied in upstream QEMU, but the community has rejected it as a policy decision that belongs in the mgmt apps. Thus they only provide the progress info, migrate downtime tunable & the pause option and the ability to cancel a migration. libvirt then exposes these & its upto apps to dynamically manage it. IMHO this rather sucks for apps which don't care about this level of flexibility & would rather it 'just works' like Xen, but this discussion has been had & lost many times on qemu-devel now :-( Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list