* qubesos/pr/55:
Fixed according to @marmarek request
Fixed according to @marmarek request
Added 'configure no strict reset for PCI devices' button
Adding a button to list PCI devices and enable no-strict-reset
Fixed some indents and whitespaces
Fixed python2 in settings.py
The button is in 'devices' tab of VM settings; it allows the user to
select which devices should have 'no-strict-reset' enabled and tells
the user not to change this setting if there are no errors.
fixesQubesOS/qubes-issues#3205
When init page was 'firewall', the tool incorrectly displayed warnings about wrong firewall vm configuration, without actually checking if they should be displayed.
Enabled Firewall tab even when there's no working netvm or the netvm
doesn't support qubes-firewall. An appropriate warning label and message
are shown in both cases.
fixesQubesOS/qubes-issues#3290
Generally vm.features values are strings, need to cast them to boot to
use in such context.
Additionally fix typo in feature name ('services' -> 'service').
FixesQubesOS/qubes-issues#2947FixesQubesOS/qubes-issues#3104
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.
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.
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
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
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
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.
Settings are applied in separate thread, so when any exception occured there,
the user had no way to know it (besides hanging "applying settings" window).
