Comment 2 for bug 2073214

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