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). To avoid this forbid undefining domain with
NVRAM file.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
---
src/qemu/qemu_driver.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 574c351ae..dc5b924ef 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -7367,10 +7367,15 @@ 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 (virDomainObjIsActive(vm)) {
+ virReportError(VIR_ERR_OPERATION_INVALID, "%s",
+ _("cannot delete active domain with nvram"));
+ goto endjob;
+ }
if (unlink(vm->def->os.loader->nvram) < 0) {
virReportSystemError(errno,
_("failed to remove nvram: %s"),
--
2.13.0
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, Aug 09, 2017 at 02:00: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). To avoid this forbid undefining domain with > NVRAM file. Why do we need to forbid it ? Even if QEMU still has an open file handle, it can continue to write to it after we unlink it. 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@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, Aug 09, 2017 at 01:14:59PM +0100, Daniel P. Berrange wrote: >On Wed, Aug 09, 2017 at 02:00: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). To avoid this forbid undefining domain with >> NVRAM file. > >Why do we need to forbid it ? Even if QEMU still has an open >file handle, it can continue to write to it after we unlink >it. > It was a suggestion, because that's what will people expect, IMHO. Feel free to go with the first version if that's what Dan prefers. > >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@redhat.com >https://www.redhat.com/mailman/listinfo/libvir-list -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On 08/09/2017 02:14 PM, Daniel P. Berrange wrote:
> On Wed, Aug 09, 2017 at 02:00: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). To avoid this forbid undefining domain with
>> NVRAM file.
>
> Why do we need to forbid it ? Even if QEMU still has an open
> file handle, it can continue to write to it after we unlink
> it.
>
>
That's what my v1 does. Anyway, there's third option: just recently
Jirka added possibility to do some actions when domain is destroyed. He
needed it for some migration work, but the design is broad enough to fit
this problem too. What we can do is:
if (flags & VIR_DOMAIN_UNDEFINE_NVRAM):
if domain is running:
register the callback /* that merely just unlinks the file */
else:
unlink
else:
if (!(flags & VIR_DOMAIN_UNDEFINE_KEEP_NVRAM)):
error
What do you guys think of this one?
Michal
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, Aug 09, 2017 at 02:55:36PM +0200, Michal Privoznik wrote: > On 08/09/2017 02:14 PM, Daniel P. Berrange wrote: > > On Wed, Aug 09, 2017 at 02:00: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). To avoid this forbid undefining domain with > >> NVRAM file. > > > > Why do we need to forbid it ? Even if QEMU still has an open > > file handle, it can continue to write to it after we unlink > > it. > > > > > > That's what my v1 does. Anyway, there's third option: just recently > Jirka added possibility to do some actions when domain is destroyed. He > needed it for some migration work, but the design is broad enough to fit > this problem too. What we can do is: > > if (flags & VIR_DOMAIN_UNDEFINE_NVRAM): > if domain is running: > register the callback /* that merely just unlinks the file */ > else: > unlink > else: > if (!(flags & VIR_DOMAIN_UNDEFINE_KEEP_NVRAM)): > error > > > What do you guys think of this one? The callback will be lost if libvirtd restarts. 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@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On 08/09/2017 03:02 PM, Daniel P. Berrange wrote: > On Wed, Aug 09, 2017 at 02:55:36PM +0200, Michal Privoznik wrote: >> On 08/09/2017 02:14 PM, Daniel P. Berrange wrote: >>> On Wed, Aug 09, 2017 at 02:00: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). To avoid this forbid undefining domain with >>>> NVRAM file. >>> >>> Why do we need to forbid it ? Even if QEMU still has an open >>> file handle, it can continue to write to it after we unlink >>> it. >>> >>> >> >> That's what my v1 does. Anyway, there's third option: just recently >> Jirka added possibility to do some actions when domain is destroyed. He >> needed it for some migration work, but the design is broad enough to fit >> this problem too. What we can do is: >> >> if (flags & VIR_DOMAIN_UNDEFINE_NVRAM): >> if domain is running: >> register the callback /* that merely just unlinks the file */ >> else: >> unlink >> else: >> if (!(flags & VIR_DOMAIN_UNDEFINE_KEEP_NVRAM)): >> error >> >> >> What do you guys think of this one? > > The callback will be lost if libvirtd restarts. Ah, good point. In that case all I need is an ACK to v1 then ;-) Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
© 2016 - 2025 Red Hat, Inc.