On Wed, Mar 06, 2019 at 13:31:14 +0100, Jiri Denemark wrote:
On Wed, Mar 06, 2019 at 12:39:56 +0100, Peter Krempa wrote:
> On Wed, Mar 06, 2019 at 12:15:08 +0100, Jiri Denemark wrote:
[...]
So how about:
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.
ACK, this explains it nicely.