Re: [libvirt] [PATCH] qemuPrepareNVRAM: Save domain after NVRAM path generation
On 09/25/14 15:00, 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
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.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
src/qemu/qemu_process.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index dddca35..1b8931e 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -3876,6 +3876,9 @@ qemuPrepareNVRAM(virQEMUDriverConfigPtr cfg,
goto cleanup;
generated = true;
+
+ if (virDomainSaveConfig(cfg->configDir, def) < 0)
+ goto cleanup;
}
if (!virFileExists(loader->nvram)) {
Notes:
(1) I skimmed a few qemu-related source files *very superficially*, and
apparently it is allowed / quite liberal to re-save a domain XML
*whenever*. I was worried about that, but seems like it's fine.
Specifically, the following call chain should be allowed:
qemuProcessStart()
qemuPrepareNVRAM()
virDomainSaveConfig()
OK I guess.
(2) if the virDomainSaveConfig() call fails, then (due to "generated"
being true) loader->nvram will be freed, and re-set to NULL. Hence at
the next-start we'll retry the pathname generation and to save the
domain XML. Seems OK. (Assuming that saving the domain XML is "atomic",
which, if my reading of virFileRewrite() is correct, it is -- written,
synced, then renamed. Good.)
(3) If the virDomainSaveConfig() call succeeds, and we fail sometime
later, then the domain XML will have been rewritten, but loader->nvram
will be freed and NULL-ed nonetheless.
What happens if the user tries to start the domain again? I can imagine
two possibilities:
- the in-memory loader->nvram value is still NULL, not reflecting the
domain XML. Shouldn't be the problem, we'll just regenerate the pathname
again, and dump the XML again. A bit strange, but should be fine.
- or, the in-memory loader-nvram value is not NULL -- it reflects the
domain XML closely. (This should be the case eg. when libvirtd has been
restarted). This should be fine too, we'll just proceed to the
virFileExists() check. Should be fine.
(4) I like how this approach keeps both the pathname generation and the
contents copying associated with VM startup. It "just" saves the
generated pathname for everything later, including a later startup as well.
(5) As Michal explained to me, renames are not supported generally
anyway, so that's fine.
I hope we're not missing anything.
I should really test this, but I'm too tired to do that now, sorry. I'll
trust that you tested it. :)
Acked-by: Laszlo Ersek <lersek(a)redhat.com>
Cole, Giuseppe, do you agree this patch should be fine?
Thanks,
Laszlo