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: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [RFC PATCH v2 00/16] visitor+BER migration format
Date: Wed, 7 May 2014 12:57:34 +0300

On Wed, Apr 23, 2014 at 12:57:43PM -0600, Eric Blake wrote:
> On 04/23/2014 11:54 AM, Michael S. Tsirkin wrote:
> > On Wed, Apr 23, 2014 at 11:47:21AM -0600, Eric Blake wrote:
> >> On 04/23/2014 11:16 AM, Dr. David Alan Gilbert wrote:
> >>> 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.
> >> Hmm. Maybe a compromise - an environment variable determines the default
> >> state of the QMP capability (for use in running the testsuite in one
> >> mode or the other for all tests that don't explicitly set a mode), but
> >> the QMP command still allows toggling the state at runtime (the
> >> environment variable doesn't lock us out from changing away from the
> >> startup default).
> > 
> > Eric, could you explain the need for the runtime thing?
> 
> I thought I did - when migrating across machines to what we know is an
> older qemu, we want the old migration format; but when migrating to a
> file to be reloaded by the current (or newer) qemu, we want the new
> format since it is more robust.

It's more robust for adding new functionality/new machine types but for
old one I think we can assume it describes it sufficiently.

> But libvirt can't know up front whether
> the user starting a qemu instance has plans down the road of calling
> 'virsh save' (migrate to file) or 'virsh migrate' (migrate across
> machines) first.
> 
> On the other hand, you have a point that upstream tends to not care
> about migration from new qemu to old (that's one of the value-added
> tasks of downstream distros), and that we could merely get away with
> using the -m machine name as the witness of which form to use, with no
> need for an environment variable or any other runtime switch.
> 
> -- 
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
> 





reply via email to

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