Re: [qubes-users] Memory saving techniques
-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- iQJ8BAEBCgBmBQJXvIWqXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w 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- -- 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/c36d9935-0d8e-a6cf-3a59-d217f729db73%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Memory saving techniques
> 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.
>
> Impor
[qubes-users] Memory saving techniques
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
neces
