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

[Markus Armbruster]

"Michael S. Tsirkin" <address@hidden> writes:

> On Thu, Apr 24, 2014 at 09:21:00AM +0100, Dr. David Alan Gilbert wrote:
>> * 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
>
> OK but for a new machine type, let's default to BER, right?
> I see no reason to keep supporting when non-BER when -M specifies 2.1
> compatibility, do you?

I fail to see the relation between machine type and migration's wire
encoding.