Bug 1275349

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.

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

(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

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

This should be testable on latest RHELSA qemu-kvm-rhev composes.

All of Drew's patches are upstream so I will include them in
RHEL 7.3.

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.

(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.

(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

(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.

(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?

(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?

(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

Yes we should depend on dmidecode.  I have added bug 1360699
to track this issue separately.

This bug is now in ASSIGNED.  Should it be moved back to
ON_QA or VERIFIED?

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.

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