RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1439736 - hyperv vendor_id causes unknown cpu feature error
Summary: hyperv vendor_id causes unknown cpu feature error
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.4
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Jiri Denemark
QA Contact: zhe peng
URL:
Whiteboard:
Depends On: 1439424
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-04-06 12:42 UTC by Jiri Denemark
Modified: 2017-08-02 01:30 UTC (History)
6 users (show)

Fixed In Version: libvirt-3.2.0-2.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1439424
Environment:
Last Closed: 2017-08-02 00:05:54 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2017:1846 0 normal SHIPPED_LIVE libvirt bug fix and enhancement update 2017-08-01 18:02:50 UTC

Description Jiri Denemark 2017-04-06 12:42:15 UTC 
+++ This bug was initially created as a clone of Bug #1439424 +++

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):
3.2.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 comment from Jiri Denemark on 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 4 zhe peng 2017-06-12 07:55:09 UTC 
verify with build :
libvirt-3.2.0-9.x86_64

step:
1 prepare a win 10 guest with xml
<features>
    <acpi/>
    <hyperv>
      <vendor_id state='on' value='KVM Hv'/>
    </hyperv>
  </features>
2 start the guest
3 # virsh start win
Domain win started

no error, check qemu cmd line
.....
-cpu qemu64,hv_vendor_id=KVM Hv
.....

mover to verified.
Comment 5 errata-xmlrpc 2017-08-02 00:05:54 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2017:1846
Comment 6 errata-xmlrpc 2017-08-02 01:30:05 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2017:1846
Note You need to log in before you can comment on or make changes to this bug.