"Michael S. Tsirkin" <m...@redhat.com> writes: > On Thu, Apr 24, 2014 at 09:21:00AM +0100, Dr. David Alan Gilbert wrote: >> * Markus Armbruster (arm...@redhat.com) wrote: >> > "Dr. David Alan Gilbert" <dgilb...@redhat.com> writes: >> > >> > > * Eric Blake (ebl...@redhat.com) wrote: >> > >> On 04/23/2014 10:37 AM, Dr. David Alan Gilbert (git) wrote: >> > >> > From: "Dr. David Alan Gilbert" <dgilb...@redhat.com> >> > >> > >> > >> >> > >> > 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.
