]> xenbits.xensource.com Git - libvirt.git/commit
qemu: Don't set migration caps when changing postcopy bandwidth
authorJiri Denemark <jdenemar@redhat.com>
Tue, 5 Mar 2019 21:16:03 +0000 (22:16 +0100)
committerJiri Denemark <jdenemar@redhat.com>
Wed, 6 Mar 2019 12:57:25 +0000 (13:57 +0100)
commita1dec315c9ad87a198245db0077ef80778621392
tree0936b086ea10518d6e11ad2a289049c7f4cfa98d
parentf2cbb94eabdd5e3422c45b1afa48eb4c951c09e0
qemu: Don't set migration caps when changing postcopy bandwidth

The qemuMigrationParamsApply internal API was designed to apply all
migration parameters and capabilities before we start to migrate a
domain. While migration parameters are only passed to QEMU when we
explicitly want to set a specific value, capabilities are always either
enabled or disabled.

Thus when this API is called outside migration job, e.g., via a call to
qemuDomainMigrateSetMaxSpeed with VIR_DOMAIN_MIGRATE_MAX_SPEED_POSTCOPY
flag, we would call migrate-set-capabilities and disable all
capabilities. However, changing capabilities while migration is already
running does not make sense and our code should never be trying to do
so. In fact QEMU even reports an error if migrate-set-capabilities is
called during migration and qemuDomainMigrateSetMaxSpeed would fail
with:

    internal error: unable to execute QEMU command
    migrate-set-capabilities: There's a migration process in progress

With this patch qemuMigrationParamsApply never tries to call
migrate-set-capabilities outside of migration job. When the capabilities
bitmap is all zeros (which is its initial value after
qemuMigrationParamsNew), we just skip the command. But when any
capability bit is set to 1 by a non-migration job, we report an error to
highlight a bug in our code.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
src/qemu/qemu_migration_params.c