Bug 1275349 - detect ACPI-boot AArch64 guest VM
detect ACPI-boot AArch64 guest VM
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: virt-what (Show other bugs)
7.3
aarch64 Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Richard W.M. Jones
Virtualization Bugs
:
Depends On: 1360699
Blocks: 1212027 1301891 1288337
  Show dependency treegraph
 
Reported: 2015-10-26 11:25 EDT by Andrew Jones
Modified: 2016-11-04 03:02 EDT (History)
10 users (show)

See Also:
Fixed In Version: virt-what-1.13-7.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1360699 (view as bug list)
Environment:
Last Closed: 2016-11-04 03:02:43 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Andrew Jones 2015-10-26 11:25:14 EDT
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 11:29:06 EDT
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 4 Andrew Jones 2015-10-27 05:40:30 EDT
(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 6 Andrew Jones 2016-04-26 10:35:12 EDT
This should be testable on latest RHELSA qemu-kvm-rhev composes.
Comment 7 Richard W.M. Jones 2016-06-20 08:18:01 EDT
All of Drew's patches are upstream so I will include them in
RHEL 7.3.
Comment 9 Xianghua Chen 2016-07-25 06:40:52 EDT
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 08:02:52 EDT
(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 08:04:03 EDT
(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 00:39:50 EDT
(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 02:13:35 EDT
(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-26 22:26:41 EDT
(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 03:55:05 EDT
(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 07:06:52 EDT
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 07:07:47 EDT
This bug is now in ASSIGNED.  Should it be moved back to
ON_QA or VERIFIED?
Comment 18 Xianghua Chen 2016-07-28 05:30:29 EDT
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 03:02:43 EDT
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.