Let me take you on a short trip to history. A long time ago,
libvirt would configure all QEMUs to use $hugetlbfs/libvirt/qemu
for their hugepages setup. This was problematic, because it did
not allow enough separation between guests. Therefore in
v3.0.0-rc1~367 the path changed to a per-domain basis:

  $hugetlbfs/libvirt/qemu/$domainShortName

And to help with migration on daemon restart a call to
qemuProcessBuildDestroyMemoryPaths() was added to
qemuProcessReconnect() (well, it was named
qemuProcessBuildDestroyHugepagesPath() back then, see
v3.10.0-rc1~174). This was desirable then, because the memory
hotplug code did not call the function, it simply assumes
per-domain paths to exist. But this changed in v3.5.0-rc1~92
after which the per-domain paths are created on memory hotplug
too.

Therefore, it's no longer necessary to create these paths in
qemuProcessReconnect(). They are created exactly when needed
(domain startup and memory hotplug).

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
---
 src/qemu/qemu_process.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index b05ad059c3..998f4aa63c 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -8785,9 +8785,6 @@ qemuProcessReconnect(void *opaque)
         goto cleanup;
     }
 
-    if (qemuProcessBuildDestroyMemoryPaths(driver, obj, NULL, true) < 0)
-        goto error;
-
     if ((qemuDomainAssignAddresses(obj->def, priv->qemuCaps,
                                    driver, obj, false)) < 0) {
         goto error;
-- 
2.35.1

On a Thursday in 2022, Michal Privoznik wrote:
>Let me take you on a short trip to history. A long time ago,
>libvirt would configure all QEMUs to use $hugetlbfs/libvirt/qemu
>for their hugepages setup. This was problematic, because it did
>not allow enough separation between guests. Therefore in
>v3.0.0-rc1~367 the path changed to a per-domain basis:
>
>  $hugetlbfs/libvirt/qemu/$domainShortName
>
>And to help with migration on daemon restart a call to
>qemuProcessBuildDestroyMemoryPaths() was added to
>qemuProcessReconnect() (well, it was named
>qemuProcessBuildDestroyHugepagesPath() back then, see
>v3.10.0-rc1~174). This was desirable then, because the memory
>hotplug code did not call the function, it simply assumes
>per-domain paths to exist. But this changed in v3.5.0-rc1~92
>after which the per-domain paths are created on memory hotplug
>too.
>
>Therefore, it's no longer necessary to create these paths in
>qemuProcessReconnect(). They are created exactly when needed
>(domain startup and memory hotplug).
>
>Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
>---
> src/qemu/qemu_process.c | 3 ---
> 1 file changed, 3 deletions(-)
>

Reviewed-by: Ján Tomko <jtomko@redhat.com>

Jano