Question: Will the 'bandwidth' parameter of migrateToURI2() be ignored if it was previously set by the API migrateSetMaxSpeed()? Eric Blake writes (on #virt, 06FEB2018): Off-hand (without checking libvirt code), my understanding is that 'bandwidth' parameter of migrateToURI2 and migrateSetMaxSpeed() all tweak the same QEMU knob. The most recent tweak overrides all earlier tweaks. There's a race if migrateSetMaxSpeed() is called to set initial bandwidth after the migration is already started, which is why migrateToURI2 needs a bandwidth parameter. But what I'm less sure of is that if you call migrateSetMaxSpeed() before the migration, then pass '0' for the bandwidth on migrateToURI(), whether that undoes the earlier setting, or if 0 leaves bandwidth unchanged from its earlier setting. (Or in other words, I'm not sure whether the 'bandwidth' parameter to migrateToURI2 has a setting that says "keep my current settings" rather than "forcibly change to unlimited bandwidth"). Now looking in source code... qemu_driver.c:qemuDomainMigratePerform3Params() 'bandwidth' defaults to 0, remains 0 if the user didn't set the parameter or set the parameter explicitly to 0, then is passed on to qemuMigrationPerform. But I'm getting a bit lost tracing where bandwidth is actually modified by calling into QMP. qemu_migration.c:qemuMigrationToFile() temporarily clears any 'bandwidth' when migrating to file, then restores it afterwards; but nothing else in qemu_migration.c seems to pass bandwidth directly on to QEMU. Oh, there it is: qemu_migration.c:qemuMigrationRun() calls qemuMonitorSetMigrationSpeed() unconditionally using 'migrate_speed', which in turn is set to a non-zero parameter on input or to priv->migMaxBandwidth from an earlier setting So passing 0 DOES appear to defer to the previous migration speed setting.