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 >
