Ever since QEMU commit 7b8be49d36fc ("NUMA: Enable adding NUMA node implicitly") in 2017 we started to implicitly create a single NUMA node when memory hotplug was possible (DIMM "slots" defined on the QEMU cmdline). Before that, the user had to create a dummy NUMA node manually on the QEMU cmdline.

In QEMU commit 195784a0cfad ("numa: Auto-enable NUMA when any memory devices are possible") in 2020 we extended that handling for slot-less memory devices (like virtio-mem, see bz2216212).

In Libvirt, in order to use memory devices (DIMMs/NVDIMMs/virtio-mem/virtio-pmem), we still have to manually create at least one NUMA node.

Without a NUMA node, Libvirt will bail out when specifying the maxMemory option to enable memory devices like:

<memory unit='GiB'>4</memory>
<maxMemory slots='1' unit='GiB'>8</maxMemory>

"error: unsupported configuration: At least one numa node has to be
configured when enabling memory hotplug"

And the user has to manually define a single NUMA node:

<vcpu placement='static'>16</vcpu>
...
<cpu ...>
...
<numa>
<cell id='0' cpus='0-16' memory='4' unit='GiB'/>
</numa>
</cpu>

To get it working.

To improve usability, either Libvirt should automatically create that single NUMA node (memory and VCPUs are known) for the user, or it should rely on QEMU to do it automatically.

Letting Libvirt do it is probably cleaner, because that won't require QEMU compat handling.