On Thu, 13 May 2010 14:21:02 +0100 "Daniel P. Berrange" <berra...@redhat.com> wrote:
> On Thu, May 13, 2010 at 03:07:49PM +0200, Jes Sorensen wrote: > > On 05/13/10 15:04, Cole Robinson wrote: > > > On 05/13/2010 04:35 AM, Jes Sorensen wrote: > > >> On 05/12/10 22:48, Cole Robinson wrote: > > >> I think rather than 1, it would be better to add a patch to libvirt to > > >> catch both formats. I know Chris Lalancette already cooked up a patch > > >> for this. Combined with the 2) patch I just posted, and 3) I think that > > >> should take care of the problems. > > > > > > It doesn't solve the problem for existing libvirt installations. It's > > > not uncommon for users to track just the latest kvm releases without > > > upgrading libvirt: any future qemu or kvm release will break every > > > version of libvirt that exists today. Given that unfortunate case, I > > > still recommend reverting the 'PC' change at least for long enough for a > > > few fixed libvirt releases to make it into the wild. > > > > But that is no different from what we have today. Users who update their > > qemu and see issues with libvirt can also be asked to update libvirt. I > > have already had several cases where I needed to do that anyway. > > The general policy of QEMU has been to try and avoid known breakage of > existing apps unless unavoidable. This change introduced 100% guarenteed > breakage of every single deployment that exists today, for the sake of > removing 2 characters from a string. I really don't think this is a good > cost/benefit tradeoff & agree with Cole that I'd like to see this reverted > for the 0.13 release, and re-considered in a later release once we've had > a chance to get a preventative fix out for libvirt using -version-string > or equivalent. Agreed, we should improve client's life, not contribute with additional headaches. Regarding Cole's suggestion, instead of adding a new -version parameter you could connect to QMP, get this information from it and re-run QEMU, not sure if it's worth the trouble though.