[libvirt] [PATCH] qemuPrepareNVRAM: Save domain after NVRAM path generation

Martin Kletzander mkletzan at redhat.com
Fri Sep 26 08:46:05 UTC 2014


On Fri, Sep 26, 2014 at 10:13:35AM +0200, Michal Privoznik wrote:
>On 25.09.2014 19:21, Martin Kletzander wrote:
>> On Thu, Sep 25, 2014 at 03:00:06PM +0200, Michal Privoznik wrote:
>>> On a domain startup, the variable store path is generated if needed.
>>> The path is intended to be generated only once. However, the updated
>>> domain definition is not saved into config dir rather than state XML
>>
>> the 'is not' confused me in here.  Did you mean s/not // by any chance?
>
>Nope.
>
>>
>>> only. So later, whenever the domain is destroyed and the daemon is
>>> restarted, the generated path is forgotten and the file may be left
>>> behind on virDomainUndefine() call.
>>>
>>
>> And if you did really mean "the updated domain definition is saved
>> into config dir rather than state XML only", why isn't that done when
>> the domain is defined (in PostParse() for example) like address
>> assignment, etc.?
>>
>
>Well, the main reason is that path I'd like to keep path generation
>close to copying from the template/master var store. And the copying
>doesn't need to be done until the domain is started. But once the path
>is generated it shoul persist in the config XML. However, early in the
>qemuProcessStart() the vm->def and vm->newDef are swapped to create live
>XML. Anything that's done to domain def after the swap is reflected in
>live XML only. That's why the config didn't need to be saved. But now,
>with NVRAM things have changed.
>
>What we can do (post release preferably) is to break qemuPrepareNVRAM()
>into smaller pieces: the NVRAM path would be generated in PostParse()
>callback and the file creation somewhere in qemuProcessStart.
>

That's just one condition that's about few lines that needs to be
moved, but for the release it's fine, as you said, we can do that
post-release.

ACK,

Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140926/a7e40427/attachment-0001.sig>


More information about the libvir-list mailing list