Bug 1439424 - hyperv vendor_id causes unknown cpu feature error
Summary: hyperv vendor_id causes unknown cpu feature error
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Jiri Denemark
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 1439736
TreeView+ depends on / blocked
 
Reported: 2017-04-06 00:43 UTC by Tobias Auerochs
Modified: 2017-04-06 12:47 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1439736 (view as bug list)
Environment:
Last Closed: 2017-04-06 12:47:30 UTC
Embargoed:


Attachments (Terms of Use)

Description Tobias Auerochs 2017-04-06 00:43:57 UTC
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

Comment 1 Peter Krempa 2017-04-06 06:37:16 UTC
Which version of qemu are you using?

Comment 2 Tobias Auerochs 2017-04-06 07:36:33 UTC
Running QEMU 2.8.0 from the Arch Linux repositories.

Comment 3 Jiri Denemark 2017-04-06 08:04:00 UTC
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?

Comment 4 Tobias Auerochs 2017-04-06 08:36:47 UTC
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

Comment 5 Jiri Denemark 2017-04-06 09:41:14 UTC
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.

Comment 6 Jiri Denemark 2017-04-06 12:38:41 UTC
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>

Comment 7 Jiri Denemark 2017-04-06 12:47:30 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.