On 01/11/2018 01:36 PM, Peter Krempa wrote: > On Thu, Jan 11, 2018 at 13:24:57 +0100, Michal Privoznik wrote: >> https://bugzilla.redhat.com/show_bug.cgi?id=1461214 >> >> Since fec8f9c49af we try to use predictable file names for >> 'memory-backend-file' objects. But that made us provide full path >> to qemu when hot plugging the object while previously we provided >> merely a directory. But this makes qemu behave differently. If >> qemu sees a path terminated with a directory it calls mkstemp() >> and unlinks the file immediately. But if it sees full path it >> just calls open(path, O_CREAT ..); and never unlinks the file. >> Therefore it's up to libvirt to unlink the file and not leave it >> behind. >> >> Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> >> --- >> >> Zack, can you please check if this patch is suitable for your use cases? >> >> src/qemu/qemu_hotplug.c | 3 +++ >> src/qemu/qemu_process.c | 26 ++++++++++++++++++++++++++ >> src/qemu/qemu_process.h | 4 ++++ >> 3 files changed, 33 insertions(+) >> >> diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c >> index 6dc16a105..f26e2ca60 100644 >> --- a/src/qemu/qemu_hotplug.c >> +++ b/src/qemu/qemu_hotplug.c >> @@ -3894,6 +3894,9 @@ qemuDomainRemoveMemoryDevice(virQEMUDriverPtr driver, >> if (qemuDomainNamespaceTeardownMemory(vm, mem) < 0) >> VIR_WARN("Unable to remove memory device from /dev"); >> >> + if (qemuProcessDestroyMemoryBackingPath(driver, vm, mem) < 0) >> + VIR_WARN("Unable to destroy memory backing path"); >> + >> virDomainMemoryDefFree(mem); > > This will not call the function when we shut down qemu. Is the full > directory removed in that case? > Yes, from qemuProcessStop() we call qemuProcessBuildDestroyMemoryPaths() which in turn calls virFileDeleteTree() over all domain specific hugepages paths and memoryBacking ones. Michal -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
