This is an invalid bug report.

But it might still be interesting because the problem seems to be some
change after the upgrade which is reserving some of the exactly 16GiB of
hugepages I reserved via sysctl.conf
I did not see this in 22.04.


So, I think the problem was the amount of memory I was requesting exceeded
free pages due to something else reserving some of the hugepage pool.


Firstly ...

#Topic 1: Unnecessary entry in fstab and /det/libvirt/qemu.conf edit are
now reverted
#Topic 2: there is no indication of apparmor problems, I was just
eliminating it.


guest config which fails to start: "FailConfig":

 <memory unit="KiB">16777216</memory>
  <currentMemory unit="KiB">16777216</currentMemory>
  <memoryBacking>
    <hugepages>
      <page size="2048" unit="KiB"/>
    </hugepages>
    <source type="memfd"/>
    <access mode="shared"/>
  </memoryBacking>

guest config which worked "SucceedConfig":

<memory unit="KiB">8388608</memory>
  <currentMemory unit="KiB">8388608</currentMemory>
  <memoryBacking>
    <hugepages>
      <page size="2048" unit="KiB"/>
    </hugepages>
    <source type="memfd"/>
    <access mode="shared"/>
  </memoryBacking>



tim@black:~$ hugeadm --list-all-mounts
Mount Point          Options
/dev/hugepages       rw,relatime,gid=1002,mode=1770,pagesize=2M

Prior to starting the VM:


tim@black:~$ grep -i huge /proc/meminfo
AnonHugePages:         0 kB
ShmemHugePages:        0 kB
FileHugePages:         0 kB
HugePages_Total:    8192
HugePages_Free:     8180
HugePages_Rsvd:       61
HugePages_Surp:        0
Hugepagesize:       2048 kB
Hugetlb:        16777216 kB


(I do not remember noticing the reservation of 61 pages in 22.04)


After starting with SucceedConfig:

tim@black:~$ grep -i huge /proc/meminfo
AnonHugePages:         0 kB
ShmemHugePages:        0 kB
FileHugePages:         0 kB
HugePages_Total:    8192
HugePages_Free:     4084
HugePages_Rsvd:       61
HugePages_Surp:        0
Hugepagesize:       2048 kB
Hugetlb:        16777216 kB


So, back to FailConfig, but first increase number of pages

try:

tim@black:~$ echo 8500 | sudo tee -a
/sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
8500
tim@black:~$ grep -i huge /proc/meminfo
AnonHugePages:         0 kB
ShmemHugePages:        0 kB
FileHugePages:         0 kB
HugePages_Total:    8500
HugePages_Free:     8488
HugePages_Rsvd:       61
HugePages_Surp:        0
Hugepagesize:       2048 kB
Hugetlb:        17408000 kB


and start with "FailConfig"

Result: Boot is successful!

tim@black:~$ grep -i huge /proc/meminfo
AnonHugePages:         0 kB
ShmemHugePages:        0 kB
FileHugePages:         0 kB
HugePages_Total:    8500
HugePages_Free:      296
HugePages_Rsvd:       61
HugePages_Surp:        0
Hugepagesize:       2048 kB
Hugetlb:        17408000 kB




Thank you for helping me. I am new to hugepages and without your excellent
reply I would not have had confidence to keep trying to fix the problem.
Hopefully this can serve as some documentation for other beginners.







On Tue, 16 Jul 2024 at 18:35, Christian Ehrhardt  <
<email address hidden>> wrote:

> Hi Tim,
> you are right that neither of the workaround steps were necessary on 22.04
> and they should neither be on 24.04.
>
>
> ### Topic 1 - changes that should not be needed
>
> Ubuntu 24.04 by default has
>
> 1. hugetlbfs mounted (was that no more the case for you after upgrade?)
> $ mount | grep huge
> hugetlbfs on /dev/hugepages type hugetlbfs
> (rw,nosuid,nodev,relatime,pagesize=2M)
>
> 2. uncommenting hugetlbfs_mount in /etc/libvirt/qemu.conf changes nothing
> default is
> #hugetlbfs_mount = "/dev/hugepages"
> Changing that to
> hugetlbfs_mount = "/dev/hugepages"
> will not change anything.
>
> I assume #1 and #2 have only been things on your try to debug what is
> wrong - which is fine.
> But let us know if it is otherwise.
>
> ### Topic 2 - was there an apparmor denial?
>
> Now back to your actual issue, you mentioned that you set apparmor to
> complain mode.
> Was there an indication that apparmor is the issue, a related denial in
> the syslog when you start your guest? If so could you please pass that
> denial?
>
> ### Topic 3 - repro seems to not trigger this
>
> I picked a guest which before had:
>   <memory unit='MiB'>1024</memory>
>
>   <currentMemory unit='MiB'>1024</currentMemory>
>
> And changed it to use huge pages by adding:
>   <memoryBacking>
>
>     <hugepages>
>
>       <page size='2048' unit='KiB'/>
>
>     </hugepages>
>
>   </memoryBacking>
>
> To confirm it tries to use the right thing I started it without allocating
> huge pages and got:
> => qemu-system-x86_64: unable to map backing store for guest RAM: Cannot
> allocate memory
>
> Then I allocated some huge pages in the system and started it again.
> $ echo 512 | sudo tee -a
> /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
> $ virsh start --console test
>
> Worked right away.
>
> I double checked in /proc/meminfo and saw HugePages_Free changing when the
> guest was running.
> So I think, something is configured in an unexpected way.
>
> Could you share
> - your full guest-config in regard to memory
> - hugeadm --list-all-mounts
> - journalctl -f while starting the guest
> - grep -i huge /proc/meminfo
>
> ** Changed in: libvirt (Ubuntu)
>        Status: New => Incomplete
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/2073214
>
> Title:
>   hugepages causes permissions error
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/2073214/+subscriptions
>
>

-- 
Tim Richardson