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@redhat.com> ---
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