[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Configuring migration
|
From: |
Daniel P . Berrangé |
|
Subject: |
Re: Configuring migration |
|
Date: |
Tue, 14 Nov 2023 09:55:54 +0000 |
|
User-agent: |
Mutt/2.2.9 (2022-11-12) |
On Tue, Nov 14, 2023 at 10:53:20AM +0100, Markus Armbruster wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:
>
> > On Thu, Nov 02, 2023 at 03:25:25PM +0100, Markus Armbruster wrote:
> >> Now let's try to apply this to migration.
> >>
> >> As long as we can have just one migration, we need just one QAPI object
> >> to configure it.
> >>
> >> We could create the object with -object / object_add. For convenience,
> >> we'd probably want to create one with default configuration
> >> automatically on demand.
> >>
> >> We could use qom-set to change configuration. If we're not comfortable
> >> with using qom-set for production, we could do something like
> >> blockdev-reopen instead.
> >
> > Do we even need to do this via a QAPI object ?
>
> No. It's merely one way to skin the cat.
>
> > Why are we not just making the obvious design change of passing everything
> > with the 'migrate' / 'migrate-incoming' commands that kick it off:
> >
> > ie:
> >
> > { 'command': 'migrate',
> > 'data': {'uri': 'str',
> > '*channels': [ 'MigrationChannel' ],
> > '*capabilities': [ 'MigrateCapability' ],
> > '*parameters': [ 'MigrateParameters' ],
> > '*detach': 'bool', '*resume': 'bool' } }
> >
> > (deprecated bits trimmed for clarity)
> >
> > and the counterpart:
> >
> > { 'command': 'migrate-incoming',
> > 'data': {'*uri': 'str',
> > '*channels': [ 'MigrationChannel' ],
> > '*capabilities': [ 'MigrateCapability' ],
> > '*parameters': [ 'MigrateParameters' ] } }
> >
> > such that the design is just like 99% of other commands which take
> > all their parameters directly. We already have 'migrate-set-parameters'
> > remaining for the runtime tunables, and can deprecate the usage of this
> > when migration is not already running, and similarly deprecate
> > migrate-set-capabilities.
>
> We still need commands to adjust configuration while migration runs.
migrate-set-parameters will still satisfy that use case, we can allow
its usage when migration is active and deprecate its usage when migration
is not active
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|