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.
