Simple design and better performance, just start() thread and finished
call back will show any error or msg, stop progress dialog and do cleanup.
Full remove of QT process_events() calls.
Added the following reactions ot VM dependencies in GUI tools:
- Qube Manager will inform the user why they cannot delete a VM (which
properties of which VMS [or global] are using the VM)
- Settings window will try to intelligently rename VMs (change
properties to the new name, if possible, and inform the user what went
wrong if not)
- Settings window will inform the user why they cannot delete a VM
Also, renaming VM from Settings launched from Qube Manager will
refresh the VM list through a horrible hack, to be replaced by a neater
Admin API solution in some near future.
depends on ca848ca7bdfixesQubesOS/qubes-issues#3992fixesQubesOS/qubes-issues#3993fixesQubesOS/qubes-issues#3892fixesQubesOS/qubes-issues#3499
Added a list of suggested services to the Services tab in VM Settings.
The list is drawn from man qvm-services (manually, not automatically).
fixesQubesOS/qubes-issues#3891
* qubesos/pr/95:
Revert last and removed pylint disables
Added BaseException
Show updates pending while running domain
Fix search coherence when adding a domain
Last no-member
Try with disable=no-member
Another try for travis
Disable no-name-in-module
Fix pylint warnings
Fix very unlikely case when user right clicks the VM in the exact moment he deletes it.
Don't close the settings window if something failed when renaming e.g. the VM name already exists
Revert "Since __lt__ methods are safe, is not needed to stop and reenable sorting."
Added standalone VM's to check_updates() Also added an initial call when creating the timer, most users will look for updates inmediately after start the manager
Since __lt__ methods are safe, is not needed to stop and reenable sorting. It causes a short freeze of the main window when reenabling, so better removing it.
Added try/except for all __lt__() methods since some VM could be deleted before the signal is received and handled.
Whenever Enter was pressed, the Settings window
closed and applied changes, which was very unintuitive
especially in case of Services tab.
references QubesOS/qubes-issues#3891
* 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
