From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Nikita <nikita.lapshin@openvz.org>
Cc: qemu-devel@nongnu.org, den@virtuozzo.com,
andrey.drobyshev@virtuozzo.com, quintela@redhat.com,
dgilbert@redhat.com
Subject: Re: [PATCH 1/8] migration: Implemented new parameter stream_content
Date: Thu, 16 Jun 2022 14:10:35 +0100 [thread overview]
Message-ID: <Yqsry0i4FtC8MpnD@redhat.com> (raw)
In-Reply-To: <7d86202a-5d77-a12d-9022-5bc0315af76b@openvz.org>
On Thu, Jun 16, 2022 at 03:53:29PM +0300, Nikita wrote:
>
> On 6/16/22 1:32 PM, Daniel P. Berrangé wrote:
> > On Thu, Jun 16, 2022 at 01:19:57PM +0300, nikita.lapshin@openvz.org wrote:
> > > From: Nikita Lapshin <nikita.lapshin@openvz.org>
> > >
> > > This new optional parameter contains inormation about migration
> > > stream parts to be sent (such as RAM, block, bitmap). This looks
> > > better than using capabilities to solve problem of dividing
> > > migration stream.
> > >
> > > Signed-off-by: Nikita Lapshin <nikita.lapshin@openvz.org>
> > > ---
> > > migration/migration.c | 47 ++++++++++++++++++++++++++++++++++++++++++-
> > > migration/migration.h | 2 ++
> > > qapi/migration.json | 21 ++++++++++++++++---
> > > 3 files changed, 66 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/qapi/migration.json b/qapi/migration.json
> > > index 18e2610e88..80acf6dbc3 100644
> > > --- a/qapi/migration.json
> > > +++ b/qapi/migration.json
> > > @@ -760,6 +760,12 @@
> > > # block device name if there is one, and to their node name
> > > # otherwise. (Since 5.2)
> > > #
> > > +# @stream-content-list: Parameter control content of migration stream such as RAM,
> > > +# vmstate, block and dirty-bitmaps. This is optional parameter
> > > +# so migration will work correctly without it.
> > > +# This parameter takes string list as description of content
> > > +# and include that part of migration stream. (Since 7.0)
> > > +#
> > > # Features:
> > > # @unstable: Member @x-checkpoint-delay is experimental.
> > > #
> > > @@ -780,7 +786,8 @@
> > > 'xbzrle-cache-size', 'max-postcopy-bandwidth',
> > > 'max-cpu-throttle', 'multifd-compression',
> > > 'multifd-zlib-level' ,'multifd-zstd-level',
> > > - 'block-bitmap-mapping' ] }
> > > + 'block-bitmap-mapping',
> > > + 'stream-content-list' ] }
> > > ##
> > > # @MigrateSetParameters:
> > > @@ -925,6 +932,12 @@
> > > # block device name if there is one, and to their node name
> > > # otherwise. (Since 5.2)
> > > #
> > > +# @stream-content-list: Parameter control content of migration stream such as RAM,
> > > +# vmstate, block and dirty-bitmaps. This is optional parameter
> > > +# so migration will work correctly without it.
> > > +# This parameter takes string list as description of content
> > > +# and include that part of migration stream. (Since 7.0)
> > > +#
> > > # Features:
> > > # @unstable: Member @x-checkpoint-delay is experimental.
> > > #
> > > @@ -960,7 +973,8 @@
> > > '*multifd-compression': 'MultiFDCompression',
> > > '*multifd-zlib-level': 'uint8',
> > > '*multifd-zstd-level': 'uint8',
> > > - '*block-bitmap-mapping': [ 'BitmapMigrationNodeAlias' ] } }
> > > + '*block-bitmap-mapping': [ 'BitmapMigrationNodeAlias' ],
> > > + '*stream-content-list': [ 'str' ] } }
> > > ##
> > > # @migrate-set-parameters:
> > > @@ -1158,7 +1172,8 @@
> > > '*multifd-compression': 'MultiFDCompression',
> > > '*multifd-zlib-level': 'uint8',
> > > '*multifd-zstd-level': 'uint8',
> > > - '*block-bitmap-mapping': [ 'BitmapMigrationNodeAlias' ] } }
> > > + '*block-bitmap-mapping': [ 'BitmapMigrationNodeAlias' ],
> > > + '*stream-content-list': [ 'str' ] } }
> > These will need to be represented using an enum type rather than
> > a string, since this value accepts a fixed pre-determined list of
> > strings.
> >
> > With regards,
> > Daniel
> First of all thank you for your review!
>
> May be I misunderstood you, but is enum convenient for this purpose? List
> for describing looks pretty good.
>
> Or you mean that it is better to use list of enums?
Yes, sorry, I meant list of enums, so
'*stream-content-list': [ 'MigrationSteamContent']
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 :|
next prev parent reply other threads:[~2022-06-16 13:35 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-16 10:19 [PATCH 0/8] New parameter for migration stream nikita.lapshin
2022-06-16 10:19 ` [PATCH 1/8] migration: Implemented new parameter stream_content nikita.lapshin
2022-06-16 10:32 ` Daniel P. Berrangé
2022-06-16 12:53 ` Nikita
2022-06-16 13:10 ` Daniel P. Berrangé [this message]
2022-06-16 13:22 ` Nikita
2022-06-16 10:19 ` [PATCH 2/8] migration: should_skip() implemented nikita.lapshin
2022-06-16 10:19 ` [PATCH 3/8] migration: Add vmstate part of migration stream nikita.lapshin
2022-06-16 10:20 ` [PATCH 4/8] igration: Add dirty-bitmaps " nikita.lapshin
2022-06-16 10:20 ` [PATCH 4/8] migration: " nikita.lapshin
2022-06-16 10:20 ` [PATCH 5/8] Add block " nikita.lapshin
2022-06-16 10:22 ` Nikita
2022-06-16 10:20 ` [PATCH 5/8] migration: " nikita.lapshin
2022-06-16 10:20 ` [PATCH 6/8] migration: Add RAM " nikita.lapshin
2022-06-16 10:20 ` [PATCH 7/8] migration: analyze-migration script changed nikita.lapshin
2022-06-16 10:20 ` [PATCH 8/8] migration: Test for RAM and vmstate parts nikita.lapshin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yqsry0i4FtC8MpnD@redhat.com \
--to=berrange@redhat.com \
--cc=andrey.drobyshev@virtuozzo.com \
--cc=den@virtuozzo.com \
--cc=dgilbert@redhat.com \
--cc=nikita.lapshin@openvz.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.