[libvirt] libvirt(-java): virDomainMigrateSetMaxDowntime
crobinso at redhat.com
Tue Jul 13 18:21:04 UTC 2010
On 07/13/2010 01:12 PM, Daniel P. Berrange wrote:
> On Tue, Jul 13, 2010 at 06:56:53PM +0200, Thomas Treutner wrote:
>> I'm facing some troubles with virDomainMigrate &
>> virDomainMigrateSetMaxDowntime. The core problem is that KVM's default
>> value for the maximum allowed downtime is 30ms (max_downtime in
>> migration.c, it's nanoseconds there; 0.12.3) which is too low for my VMs
>> when they're busy (~50% CPU util and above). Migrations then take
>> literally forever, I had to abort them after 15 minutes or so. I'm using
>> GBit Ethernet, so plenty bandwidth should be available. Increasing the
>> allowed downtime to 50ms seems to help, but I have not tested situations
>> where the VM is completely utilized. Anyways, the default value is too
>> low for me, so I tried virDomainMigrateSetMaxDowntime resp. the Java
>> wrapper function.
>> Here I'm facing a problem I can overcome only with a quite crude hack:
>> org.libvirt.Domain.migrate(..) blocks until the migration is done, which
>> is of course reasonable. So I tried calling migrateSetMaxDowntime(..)
>> before migrating, causing an error:
>> "Requested operation is not valid: domain is not being migrated"
>> This tells me that calling migrateSetMaxDowntime is only allowed during
>> migrations. As I'm migrating VMs automatically and without any user
>> intervention I'd need to create some glue code that runs in an extra
>> thread, waiting "some time" hoping that the migration was kicked off in
>> the main thread yet and then calling migrateSetMaxDowntime. I'd like to
>> avoid such quirks in the long run, if possible.
> Multiple threads is our recommended approach to the problem, since it is
> a general solution. eg you can call virDomainSuspend to pause the guest
> during migration & thus let it complete non-live. And virDomainGetJobInfo
> to check progress. And virDomainAbortJob to cancel.
>> 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
More information about the libvir-list