Your message dated Fri, 28 Oct 2016 22:53:46 +0200 with message-id <20161028205346.csdexxjg5j2tq...@nana.phantasia.die-welt.net> and subject line Re: [Pkg-libvirt-maintainers] Bug#841778: fails to start qemu VMs when <model fallback='allow'>qemu64</model> is set has caused the Debian Bug report #841778, regarding fails to start qemu VMs when <model fallback='allow'>qemu64</model> is set to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 841778: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841778 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---Package: libvirt-daemon Version: 2.3.0-3 Severity: important Ohai, since some time (probably since 2.3.0, but I didn't test exactly), VMs created by vagrant-libvirt fail to start on my laptop with the following error: error: the CPU is incompatible with host CPU: Host CPU does not provide required features: svm Technically, this is totally true, as I have an Intel CPU, and thus have "only" support for vmx, not svm. The VM is defined with the following cpu config: <cpu mode='host-model'> <model fallback='allow'>qemu64</model> </cpu> Changing this to <cpu mode='host-model'> <model fallback='allow'/> </cpu> or <cpu mode='host-model'> <model fallback='allow'>pentium</model> </cpu> makes the VM boot just fine. In both cases the CPU visible inside the VM is a Nehalem/Westmere, which matches the physical i7 in my laptop. But the machine has no vmx flag, as I did not enable nesting for kvm_intel. Now the obvious questions are: * why does setting fallback to qemu64 fail? * why did it work before? * is it actually a libvirt bug, or should vagrant-libvirt behave differently? Greets Evgeni PS: My system is: model name : Intel(R) Core(TM) i7 CPU L 620 @ 2.00GHz flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt aes lahf_lm tpr_shadow vnmi flexpriority ept vpid dtherm ida arat -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libvirt-daemon depends on: ii libapparmor1 2.10.95-5 ii libaudit1 1:2.6.7-1 ii libavahi-client3 0.6.32-1 ii libavahi-common3 0.6.32-1 ii libblkid1 2.28.2-1 ii libc6 2.24-5 ii libcap-ng0 0.7.7-3 ii libdbus-1-3 1.10.12-1 ii libdevmapper1.02.1 2:1.02.133-1 ii libfuse2 2.9.7-1 ii libgnutls30 3.5.5-2 ii libnetcf1 1:0.2.8-1+b1 ii libnl-3-200 3.2.27-1 ii libnl-route-3-200 3.2.27-1 ii libnuma1 2.0.11-1 ii libparted2 3.2-16+b1 ii libpcap0.8 1.7.4-3 ii libpciaccess0 0.13.4-1 ii librados2 0.80.11-1.1 ii librbd1 0.80.11-1.1 ii libsasl2-2 2.1.26.dfsg1-15 ii libselinux1 2.5-3 ii libssh2-1 1.7.0-1 ii libudev1 231-9 ii libvirt0 2.3.0-3 ii libxen-4.6 4.6.0-1+nmu2 ii libxenstore3.0 4.6.0-1+nmu2 ii libxml2 2.9.4+dfsg1-2 ii libyajl2 2.1.0-2 Versions of packages libvirt-daemon recommends: ii libxml2-utils 2.9.4+dfsg1-2 ii netcat-openbsd 1.105-7 ii qemu 1:2.7+dfsg-1 ii qemu-kvm 1:2.7+dfsg-1 Versions of packages libvirt-daemon suggests: ii libvirt-daemon-system 2.3.0-3 -- no debconf information
--- End Message ---
--- Begin Message ---Hi, On Sun, Oct 23, 2016 at 05:02:31PM +0200, Guido Günther wrote: > > Now the obvious questions are: > > * why does setting fallback to qemu64 fail? > > * why did it work before? > > * is it actually a libvirt bug, or should vagrant-libvirt behave > > differently? > > I'd say vagrant-libvirt should use kvm64 (or better not specify a > fallback cpu at all). See here for some more details: > > https://www.redhat.com/archives/libvir-list/2016-May/msg01940.html > > I don't think there's a libvirt bug here. Right. I sent a PR to vagrant-libvirt not to set a fallback CPU at all. Closing here. Thanks for your input. Regards Evgeni
--- End Message ---
