[Pkg-libvirt-maintainers] Bug#699813: libvirt refuses to use newer CPU models that are presented as default

[Philipp Kern]

On Mon, Feb 11, 2013 at 04:33:01PM +0100, Guido Günther wrote:
> > libvirt in wheezy calls qemu with -nodefconfig to query the supported CPU
> > models (-cpu ?). This ignores the cpu definition qemu ships
> > (/usr/share/kvm/cpus-x86_64.conf in qemu-kvm). When copying
> > the CPU flags of the host processor virt-manager will pick, in my case,
> > SandyBridge, which libvirt then discards as not being supported.
> > libvirt 0.9.13 will call qemu with -no-user-config[0], which will
> > still present the newer CPU models.
> I'm not sure I'm following. I do see that we're missing the
> -no-user-config patch in Wheezy's libvirt but if I read this correctly
> even with that patch applied you're not seeing the exected result which
> would be what exactly?

It should use -no-user-config, not -nodefconfig, as otherwise the models
defined in qemu's system configuration are not available. I didn't mean
to imply that it would not work after applying that patch.

My main point is that either virt-manager or libvirt from wheezy (I
don't know where it's coming from) propose SandyBridge as the default
CPU model on this machine (which, admittedly, is the closed match),
while it's not available on the hypervisor due to the odd qemu call
(i.e. KVM will fall back due to the global configuration not being
loaded).

Kind regards
Philipp Kern
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-libvirt-maintainers/attachments/20130211/2a2eb100/attachment.pgp>