* 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
Saving (and also applying) firewall rules may modify VM's "services",
which are stored in qubes.xml. This is the case for "Allow connection to
Updates Proxy" - which also enables/disables 'yum-proxy-setup' service.
Without this commit, such change was ignored.
FixesQubesOS/qubes-issues#2770
This reverts commit 4a3240bf1a.
VM names never contain any unicode characters, so this fix only
propagates the possibility of an encoding error to further down
the line, rather than removing it.
A proper fix would involve filtering the input to the search box
as we do with creating & renaming VMs.
* i18n:
i18n: update translations
i18n: add configuration for transifex client
i18n: add 'en' translation file as a source template
Translated some strings to test the process
i18n: add skeleton translation file for spanish
i18n: wrap strings with self.tr
i18n: add basic support for translations
Currently in gui-daemon/xside.c (only other holder of the lock):
g->inter_appviewer_lock_fd = open("/var/run/qubes/appviewer.lock",
O_RDWR | O_CREAT, 0666);
...
/* ignore possible errors */
fchmod(g->inter_appviewer_lock_fd, 0666);
It is too easy to accidentally delete the wrong VM if you use lots
of short-term (but longer than disposable) VMs and have built
muscle memory of just clicking "Ok" in the deletion confirmation box.
This patch requires you to type the full name of the VM, inspired by
repo deletion confirmation on GitHub.
If the clipboard file doesn't exist (and it doesn't at system startup),
pyinotify will output an error to stderr. This situation is already
handled by also monitoring the directory itself for CREATE event. But
prevent error message.
non-GUI thread can't open new window in PyQt. So as a band aid print the
message to stderr in such case.
And while at it, fix filename in error message (it was clobbered later
while constructing stack trace).
QubesOS/qubes-issues#1266
This was broken since 8a91c90 "Fix block attach/detach", which changed
rows_with_blk list to contain VM qid, not name. One place was left not
updated.
Additionally document VmRowInTable.update parameters, as some of them
may be not obvious (blk_visible=None).
FixesQubesOS/qubes-issues#1291
xterm closes itself immediatelly when the specified command ends, so
wait for user reaction to give a chance to read the message (potentially
some error info). Also add some more meaningful window title.
QubesOS/qubes-issues#982
The "default NetVM" is usually the first created ProxyVM which is
set by qubes-core during its creation. [1] If there is no ProxyVM,
there is no "default NetVM". Therefore, creating an AppVM and
launching its settings dialog raised AttributeError, because
get_default_netvm method returned None.
This can be reproduced by installing QubesOS without creating VMs
by installer.
[1] https://github.com/QubesOS/qubes-core-admin/blob/master/core/qubes.py#L355Fixesqubesos/qubes-issues#1008
Qubes manager used different logic what it considers as "running VM",
than qubes core.
Here it was "running or starting/stopping", while qubes core uses the
same as libvirt (isActive()), which effectively means "not halted" -
which includes also "paused" and "suspended". This creates a lot
confusion in which action should be available when.
The actual detected bug was about resuming paused VM. There was assert
"not vm.is_running()", while the paused VM _is_ running in terms of
qubes core.
Fixesqubesos/qubes-issues#981
QubesVmCollection is not thread safe. If for example update_table() will
be called during some long-running task (like creating or removing VM),
it will try to reload qubes.xml (so get read lock first), but the thread
already holds a lock on this file. This would result in "Lock already
taken" exception.
Fixesqubesos/qubes-issues#986
QubesVm object caches some domain state (domain ID in libvirt object,
Qubes DB connection socket), which can become out of date in
case of start/stop events. Currently it needs manual trigger to refresh
itself.
This reverts commit 227597cf93.
QubesWatch no longer supports xenstore, so there is no simple way to
get this column updated. This is conscious decision in process of making
R3 Xen-independent.
Conflicts:
qubesmanager/main.py
Those changes will take effect after VM restart (at least for VM windows
borders), so to not confuse the user with partly updated colors, simply
block the change while the VM is running. The same applies to VM name.
Check init_mem and max_mem_size in a single function (merging the
previous two) taking into account the minimum init memory that allows
the requested maximum memory.
Explanation:
Linux kernel needs space for memory-related structures created at boot.
If init_mem is just 400MB, then max_mem can't balloon above 4.3GB (at
which poing it yields "add_memory() failed: -17" messages and apps
crash), regardless of the max_mem_size value.
Base of Marek's findings and my tests on a 16GB PC, using several
processes like:
stress -m 1 --vm-bytes 1g --vm-hang 100
result in the following points:
init_mem ==> actual max memory
400 4300
700 7554
800 8635
1024 11051
1200 12954
1300 14038
1500 14045 <== probably capped on my 16GB system
The actual ratio of max_mem_size/init_mem is surprisingly constant at
10.79
If less init memory is set than that ratio allows, then the set
max_mem_size is unreachable and the VM becomes unstable (app crashes)
Based on qubes-devel discussion titled "Qubes Dom0 init memory against
Xen best practices?" at:
https://groups.google.com/d/msg/qubes-devel/VRqkFj1IOtA/UgMgnwfxVSIJ
In Fedora 20 sudo cannot be called from qrexec call (no tty available),
so run it in separate call as root.
Also add "-P" option to qubes-update-check call: for SysV systems it
should be ignored and service started as normal user (which is just
fine), but on systemd systems, the call would be redirected to
systemctl, which refuse normal user service actions. "-P" flag acquires
root privileges using PolicyKit.
Window size is fixed (calculated based on VMs count etc) so it isn't
useful. Without correctly calculated base size hint it can cause wrong
manager window size. It actually happens on fc20 in dom0.
Use directly rule provided by qubes core, not intermediate class
QubesFirewallRuleItem. This also will improve compatibility - if no
firewall changes made (but still "OK" clicked instead of "Cancel")
really the same settings are saved, even if rules contains some not
supported by Qubes Manager attributes.
Apparently KDE parses HTML tags in tray notifications only when some of
them appears on the first line of the message. So add some there.
This doesn't affect Xfce, which always parses HTML tags.
