IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
(1) A separate nvram (ie. variable store) file for the domain exists if
and only if the following condition holds:
(self.get_xmlobj().os.loader_ro is True and
self.get_xmlobj().os.loader_type == "pflash")
(Refer to libvirtd's qemuPrepareNVRAM() function, as of commit 742b08e30.)
(2) The
self.get_xmlobj().os.nvram
condition is sufficient, but not necessary, for the separate varstore file
to exist. That is, if the condition holds, then the separate varstore file
exists for sure, but if the condition doesn't hold, the file may exist
nonetheless. (Because libvirtd can auto-generate the varstore file's
pathname.)
This means that requiring condition (2) for setting UNDEFINE_NVRAM on
domain deletion will miss a subset of the cases, ie. when the necessary
and sufficient condition (1) holds, but the sufficient-only condition (2)
doesn't.
Make sure that the code uses the necessary and sufficient condition (1).
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
This was a weird bit of logic that tries to be smart, but there isn't
a clear corrolation between DISPLAY being unset and whether the user
wants graphics or not.
Make the default consistent, some people may need to adjust to
--nographics
Rework things a bit to simplify everything we pass around.
The specific bug fix is making sure we update the object list in place,
otherwise the event loop detects it as the VM being deleted and closes
the details window.
It annoys me that all the other CLI options map to the libvirt XML name,
except this one. Of course, keep the old option around for back compat,
just give precendence to the new option.
As of now, the only uses of nvram likely in the domain XML are with
libvirt configurations that also support the UNDEFINE_NVRAM flag, so
listing it here is kind of redundant. And in the common config of
non-root user connected to qemu:///system with template based nvram
in /var/lib, we won't be able to remove it anyways.