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. 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
signature.asc
Description: OpenPGP digital signature
