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 1978574 - allocpages fails silently on arch without NUMA (s390x)
Summary: allocpages fails silently on arch without NUMA (s390x)
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: libvirt
Version: 8.5
Hardware: s390x
OS: Linux
low
medium
Target Milestone: rc
: 8.6
Assignee: Michal Privoznik
QA Contact: smitterl
URL:
Whiteboard:
Depends On:
Blocks: 1916117
TreeView+ depends on / blocked
 
Reported: 2021-07-02 08:24 UTC by smitterl
Modified: 2022-05-10 13:27 UTC (History)
14 users (show)

Fixed In Version: libvirt-7.8.0-1.module+el8.6.0+12978+7d7a0321
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-05-10 13:20:14 UTC
Type: Bug
Target Upstream Version: 7.7.0
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
IBM Linux Technology Center 193542 0 None None None 2021-07-02 08:55:48 UTC
Red Hat Product Errata RHSA-2022:1759 0 None None None 2022-05-10 13:21:17 UTC

Description smitterl 2021-07-02 08:24:34 UTC 
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.
Comment 1 Michal Privoznik 2021-08-18 11:40:19 UTC 
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?
Comment 2 smitterl 2021-08-18 15:24:19 UTC 
(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")
Comment 5 Michal Privoznik 2021-08-19 11:28:22 UTC 
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.
Comment 6 Michal Privoznik 2021-08-19 14:27:41 UTC 
Patches posted upstream:

https://listman.redhat.com/archives/libvir-list/2021-August/msg00577.html
Comment 7 Michal Privoznik 2021-08-23 12:17:29 UTC 
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
Comment 8 John Ferlan 2021-09-09 18:38:27 UTC 
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 9 IBM Bug Proxy 2021-09-13 08:01:03 UTC 
------- 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.
Comment 10 Thomas Huth 2021-09-13 09:10:44 UTC 
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.
Comment 11 smitterl 2021-09-20 17:04:35 UTC 
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
Comment 14 smitterl 2021-12-07 09:33:05 UTC 
auto test case: https://github.com/autotest/tp-libvirt/pull/3915

Verified with:
libvirt-7.9.0-1.module+el8.6.0+13150+28339563.s390x
Comment 17 errata-xmlrpc 2022-05-10 13:20:14 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 (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
Note You need to log in before you can comment on or make changes to this bug.