On 02/13/2012 07:32 AM, Jiri Denemark wrote:
On Fri, Feb 10, 2012 at 11:22:09 -0700, Eric Blake wrote:
On 01/30/2012 09:25 AM, Martin Kletzander wrote:
In qemu there are 2 cpu models (cpu64-rhel5 and cpu64-rhel6) not supported by libvirt. This patch adds the support with the flags specifications from /usr/share/qemu-kvm/cpu-model/cpu-x86_64.conf
Is it going to be an issue where we use libvirt on something like F16 where qemu does not have these machine names? Or is it okay for libvirt to have a larger list of machine names, to make out-of-box installation of newer libvirt onto older RHEL/CentOS machines just work with those new names?
It was designed to be okay. Libvirt checks what CPU models are supported by qemu and avoids passing unsupported models to qemu. After all, we support running libvirt with older releases of qemu (we don't force their git HEAD).
True enough.
Should this be a RHEL-specific patch for just the RHEL version of libvirt, rather than upstream?
I think having this patch in is better than the opposite :-) Allowing RHEL/CentOS users to install newer libvirt without losing functionality is nice and we already did so in the past:
commit ff88cd590572277f10ecee4ebb1174d9b70fc0d7 Author: Eric Blake <eblake@redhat.com> Date: Wed Jan 25 21:33:21 2012 -0700
qemu: support qmp on RHEL/CentOS qemu
Sure, use my own patch against me to make your point :) All right, I think we're in agreement: ACK to applying this one. Even though the machine names are specific only to the RHEL port of qemu, it is a common enough user base that it is worth supporting in out-of-the-box libvirt installs, rather than relegating this patch to only the RHEL backport of libvirt. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org