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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org