On Mon, Feb 13, 2012 at 03:32:26PM +0100, 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 --- v3: - fixed sse3 naming (it's 'pni' in the features)
v2: - removed duplicated entries
src/cpu/cpu_map.xml | 66 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 66 insertions(+), 0 deletions(-)
I'm assuming that you tested this (I did not spend the time meticulously cross-checking qemu with this list). Upstream qemu does not provide these machine names; they are RHEL-specific.
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).
One day we should just stop using '-cpu', and simply write out a config file where we can put a full '[cpudef]' definition, and pass it to QEMU using -loadconfig. This will allow us to specify precise CPU models, without being tied to particular QEMU versions. It will also allow the end user / mgmt app to define new CPU models for libvirt to use. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|