[libvirt] libvirt(-java): virDomainMigrateSetMaxDowntime

[Daniel P. Berrange]

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 :|