Re: [Qemu-devel] [RFC PATCH v2 00/16] visitor+BER migration format

[Dr. David Alan Gilbert]

* Markus Armbruster (address@hidden) wrote:
> "Dr. David Alan Gilbert" <address@hidden> writes:
> 
> > * Eric Blake (address@hidden) wrote:
> >> On 04/23/2014 10:37 AM, Dr. David Alan Gilbert (git) wrote:
> >> > From: "Dr. David Alan Gilbert" <address@hidden>
> >> > 
> >> 
> >> >    4) At the moment you select BER output format by setting an 
> >> > environment
> >> >       variable ( export QEMUMIGFORMAT=BER ) , I need to put more thought
> >> >       in to the right way to do this, there are some harder questions 
> >> > like
> >> >       what happens to devices that are still using pre-vmstate encodings
> >> >       (that are currently sent as blobs) when they eventually convert 
> >> > over
> >> >       and thus how to keep compatibility with earlier BER output versions
> >> >       where they were blobs.
> >> 
> >> I don't have good advice on how to address intra-version design (what
> >> happens when an old version of BER sends a blob but a new version on the
> >> receiving side expects formatted data instead of a blob), other than
> >> it's going to be similar to any other intra-version design that we
> >> already have to consider when upgrading from old to new qemu.
> >> 
> >> But for how to select BER format, I _do_ have an idea:
> >> 
> >> https://lists.gnu.org/archive/html/qemu-devel/2014-04/msg00782.html
> >> 
> >> Basically, I think that the choice of migration format should be
> >> selected via a new extended capability added to
> >> migrate-set-capabilities.  Setting the choice at the environment
> >> variable is too inflexible (it's locked down for the duration of the
> >> entire qemu process), whereas setting it via QMP is desirable (for
> >> example, it would let us choose at the time of migration whether we are
> >> migrating to an older host and want the old format, or migrating to a
> >> file for checkpointing reasons and want the new format).
> >
> > Yep, that would certainly be easy to do - and I can do that for
> > the next version.
> > It's more the intra-version I'm worried about, primarily because I don't
> > want to have to wait until every device is vmstate'd before moving this
> > code forward.
> >
> > The one thing that the environment variable does make nice and easy,
> > for dev, is using it with existing test setups - e.g. running virt-test
> > in BER mode or existing mode.
> 
> Sounds like a useful hack to speed up development, but not so much like
> a useful permanent API :)

Yep, I think what I'll do is go with Eric's suggestion of the 
migration-capability,
but initialise it based on the environment variable; then I can take that
out once it all settles out.

Dave
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK