[libvirt] [PATCH 2/2] qemuDomainUndefineFlags: unlink nvram file regardless of domain state

Martin Kletzander mkletzan at redhat.com
Wed Aug 9 11:57:30 UTC 2017


On Wed, Aug 09, 2017 at 01:13:02PM +0200, Michal Privoznik wrote:
>On 08/09/2017 11:41 AM, Martin Kletzander wrote:
>> 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?
>>>
>>
>> It might be.  Why don't we disable removing it when the domain is
>> running?  We have some precedence for this.  The place which already
>> deals with this possibility is tools/virsh-domain.c in the cmdUndefine()
>> where we handle --remove-all-storage.  If you look at the help of that
>> command it also says:
>>
>>  --nvram          remove nvram file, if inactive
>>
>> And that makes sense to me.  What doesn't, on the other hand, is that it
>> also says:
>>
>>  --keep-nvram     keep nvram file, if inactive
>>
>> I don't get the "if inactive" there.  But I'm not going to check who
>> pushed that.  At least not again =)
>
>Okay, I'll write a patch that:
>
>a) forbids undefine for active domains, unless
>b) KEEP_NVRAM flag is specified.
>

c) or there is no nvram =)

Yeah, well, that's caused by the unfortunate design of the way nvram is
handled by qemu and qemu driver.

Thanks

>Michal
>
>--
>libvir-list mailing list
>libvir-list at redhat.com
>https://www.redhat.com/mailman/listinfo/libvir-list
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20170809/670b51d8/attachment-0001.sig>


More information about the libvir-list mailing list