On Mon, Aug 07, 2017 at 02:20:06PM +0200, Michal Privoznik wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=1467245 > > Currently, there's a bug when undefining a domain with NVRAM > store. Basically, the unlink() of the NVRAM store file happens > during the undefine procedure iff domain is inactive. So, if > domain is running and undefine is called the file is left behind. > It won't be removed in the domain cleanup process either > (qemuProcessStop). One of the solutions is to remove if > regardless of the domain state and rely on qemu having the file > opened. This still has a downside that if the domain is defined > back the NVRAM store file is going to be new, any changes to the > current one are lost (just like with any other file that is > deleted while a process has it opened). But is it really a > downside? We only unlink if the user explicitly gives VIR_DOMAIN_UNDEFINE_NVRAM, so I think that "prolem" scenario you describe is exactly what the user has asked for. ie not a bug - just don't pass VIR_DOMAIN_UNDEFINE_NVRAM if they want to keep it around across an undefine+define pair. > > Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> > --- > src/qemu/qemu_driver.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c > index 574c351ae..992ae2a2e 100644 > --- a/src/qemu/qemu_driver.c > +++ b/src/qemu/qemu_driver.c > @@ -7367,8 +7367,8 @@ qemuDomainUndefineFlags(virDomainPtr dom, > } > } > > - if (!virDomainObjIsActive(vm) && > - vm->def->os.loader && vm->def->os.loader->nvram && > + if (vm->def->os.loader && > + vm->def->os.loader->nvram && > virFileExists(vm->def->os.loader->nvram)) { > if ((flags & VIR_DOMAIN_UNDEFINE_NVRAM)) { > if (unlink(vm->def->os.loader->nvram) < 0) { ACK Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
