Renamed "NetVM" to "Networking" and to clear up any possible
misunderstanding, renamed "none" to "(none)" in the appropriate dropdown.
FixesQubesOS/qubes-issues#1763
rename VM button in VM settings: it asks for a new name, and then clones
VM under the new name and deletes old one. Renaming VM closes VM settings
window without saving any other changes.
Changed max size of VM name field to 32 characters.
* qubesos/pr/34:
Show size of current inter-VM clipboard in Ctrl-Shift-C notification message
Show size of current inter-VM clipboard in Ctrl-Shift-C notification message
Prior to this commit, whenever the user selected the default kernel in
a VM's "Advanced Settings" dialog in Qubes Manager, the
"uses_default_kernel" flag would not be saved as expected. Instead of
the intent to use the default kernel version for the VM in the future,
the VM would be stuck with the specific kernel version and not any new
future default kernel versions.
This issue occurs because the "kernel" property setter for the QubesVm
class resets the "uses_default_kernel" member variable to False, and
Qubes Manager sets the "uses_default_kernel" property before setting the
"kernel" property.
Resolve this issue by making sure that the "uses_default_kernel"
member variable of the VM in question is set after the "kernel" member
variable.
Prior to this commit, there have been occasional issues with the usage
of the Qubes Manager's VM restart button where the restart procedure
is interrupted due to an exception thrown after the VM in question is
shut down. The exception has the following backtrace:
----
line: assert not vm.is_running()
func: start_vm
line no.: 1198
file: /usr/lib64/python2.7/site-packages/qubesmanager/main.py
----
line: self.caller.start_vm(vm)
func: check_if_vm_has_shutdown
line no.: 308
file: /usr/lib64/python2.7/site-packages/qubesmanager/main.py
Upon investigation, the root cause of the issue appears to be
inconsistent information provided by Xen regarding a recently-shut-down
VM's start-up timestamp and its state (i.e., running or shut down).
In some cases Xen would report that the VM is running whereas the
start-up timestamp would be returned as None, due to unknown reasons.
This inconsistency would then cause the code modified by this commit to
call the Qubes Manager's "start_vm" method, which would attempt to
assert that a VM is shut down, which would raise the aforementioned
exception.
This commit aims to resolve this issue by checking whether the VM has
fully shut down according to Xen and by calling "start_vm" only if the
VM has fully shut down.
This commit also slightly refactors the affected code.
Fixes: QubesOS/qubes-issues#2438
