New subject: [Bug 987710] section "Guest CPU models" needs updating

24 Jul 2013


      https://bugzilla.redhat.com/show_bug.cgi?id=987710
Bug ID: 987710
           Summary: section "Guest CPU models" needs updating
           Product: Fedora Documentation
           Version: devel
         Component: virtualization-deployment-and-administrative-guide
          Assignee: lnovich@redhat.com
          Reporter: me@petetravis.com
        QA Contact: docs-qa@lists.fedoraproject.org
                CC: lnovich@redhat.com
The section "Guest CPU models" should be updated, comments below:
Background: 
- http://wiki.qemu.org/Features/CPUModels has the QEMU roadmap for relevant
features
- rawhide/F20 is currently shipping qemu-1.5.1
- F19 is currently shipping qemu-1.4.2
- F18 is currently shipping qemu-1.2.2
- Fedora ships qemu-kvm as /usr/bin/qemu-kvm not /usr/libexec/qemu-kvm
The first part of the section states CPU configurations are defined in XML
files rather than hardcoded; per the roadmap, they are again hardcoded to allow
compatibility code and more unified processor definitions. There's no
indication of backwards compatibility from qemu, although virsh and friends may
still accept .conf definitions and Know What To Do when talking to qemu.
In F18 and F19, `qemu-kvm -cpu ?cpuid` and `qemu-kvm -cpu ?dump` do not
function.
In F18, `qemu-kvm -cpu ?` gives a terse list of definitions.
in F19, `qemu-kvm -cpu ?` gives a more descriptive list, and also includes a
comprehensive list of recognized CPU flags. This could possibly replace
`?cpuid`
In both, `qemu-kvm -cpu <name>,enforce` functions as expected; this content is
commented out.
Looking further into comparing guest CPU features, I find `virsh capabilities`
will generate xml representing the host. It also appears to represent other
architectures that the host could emulate - if the appropriate packages (ie
qemu-arm ) are installed, and I correctly understand what they do.
There's also `virsh cpu-baseline` to generate a cpu definition that would allow
migration between file-defined hosts, and `virsh cpu-compare` to compare a
defined host with the local host. Both of these rely on [deprecated] xml .conf
cpu definition files. I haven't been able to find a more elegant way to compare
cpu configurations than scripting together the above virsh commands, presuming
`virsh capabilities` works the way I suspect.
The qemu roadmap cites `-cpu best` as a way to get the best CPU definition when
creating a guest - but it doesn't work here, and I'm not sure how it would make
a determination if it did.
A lot of the information I've discovered deals directly with qemu, not libvirt.
With qemu moving back to hard coded cpu definitions, I think it would be good
to get some insight on if libvirt tools are affected and how they are handling
the change. In general, I think it would be better to present libvirt commands
rather than commands executing qemu directly.
I'm not submitting a patch for this one because I'm not sure where to go with
it. It *seems* like libvirt should have a simple way to compare the
capabilities of heterogeneous hosts and aid in creating the best definitions
for guests.
-- 
You are receiving this mail because:
You are the QA Contact for the bug.

[Bug 987710] New: section "Guest CPU models" needs updating