Description of problem: Using the vendor_id option for hyperv in the domain xml prevents VM startup due to unknown cpu feature. Version-Release number of selected component (if applicable): 2.3.0 How reproducible: always Steps to Reproduce: 1. Create a new VM. (e.g. for Windows 10) 2. Edit the domain xml and add "<vendor_id state='on' value='whatever'/>" into the hyperv section. 3. Try to start the VM. Actual results: Virt-manager returns the following error and the VM is stopped: Error starting domain: internal error: unknown CPU feature __kvm_hv_vendor_id Expected results: The VM starting and hv_vendor_id being passed to the cpu argument for QEMU. Additional info: Full error in virt-manager: Error starting domain: internal error: unknown CPU feature __kvm_hv_vendor_id Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/asyncjob.py", line 88, in cb_wrapper callback(asyncjob, *args, **kwargs) File "/usr/share/virt-manager/virtManager/asyncjob.py", line 124, in tmpcb callback(*args, **kwargs) File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 83, in newfn ret = fn(self, *args, **kwargs) File "/usr/share/virt-manager/virtManager/domain.py", line 1479, in startup self._backend.create() File "/usr/lib/python2.7/site-packages/libvirt.py", line 1039, in create if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) libvirtError: internal error: unknown CPU feature __kvm_hv_vendor_id
Which version of qemu are you using?
Running QEMU 2.8.0 from the Arch Linux repositories.
Since you filed this bug against upstream and 2.3.0 is a pretty old libvirt, could you retry with the current libvirt 3.2.0?
Ah, my bad, I am running 3.2.0, mixed up the numbers in the report... Sorry for that. The issue started happening with 3.2.0, everything was fine with 3.1.0
Caused by commit e9dbe70110ac2d6ad8264c1c404e5ca4069e0e7b Author: Jiri Denemark <jdenemar> AuthorDate: Fri Mar 10 23:55:59 2017 +0100 Commit: Jiri Denemark <jdenemar> CommitDate: Fri Mar 17 11:50:48 2017 +0100 qemu: Refactor Hyper-V features check The checks are now in a dedicated qemuProcessVerifyHypervFeatures function. In addition to moving the code this patch also fixes a few bugs: the original code was leaking cpuFeature and the return value of virCPUDataCheckFeature was not checked properly. Signed-off-by: Jiri Denemark <jdenemar> but it probably just caused the preexisting bug to appear by fixing the way we check the return value of virCPUDataCheckFeature.
Fixed by commit ae102b5d7bccd29bc6015a3e0acefeaa90d097ac Refs: v3.2.0-53-gae102b5d7 Author: Jiri Denemark <jdenemar> AuthorDate: Thu Apr 6 13:52:30 2017 +0200 Commit: Jiri Denemark <jdenemar> CommitDate: Thu Apr 6 14:32:00 2017 +0200 qemu: Fix regression when hyperv/vendor_id feature is used qemuProcessVerifyHypervFeatures is supposed to check whether all requested hyperv features were actually honored by QEMU/KVM. This is done by checking the corresponding CPUID bits reported by the virtual CPU. In other words, it doesn't work for string properties, such as VIR_DOMAIN_HYPERV_VENDOR_ID (there is no CPUID bit we could check). We could theoretically check all 96 bits corresponding to the vendor string, but luckily we don't have to check the feature at all. If QEMU is too old to support hyperv features, the domain won't even start. Otherwise, it is always supported. Without this patch, libvirt refuses to start a domain which contains <features> <hyperv> <vendor_id state='on' value='...'/> </hyperv> </features> reporting internal error: "unknown CPU feature __kvm_hv_vendor_id. This regression was introduced by commit v3.1.0-186-ge9dbe7011, which (by fixing the virCPUDataCheckFeature condition in qemuProcessVerifyHypervFeatures) revealed an old bug in the feature verification code. It's been there ever since the verification was implemented by commit v1.3.3-rc1-5-g95bbe4bf5, which effectively did not check VIR_DOMAIN_HYPERV_VENDOR_ID at all. https://bugzilla.redhat.com/show_bug.cgi?id=1439424 Signed-off-by: Jiri Denemark <jdenemar>
This bug will be fixed in the next release of libvirt (which should be 3.3.0 in the beginning of May). The patch was also cherry-picked to v3.2-maint branch.