On Thu, Sep 01, 2011 at 02:42:56PM -0600, Jim Fehlig wrote:
From: Jim Fehlig <jfehlig@novell.com>
The qemu migration speed default is 32MiB/s as defined in migration.c
/* Migration speed throttling */ static int64_t max_throttle = (32 << 20);
There's no need to throttle migration when targeting a file, so set migration speed to unlimited prior to migration, and restore to libvirt default value after migration.
Default units is MB for migrate_set_speed monitor command, so (INT64_MAX / (1024 * 1024)) is used for unlimited migration speed.
Tested with both json and text monitors. --- src/qemu/qemu_migration.c | 17 +++++++++++++++++ 1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index 38b05a9..ab38579 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -2700,6 +2700,16 @@ qemuMigrationToFile(struct qemud_driver *driver, virDomainObjPtr vm, bool restoreLabel = false; virCommandPtr cmd = NULL; int pipeFD[2] = { -1, -1 }; + unsigned long saveMigBandwidth = priv->migMaxBandwidth; + + /* Increase migration bandwidth to unlimited since target is a file. + * Failure to change migration speed is not fatal. */ + if (qemuDomainObjEnterMonitorAsync(driver, vm, asyncJob) == 0) { + qemuMonitorSetMigrationSpeed(priv->mon, + QEMU_DOMAIN_FILE_MIG_BANDWIDTH_MAX); + priv->migMaxBandwidth = QEMU_DOMAIN_FILE_MIG_BANDWIDTH_MAX; + qemuDomainObjExitMonitorWithDriver(driver, vm); + }
if (qemuCapsGet(priv->qemuCaps, QEMU_CAPS_MIGRATE_QEMU_FD) && (!compressor || pipe(pipeFD) == 0)) { @@ -2808,6 +2818,13 @@ qemuMigrationToFile(struct qemud_driver *driver, virDomainObjPtr vm, ret = 0;
cleanup: + /* Restore max migration bandwidth */ + if (qemuDomainObjEnterMonitorAsync(driver, vm, asyncJob) == 0) { + qemuMonitorSetMigrationSpeed(priv->mon, saveMigBandwidth); + priv->migMaxBandwidth = saveMigBandwidth; + qemuDomainObjExitMonitorWithDriver(driver, vm); + } + VIR_FORCE_CLOSE(pipeFD[0]); VIR_FORCE_CLOSE(pipeFD[1]); virCommandFree(cmd);
ACK, makes sense, my only worry would be handling of errors, for example if for some reason qemuMonitorSetMigrationSpeed() generate a failure, we ignore it, which may make sense for some kind of errors (like failure to understand the command) but I'm worried of more complex scenarios. Since I don't have one handy, I'm giving the ACK :-) Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/