Hide Forgot
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.
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