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

[Guido Günther]

Hi Philipp,
On Mon, Feb 11, 2013 at 04:47:55PM +0100, Philipp Kern wrote:
> 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).

I see. Any chance to check if 1.0.2 from experimental fixes this for
you? I'd be happy to backport the -no-user-config part for wheezy since
it's very unintrusive.
Cheers,
 -- Guido

> 
> Kind regards
> Philipp Kern