[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH 1/2] qemu: Delete nvram store for transient domains too

On 12.11.2014 19:10, Peter Krempa wrote:
On 11/12/14 18:26, Michal Privoznik wrote:
There are two ways how to use nvram variable store file in

   1) create it by hand and pass the path in domain XML

   2) let libvirt generate path and create the file

Now, we allow users to remove the file from case 2) by passing a
flag into the virDomainUndefineFlags(). But when implementing
this I forgot about transient domains. For them the file needs to
be removed in qemuProcessStop(). But not always, only if the file
was created by us.  For that reason new attribute to <nvram/> is
invented: @generated to keep the info between daemon restarts.
However, now that we are removing autogenerated file for
transient domains automatically, we should do the same for
persistent domains too without requiring the

I agree that we should clean up the file once we create it as currently
the guest would be started with the NVRAM generated for a different
guest with the same name which might trigger some unwanted behavior.

The existing behavior (introduced in 1.2.8) though might lead the users
to use transient VMs with unspecified NVRAM path and rely on the fact
that the NVRAM file is present from the last run.

I think we should document that unless the NVRAM file is provided
externally the settings don't persist between runs and users using
transient VMs (hello oVirt) should take care of generating it by
themselves as they might get unexpected results and we should do it
rather sooner than later until somebody starts abusing it.

Okay, we should document that the file is left behind in case of transient domains and it's mgmt app responsibility to remove the file once not needed. What persuaded me is the fact, that it would be almost impossible for mgmt app to keep nvram file if this patch is merged. I mean, it's not possible from the host to tell when is the nvram file written or whether are some writes still pending in the guest. So the app can't just copy the file shortly before guest termination and hope for the best. Moreover, the guest can die without mgmt app knowledge beforehand.

Self NACK. Watch out for v2.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]