> On 23.08.2016, at 14:42, johnyjukya-at-sigaint.org
> |qubes-mailing-list/Example Allow| <567v794...@sneakemail.com> wrote:
>
> 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.
Hi John!
You may also want to search the list for "Unikernel proxyVM". Depending on your
firewalling needs, this may be a way to save another 70MB per proxyVM.
Regards, Frank
>
> 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.
--
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/BCFFBD55-9504-4BB8-921A-04D1E35C522A%40schaeckermann.net.
For more options, visit https://groups.google.com/d/optout.
