qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dr. David Alan Gilbert
Subject: Re: [Qemu-devel] [RFC PATCH v2 00/16] visitor+BER migration format
Date: Wed, 23 Apr 2014 18:16:23 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

* 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.

Dave


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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]