Description of problem: Should fail to define the xml when setting numa memory than hugepage size Version-Release number of selected component (if applicable): libvirt-daemon-7.6.0-3.module+el8.5.0+12510+80564ecf.x86_64 qemu-kvm-6.0.0-30.module+el8.5.0+12586+476da3e1.x86_64 How reproducible: 100% Steps to Reproduce: 1. enable 1GB hugepage 2. prepare a guest with the following xml # virsh dumpxml mem ... <memory unit='KiB'>1024000</memory> <currentMemory unit='KiB'>1024000</currentMemory> <memoryBacking> <hugepages> <page size='1048576' unit='KiB' nodeset='0-1'/> </hugepages> </memoryBacking> ... <numa> <cell id='0' cpus='0-1,4-15' memory='512000' unit='KiB'/> <cell id='1' cpus='2-3' memory='512000' unit='KiB'/> </numa> ... 3. start the guest # virsh start mem error: Failed to start domain 'mem' error: internal error: qemu unexpectedly closed the monitor: 2021-09-24T11:50:27.284619Z qemu-kvm: memory size 0x1f400000 must be equal to or larger than page size 0x40000000 Expected result: Error reported by qemu is not human friendly. libvirt can report some more clear error info when define such xml Additional info: 1. change numa node memory to: <numa> <cell id='0' cpus='0-1,4-15' memory='1048576' unit='KiB'/> <cell id='1' cpus='2-3' memory='1048576' unit='KiB'/> </numa> 2. start the guest # virsh start mem Domain 'mem' started Actual results: Expected results: Additional info:
Bulk update: Move RHEL-AV bugs to RHEL9. If necessary to resolve in RHEL8, then clone to the current RHEL8 release.
While it's true we can generate better error message, I don't think it's worth it. I mean, there's already a plenty of code duplication between QEMU and Libvirt as Libvirt often checks for the same conditions as QEMU. For user it doesn't really matter whether the error comes from QEMU or Libvirt, does it? Ideally, there would be no intersection between things that QEMU and Libvirt check. Therefore, I think this should be closed. But I'll let others to express their minds before closing it.
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.