Bug 1439424
| Summary: | hyperv vendor_id causes unknown cpu feature error | |||
|---|---|---|---|---|
| Product: | [Community] Virtualization Tools | Reporter: | Tobias Auerochs <tobi291019> | |
| Component: | libvirt | Assignee: | Jiri Denemark <jdenemar> | |
| Status: | CLOSED NEXTRELEASE | QA Contact: | ||
| Severity: | unspecified | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | unspecified | CC: | jdenemar, libvirt-maint, rbalakri, tobi291019 | |
| Target Milestone: | --- | |||
| Target Release: | --- | |||
| Hardware: | x86_64 | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | ||
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1439736 (view as bug list) | Environment: | ||
| Last Closed: | 2017-04-06 12:47:30 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1439736 | |||
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. |
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