On 07/14/2013 05:34 AM, Paolo Bonzini wrote: >>> Such an incompatible change is not acceptable, as it would break >>> existing configurations. libvirt doesn't specify any suffix and expects >>> it to always mean "MB". >> >> Newer libvirt can be taught to append 'M' when it detects it is talking >> to newer qemu. While you have a point that it is annoying to force >> users to upgrade to a newer libvirt merely because they upgraded qemu, >> the libvirt point of view is that the following are supported: >> >> old libvirt -> old qemu >> new libvirt -> old qemu >> new libvirt -> new qemu >> >> but that this combination is always best effort and not required to work: >> >> old libvirt -> new qemu > > I don't think this is the case, unless you're talking of *very* old > libvirt (e.g. pre-QMP).
As a counter-example, I can recall a case where a qemu release that used just two digits (was that 1.2?) broke operation under older libvirt that assumed versions would always be three digits; but it definitely occurred after 0.15.x which is the point at which libvirt started favoring QMP. That is, we had a case in Fedora where if you upgraded qemu, you HAD to also update libvirt to be able to keep your guests running. But yes, the goal of having command line compatibility, so that any application using the same command line it always uses will get the same guest, regardless of a qemu upgrade in the meantime, should be our default mode of operation, even if newer apps should prefer newer (better) command line interfaces. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
