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 1275349 - detect ACPI-boot AArch64 guest VM
Summary: detect ACPI-boot AArch64 guest VM
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: virt-what
Version: 7.3
Hardware: aarch64
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Richard W.M. Jones
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On: 1360699
Blocks: 1212027 1288337 1301891
TreeView+ depends on / blocked
 
Reported: 2015-10-26 15:25 UTC by Andrew Jones
Modified: 2016-11-04 07:02 UTC (History)
10 users (show)

Fixed In Version: virt-what-1.13-7.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1360699 (view as bug list)
Environment:
Last Closed: 2016-11-04 07:02:43 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:2469 0 normal SHIPPED_LIVE virt-what bug fix update 2016-11-03 14:07:01 UTC

Description Andrew Jones 2015-10-26 15:25:14 UTC 
Now that QEMU populates SMBIOS, we can detect we're a QEMU guest without needing to boot with DT. Furthermore, SMBIOS even has information allowing us to know if KVM is used, so we should always check there first.
Comment 2 Andrew Jones 2015-10-26 15:29:06 UTC 
KVM detection depends on a QEMU with

bab27ea2e38: hw/arm/virt: smbios: inform guest of kvm

which hasn't yet been backported to RHEL7 QEMU.
Comment 3 Richard W.M. Jones 2015-10-27 09:00:19 UTC 
Is it just these commits, or do we need more?

http://git.annexia.org/?p=virt-what.git;a=commit;h=163024ab11d1ff722c40c517be2279469614bc37
http://git.annexia.org/?p=virt-what.git;a=commit;h=1b0df165bad0cebbff2c1a5b234672a647ea75eb
Comment 4 Andrew Jones 2015-10-27 09:40:30 UTC 
(In reply to Richard W.M. Jones from comment #3)
> Is it just these commits, or do we need more?
> 
> http://git.annexia.org/?p=virt-what.git;a=commit;
> h=163024ab11d1ff722c40c517be2279469614bc37
> http://git.annexia.org/?p=virt-what.git;a=commit;
> h=1b0df165bad0cebbff2c1a5b234672a647ea75eb

We'll need more now that we can look for "KVM" as well as "QEMU". Also, as SMBIOS is populated even with DT boots (as long as UEFI is used), then I'd like to change the detection to first check for SMBIOS KVM, then SMBIOS QEMU, then DT QEMU. I'll try to send a patch yet today.

Thanks,
drew
Comment 5 Richard W.M. Jones 2015-11-03 15:02:26 UTC 
The two major commits which fix this are now upstream:

http://git.annexia.org/?p=virt-what.git;a=commit;h=6dbd668e3523d85aeedf16c6cdcc7648508a035e
http://git.annexia.org/?p=virt-what.git;a=commit;h=6fe2ebaec32d8f554749807bc21983506647a9d5
Comment 6 Andrew Jones 2016-04-26 14:35:12 UTC 
This should be testable on latest RHELSA qemu-kvm-rhev composes.
Comment 7 Richard W.M. Jones 2016-06-20 12:18:01 UTC 
All of Drew's patches are upstream so I will include them in
RHEL 7.3.
Comment 9 Xianghua Chen 2016-07-25 10:40:52 UTC 
Failed verification with following package:
Host:
kernel-4.5.0-0.45.el7.aarch64
qemu-kvm-rhev-2.6.0-15.el7.aarch64
Guest:
kernel-4.5.0-0.46.el7.aarch64
virt-what-1.13-7.el7.aarch64

Steps:
1. Prepare a rhel7.3 aarch64 host:
10.12.0.219
redhat
You can use it for debug in one week.
2. Install a rhel7.3 aarch64 guest image with UEFI:
rhel7.2-uefi-aarch64.qcow2
3. Boot the guest image with default option (acpi=on) ,in guest:
# virt-what 
Nothing export.
# ls /proc/device-tree
ls: cannot access /proc/device-tree: No such file or directory


If I boot it acpi=off as described in #1201845, the virt-what works well.
Comment 10 Andrew Jones 2016-07-25 12:02:52 UTC 
(In reply to Xianghua Chen from comment #9)
> Failed verification with following package:
> Host:
> kernel-4.5.0-0.45.el7.aarch64
> qemu-kvm-rhev-2.6.0-15.el7.aarch64
> Guest:
> kernel-4.5.0-0.46.el7.aarch64
> virt-what-1.13-7.el7.aarch64
> 
> Steps:
> 1. Prepare a rhel7.3 aarch64 host:
> 10.12.0.219
> redhat
> You can use it for debug in one week.
> 2. Install a rhel7.3 aarch64 guest image with UEFI:
> rhel7.2-uefi-aarch64.qcow2

You should only use 7.3 candidates for guests. I'm not sure if this 7.2 image has a recent enough dmidecode.

> 3. Boot the guest image with default option (acpi=on) ,in guest:
> # virt-what 
> Nothing export.
> # ls /proc/device-tree
> ls: cannot access /proc/device-tree: No such file or directory
> 
> 
> If I boot it acpi=off as described in #1201845, the virt-what works well.


I just tried with a 7.3 guest and it works for me.
Comment 11 Andrew Jones 2016-07-25 12:04:03 UTC 
(In reply to Andrew Jones from comment #10)
> You should only use 7.3 candidates for guests. I'm not sure if this 7.2
> image has a recent enough dmidecode.

BTW, thank you for verifying AArch64 Virt! And another note about the above. We won't be supporting 7.2 guests. We've even recently removed the 7.2 machine type from QEMU.

Thanks,
drew
Comment 12 Xianghua Chen 2016-07-26 04:39:50 UTC 
(In reply to Andrew Jones from comment #11)
> (In reply to Andrew Jones from comment #10)
> > You should only use 7.3 candidates for guests. I'm not sure if this 7.2
> > image has a recent enough dmidecode.
> 
> BTW, thank you for verifying AArch64 Virt! And another note about the above.
> We won't be supporting 7.2 guests. We've even recently removed the 7.2
> machine type from QEMU.
> 
> Thanks,
> drew

Thank you for your reply.
Yes, that's a rhel7.2 guest image,but I have set up a rhel7.3-candidate and yum update all the packages, then reboot it, you can see the kernel is:kernel-4.5.0-0.46.el7.aarch64.Should I just install a rhel7.3? I thought them would be the same when I update all the packages...

Since when acpi=off, virt-what get the result by inspecting /proc/device-tree ,so I didn't think it would be a matter that dmidecode didn't installed by default.
Comment 13 Andrew Jones 2016-07-26 06:13:35 UTC 
(In reply to Xianghua Chen from comment #12)
> Yes, that's a rhel7.2 guest image,but I have set up a rhel7.3-candidate and
> yum update all the packages, then reboot it, you can see the kernel
> is:kernel-4.5.0-0.46.el7.aarch64.Should I just install a rhel7.3? I thought
> them would be the same when I update all the packages...

Yes, updating should work (AFAIK). From your statements below it sounds like 7.2 vs. 7.3 isn't the problem, but rather dmidecode just isn't installed. Can you explicitly install dmidecode and try again?

> 
> Since when acpi=off, virt-what get the result by inspecting
> /proc/device-tree ,so I didn't think it would be a matter that dmidecode
> didn't installed by default.

Hmm, I think the RHEL build of virt-what should depend on dmidecode, as the ACPI boot detection depends on dmidecode, and RHEL will always be boot with ACPI. Rich?
Comment 14 Xianghua Chen 2016-07-27 02:26:41 UTC 
(In reply to Andrew Jones from comment #13)
> Yes, updating should work (AFAIK). From your statements below it sounds like
> 7.2 vs. 7.3 isn't the problem, but rather dmidecode just isn't installed.
> Can you explicitly install dmidecode and try again?> 
> Hmm, I think the RHEL build of virt-what should depend on dmidecode, as the
> ACPI boot detection depends on dmidecode, and RHEL will always be boot with
> ACPI. Rich?

Yes, I installed dmidecode(dmidecode-3.0-2.el7.aarch64) manually, it works as:
# virt-what 
kvm

But, if I boot it with acpi=off:
When there is demidecode:
  # virt-what 
  kvm                  //it get info from dmidecode
When there is no demidecode:
  # virt-what 
  qemu                 // it  get info from proc/device-tree


Is this ok?
Comment 15 Andrew Jones 2016-07-27 07:55:05 UTC 
(In reply to Xianghua Chen from comment #14)
> if I boot it with acpi=off:
> When there is demidecode:
>   # virt-what 
>   kvm                  //it get info from dmidecode
> When there is no demidecode:
>   # virt-what 
>   qemu                 // it  get info from proc/device-tree
> 
> 
> Is this ok?

Yes. That's working as designed. Thanks, drew
Comment 16 Richard W.M. Jones 2016-07-27 11:06:52 UTC 
Yes we should depend on dmidecode.  I have added bug 1360699
to track this issue separately.
Comment 17 Richard W.M. Jones 2016-07-27 11:07:47 UTC 
This bug is now in ASSIGNED.  Should it be moved back to
ON_QA or VERIFIED?
Comment 18 Xianghua Chen 2016-07-28 09:30:29 UTC 
Verified with packages:
Host
kernel-4.5.0-0.45.el7.aarch64
qemu-kvm-rhev-2.6.0-15.el7.aarch64
Guest:
kernel-4.5.0-0.46.el7.aarch64
virt-what-1.13-7.el7.aarch64

Steps:
1. Prepare a rhel7.3 aarch64 host.
2. Install a rhel7.3 aarch64 guest image with UEFI:
rhel7.3-uefi-aarch64.qcow2
3. Boot the guest image with default option (acpi=on) ,in guest:
Make sure that dmidecode is there.
# virt-what 
kvm


So verified.
Comment 20 errata-xmlrpc 2016-11-04 07:02:43 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://rhn.redhat.com/errata/RHBA-2016-2469.html
Note You need to log in before you can comment on or make changes to this bug.