I know I may be in the minority with an under-powered machine (4G), but I
thought I'd share some tips for getting more room for additional AppVM's
that worked well for me:
I guess I should state that this really would "void your warrantee" and
you shouldn't hassle the Qubes folks with problems you occur in a system
with these changes. :) But it lets me do more with Qubes, so I thought
I'd share.
Being tired the "insufficient memory" error when starting an AppVM, I
initially started on an experiment to make sys-net/sys-firewall
"headless," without an X server, using ssh to access these system VM's.
("systemctl disable qubes-gui-agent.service" to stop the X server from
starting.)
That took a lot of juggling, setting up local ssh config's in
/rw/config/ssh (linked from /etc/ssh), etc., and appropriate templates,
passwords/certificates, iptables for safety, and so on. Quite a pain to
set up, with potential security risks if not done correctly.
It worked well for sys-firewall, got it working well with 100M, versus the
300M it normally sucks up.
sys-net was a lot crankier, being a lot more "special" to dom0 with a
systemctl startup in dom0, hooks to the network manager in dom0, need to
access the ethernet device, and so forth. Really quite painful.
In getting this working, I found that /usr/lib/qubes/qrexec-client was my
friend, allowing to run commands in the VM's when ssh wasn't working
properly or whatever.
Which got me to thinking, if my main goal was to stop the GUI/X server,
one could simply do *that* from dom0 via qrexec-client on the existing
net/firewall VM's, without all the ssh configuration hassle, and creating
new net/firewall VM's.
And with VM's having swap space by default, even killing the GUI isn't
really necessary. Reduce the start/max memory for the VM's should be
enough to keep the useful networking stuff running, while the generally
unused X server being swapped out within the VM.
(Might be a little slower starting up, as things need to swap out, but
once the system settles and the net/firewall VM's just run networking
code, it's just as fast. It might also reduce the amount of memory
available for buffers/cache in these service VM's, but they're not file
intensive to start with, so that shouldn't be an issue, either.)
Much simpler, doesn't require modifying or creating VM's, and achieves the
goal.
I'm on a smoothly working system now, with sys-net and sys-firewall each
taking up 100M instead of 300M each, and sys-whonix (the gateway) taking
up 220M instead of the normal 600M-ish.
So for my normally way of working, that's 420M used instead of 1200M,
saving 780M (60%!). That good-chunk-of-a-Gig is enough to fire up
another couple of work AppVM's over what I used to be able to, a
significant productivity boost for me.
At the most simple, it involves setting the start/max memory in sys-net
and sys-firewall to 120M, and restarting, and you're good to go.
Some handy commands (sys-firewall can be substituted for sys-net in any of
the commands of course):
/usr/lib/qubes/qrexec-client -d sys-net 'root:free'
In a standard running VM, checking the among of memory actually "Used", as
a reasonable maximum memory limit for the VM:
You might want add 20M to that value for safety.
/usr/lib/qubes/qrexec-client -d sys-net 'root:ps axl'
To check out what's using real memory, under the RSS (resident set size)
column.
/usr/lib/qubes/qrexec-client -d sys-net 'root:systemctl'
To see what services are running. Stopping unneeded services is good way
to reduce the memory footprint.
/usr/lib/qubes/qrexec-client -d sys-net 'root:systemctl stop
qubes-gui-agent.service'
Stop the gui/X-server on a running VM. Note that the green Status button
in Qubes manager will turn yellow because of this, and you won't be able
to run windowed commands in that VM any more. Replace "stop" with "start"
to get it going again, if you need a Window for some reason.
/usr/lib/qubes/qrexec-client -d sys-net 'root:systemctl disable
qubes-gui-agent.service'
Make that disabling of the GUI persistent across VM restarts.
As mentioned, this might not be necessary/useful since the server should
swap out if not used.
xl mem-set sys-net 120 && xl mem-max sys-net 1200M
Sets current/max memory to a running sys-net to 120M. I think Qubes
manager might override this at times, so you'll want to change it in the
manager as well as using the xl commands to make it happen immediately.
Important: If you're going to fire up any Konsole/Terminals in
sys-net/sys-firewall/sys-whonix, or anything else with a Window, you're
going to swap that X-server back in, increasing memory demands, and things
might get slow/unsable/unusable. But for sys-net/sys-firewall/sys-whonix
that are generally untouched and quietly doing their netorking thing, it's
fine.
Obviously, the same technique could be applied to any other user AppVM's,
based upon their needs, to keep them from sucking up resources they don't
necessarily need.
Hope this helps someone be more productive, without causing any hassles!
If you've got 32G, don't waste your time with this. But for a 4G system,
it makes it a lot more useful.
And if you're going to post any system problems to the lists, please
change your settings back to the defaults and reboot, and verify the
problem still exists, before proceeding. The last thing I want to do is
create more grief for the great people behind Qubes. :)
Cheers,
JJ
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/a39188607dadf36184b82b4593732cb3.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.
