Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
Description of problem:
virsh allocpages is a convenient way to allocate hugepages. On s390x, there's no NUMA. The command fails silently.
Version-Release number of selected component (if applicable):
libvirt-client-7.0.0-14.1.module+el8.4.0+11095+d46acebf.s390x
How reproducible:
100%
Steps to Reproduce:
1. virsh allocpages 1M 1024
2. cat /proc/meminfo|grep Huge
Actual results:
a. empty output after 1.
b. output from 2.:
AnonHugePages: 464896 kB
ShmemHugePages: 0 kB
FileHugePages: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 1024 kB
Hugetlb: 0 kB
c. libvirt logs:
2021-07-02 08:07:42.317+0000: 1658553: debug : virNodeAllocPages:1682 : conn=0x3ff84004340 npages=1 pageSizes=0x3ff80002560 pageCounts=0x3ff80002c40 startCell=-1 cellCount=1 flags=0x1
2021-07-02 08:07:42.317+0000: 1658553: error : virNumaGetMaxNode:367 : internal error: NUMA isn't available on this host
Expected results:
After 1. error message like 'Command not supported on platforms without NUMA'
or add support for it without NUMA.
Sebastian, I couldn't reproduce. After 'virsh allocpages' I can see them allocated:
# virsh allocpages 1MiB 10; virsh freepages --all
Node 0:
4KiB: 33392
1024KiB: 10
I've used current git master. Can you please attach debug logs so that I can take a look?
(In reply to Michal Privoznik from comment #1)
> Sebastian, I couldn't reproduce. After 'virsh allocpages' I can see them
> allocated:
>
> # virsh allocpages 1MiB 10; virsh freepages --all
>
> Node 0:
> 4KiB: 33392
> 1024KiB: 10
>
> I've used current git master. Can you please attach debug logs so that I can
> take a look?
Hi Michal, sure. Attaching log for 'virsh allocpages 1MiB 10'.
This reproduces on Alpha Refresh compose, libvirt-daemon-7.6.0-1.module+el8.5.0+12097+2c77910b.s390x
kernel kernel-4.18.0-330.el8.s390x
# virsh allocpages 1MiB 10
>> empty output
# echo $?
0
(BTW, freepages somewhat correctly reports "error: internal error: NUMA isn't available on this host")
Alright, I was finally able to reproduce. The problem is that libvirt isn't build with numactl on s390. And I remember writing code that handles that situation but apparently it did not run. Let me try to fix it.
Merged upstream as:
c71a986e9a rpm: Enable numactl on s390x
78d4c12b8c virhostmem: Handle numactl-less build in hugepages allocation/reporting
ebec3de97d virhostmem: Let caller pass max NUMA node to virHostMemAllocPages
59e3584f71 virhostmem: Let caller pass max NUMA node to virHostMemGetFreePages
20816cbda5 conf: Introduce virCapabilitiesHostNUMAGetMaxNode()
v7.6.0-247-gc71a986e9a
Bulk update: Move RHEL-AV bugs to RHEL8.
A clone for RHEL9 was not created since the target is for s390x, if resolution/testing needs to occur for RHEL9, then a clone must be created.
------- Comment From tstaudt.com 2021-09-13 03:58 EDT-------
From IBM's perspective, this should also be implemented for RHEL 9 to avoid regressions.
Since RHEL 9.0 contains
libvirt-7.6.0-2.el9.src.rpm 2021-Aug-19 12:53 8.3M
as of NB 2021/09/01 this seems to be included already though.
Please confirm or advise.
Thanks.
As far as I can see, RHEL 9.0 will be fixed by a rebased version automatically, so from a developers point of view, this will be a no-op there. Sebastian, what about the testing side, do you want to re-test this in RHEL 9.0 ? If so, could you please create a TestOnly clone of this BZ for RHEL 9.0 ? Otherwise, I think we should be fine without a clone.
Thank you Thomas. I believe there's no need to have an explicit RHEL 9 item for the following reason: An automated test will be added to the AT suite in this item. The same AT suite will run for RHEL 9, so there should be no need to have an explicit BZ for it. QE will have this as part of our scoping explicitly though.
CC Boqiao and Jing for visibility
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 (Moderate: virt:rhel and virt-devel:rhel security, bug fix, and enhancement update), 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/RHSA-2022:1759