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.
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
