mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2024-12-22 13:45:38 +00:00
qemuProcessReconnect: Don't build memory paths
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> Reviewed-by: Ján Tomko <jtomko@redhat.com>
This commit is contained in:
parent
135233df26
commit
3478cca80e
@ -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;
|
||||
|
Loading…
Reference in New Issue
Block a user