Memory saving techniques
75 views
Skip to first unread message
johny...@sigaint.org
Aug 23, 2016, 8:42:36 AM8/23/16
to qubes...@googlegroups.com
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
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
Frank Schäckermann
Aug 23, 2016, 9:08:39 AM8/23/16
to johnyjukya-at-sigaint.org |qubes-mailing-list/Example Allow|, qubes...@googlegroups.com
> On 23.08.2016, at 14:42, johnyjukya-at-sigaint.org |qubes-mailing-list/Example Allow| <567v7...@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.
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
> 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...@googlegroups.com.
> To post to this group, send email to qubes...@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.
Rusty Bird
Aug 23, 2016, 1:20:07 PM8/23/16
to qubes...@googlegroups.com, johny...@sigaint.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi JJ!
> In getting this working, I found that /usr/lib/qubes/qrexec-client
> was my friend, allowing to run commands in the VM's [...]
It's better to use "qvm-run --pass-io --nogui". That's a wrapper around
qrexec-client which, by default, colors the output red and removes
problematic* output bytes before they reach a dom0 terminal emulator.
> /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.
This will only persist if sys-net is a StandaloneVM, because otherwise
the qubes-gui-agent.service symlink (which "systemctl disable"
operates on) is in the TemplateVM's filesystem.
Rusty
* Currently, only ANSI escape sequences are filtered out, but the filter
is going to become stricter soon -- presumably in R3.2 RC3:
https://github.com/QubesOS/qubes-core-admin-linux/commit/e005836286ed4d5615c34608a088a30d9aa7a556
https://github.com/QubesOS/qubes-core-admin-linux/commit/c7ad14320ff5e3a37dc420efae308a36f966795b
-----BEGIN PGP SIGNATURE-----
iQJ8BAEBCgBmBQJXvIWqXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfLA0P/2PQ10YHB1Omx4fv30ku6sdv
lVPReWJqynYq1slGdk2xkkxykkzaUnmZbyutPrInxR0Mo9AU7EfC1qZOR/Rpk7MR
Gnn+hIdMYSU1GR+j3KuOH8hV8JHce+zyjuHxjTUREIosKOHUoO3jjIiVqEGWb5+P
6cYMuTf/WVoVfML2TSp5bSAcYgk9xlPhNA0nsAQIv1ize37YuSuriLFTbPgK4gOZ
CetGfRQHMlFaohlbvMv4x22jSM/UM8vNNO6zmn+V3tgG9KF4bcmUmcueswT+NCNp
evjtYJ+GzlxLN9EA7qyTQ4ZX1WwNjeUnOzKCa8/OF/Wk6dj7xyNcv5/QNlI4Q321
L1/jysntKaZCPUEUYt33uGd4vEopR47Q7L+QKy0mAXNHm6fq72xdUYdNy6oZOcl6
53OXNayxHjues7HVavev5O7NuC5iOGSMQ3laibQ9YWX/TP3Ou571QSD98V1O9+dv
vEOeMibyYTbziQj3eksgM7DFQwQmiQdC48VgPF0Yq2stV8RM3rqVSnCCAgzkxzzw
4gde6U0NaDo+8+uJdaRnLlej46DzWJjye6EO7mnFH4t3lQlmp5weURaIMZ5ZPK92
IasKdFYf7oEmIABS9sc44w40308l9U2RZ+EhEYtRTkeHmSi+JY12j5hiMiDq789r
1hfgYE1JnnnXMoArR/ot
=FMbA
-----END PGP SIGNATURE-----
Hash: SHA512
Hi JJ!
> In getting this working, I found that /usr/lib/qubes/qrexec-client
It's better to use "qvm-run --pass-io --nogui". That's a wrapper around
qrexec-client which, by default, colors the output red and removes
problematic* output bytes before they reach a dom0 terminal emulator.
> /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.
the qubes-gui-agent.service symlink (which "systemctl disable"
operates on) is in the TemplateVM's filesystem.
Rusty
* Currently, only ANSI escape sequences are filtered out, but the filter
is going to become stricter soon -- presumably in R3.2 RC3:
https://github.com/QubesOS/qubes-core-admin-linux/commit/e005836286ed4d5615c34608a088a30d9aa7a556
https://github.com/QubesOS/qubes-core-admin-linux/commit/c7ad14320ff5e3a37dc420efae308a36f966795b
-----BEGIN PGP SIGNATURE-----
iQJ8BAEBCgBmBQJXvIWqXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfLA0P/2PQ10YHB1Omx4fv30ku6sdv
lVPReWJqynYq1slGdk2xkkxykkzaUnmZbyutPrInxR0Mo9AU7EfC1qZOR/Rpk7MR
Gnn+hIdMYSU1GR+j3KuOH8hV8JHce+zyjuHxjTUREIosKOHUoO3jjIiVqEGWb5+P
6cYMuTf/WVoVfML2TSp5bSAcYgk9xlPhNA0nsAQIv1ize37YuSuriLFTbPgK4gOZ
CetGfRQHMlFaohlbvMv4x22jSM/UM8vNNO6zmn+V3tgG9KF4bcmUmcueswT+NCNp
evjtYJ+GzlxLN9EA7qyTQ4ZX1WwNjeUnOzKCa8/OF/Wk6dj7xyNcv5/QNlI4Q321
L1/jysntKaZCPUEUYt33uGd4vEopR47Q7L+QKy0mAXNHm6fq72xdUYdNy6oZOcl6
53OXNayxHjues7HVavev5O7NuC5iOGSMQ3laibQ9YWX/TP3Ou571QSD98V1O9+dv
vEOeMibyYTbziQj3eksgM7DFQwQmiQdC48VgPF0Yq2stV8RM3rqVSnCCAgzkxzzw
4gde6U0NaDo+8+uJdaRnLlej46DzWJjye6EO7mnFH4t3lQlmp5weURaIMZ5ZPK92
IasKdFYf7oEmIABS9sc44w40308l9U2RZ+EhEYtRTkeHmSi+JY12j5hiMiDq789r
1hfgYE1JnnnXMoArR/ot
=FMbA
-----END PGP SIGNATURE-----
Reply all
Reply to author
Forward
0 new messages