You can build standard templates without X, accessible only via console
access, by hacking on (e.g) builder-debian.
The benefit is very marginal, and the use case limited.
(I haven’t tried disabling qubes-gui-runuser.)
1 Like
In my fedora-minimal a dnf remove xterm would result in removing 455 Packages and many of those look crucial like qubes-core-agent-stuff. Similiar to dnf remove ImageMagick…
I disabled qubes-gui-runuser yesterday with the following side effects:
- xterm doesn’t work (of course), but console works fine (it takes a bit longer to start the disposable VM, but it’s not big deal)
- the netmanager widget doesn’t display on the top bar anymore. Even though I like to know what wifi network I’m connected to from time to time, it really don’t mind reducing the memory footprint on that VM by another 100MB by losing that visual gimmick
Total memory savings between X and the network manager widget are about 200MB or even a bit more.
Since my problem is not disk, I did not uninstall X or any packages, just prevent qubes-gui-runuser from running (or just kill it after it runs).
I may seem stingy, but still remember when my computer only had 1MB of RAM in total and I could only use 640K as normal memory (and do acrobatics to get another 120KB or so in EMM)
4 Likes
So what is your final memory allocation for sys-net?
How is that done? I can’t find a qubes-gui-runuser.service or .socket in my sys-net. Google found qubes-gui-runuser mentioned in source code on github.
1 Like
I guess you need to disable qubes-gui-agent.service.
1 Like
I’m interested in your setup too, how much your ram allocation for sys-net ?
1 Like
Allocation doesn’t tell the full picture because swapping is not included there. Even with swappiness set to 1, with X and 600GB of max memory, the VM ends up swapping about 100MB (and I really don’t like swapping because it will end up wearing out my nvme faster, but I don’t want OOM conditions either).
sudo killall qubes-gui-runuser at the beginning works for me too. I don’t care about the max-mem allocation, since ballooning will move that memory around as needed, but I do care about actual utilization and swapping.
Without X, memory utilization hovers around 200MB on average. Compare this to the meager 64MB that Mirage-firewall takes
Again, to prevent swapping (but allow it if absolutely necessary), you can always set swappiness to 1. And max memory can be still set to a generous 600MB or so, since that memory can always be reclaimed as needed.
2 Likes
If I remember correctly that my minimal fedora sys-net is only 100-150MB without disabling any service or removing package like you do. Can you provide what package have you install to setup debian minimal ? Instead of using network manager widget, I don’t install those and use nmcli to configure wifi.
1 Like
How much are you swapping? I used the recipe here: Minimal templates | Qubes OS
and installed just these packages on top of it: `qubes-core-agent-networking, qubes-core-agent-network-manager and qubes-core-agent-dom0-updates (mirage-firewall doesn’t handle dom0 updates).
With X, memory utilization is roughly 300MB, including the 100MB swapped. Top memory hogs are Xorg, systemd-journal and nm-applet. If you are using xterm, xterm and qubes.StartApp also take a nice chunk of memory.
And I’m using debian-minimal, but I could try fedora to see if it’s better.
This doesn’t sound right to me.
I run a debian-11-minimal based sys-net and haven’t removed X nor changed any swap configurations. I got the network manager icon in the tray and it’s fully functional and responsive. I gave sys-net 250MB memory and no maxmem (no memory balancing). The Qubes OS tray icon shows me the qube is actually only using 234MB and when I run top from within xterm I see …
top - 09:52:41 up 12:44, 1 user, load average: 0.00, 0.01, 0.00
Tasks: 121 total, 1 running, 120 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.7 us, 0.8 sy, 0.0 ni, 98.0 id, 0.2 wa, 0.2 hi, 0.0 si, 0.2 st
MiB Mem : 180.1 total, 6.2 free, 147.0 used, 26.9 buff/cache
MiB Swap: 1024.0 total, 939.5 free, 84.5 used. 25.7 avail Mem
So there is some swapping but it can’t be very frequent or impacting performance much. CPU load for sys-net is typically between 1-4% while e.g. playing a YouTube video. In some cases I’ve seen a little over 5%, but never more than 10%.
I doubt disabling X would improve this much and I’d loose the network manager tray icon (which is doubtless useful). Not in my wildest dreams would I consider giving sys-net 600MB … for what?
1 Like
I changed swappiness to one (I like the idea) and ran top inside sys-firewall (via xterm).
Tasks: 128 total, 1 running, 127 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.2 us, 0.2 sy, 0.0 ni, 99.2 id, 0.2 wa, 0.0 hi, 0.0 si, 0.3 st
MiB Mem : 3880.5 total, 3255.7 free, 206.7 used, 418.2 buff/cache
MiB Swap: 1024.0 total, 1024.0 free, 0.0 used. 3526.0 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
363 systemd+ 20 0 17156 6300 5484 S 0.3 0.2 0:00.72 systemd-oomd
762 user 20 0 148468 62828 55272 S 0.3 1.6 0:00.84 Xorg
1019 root 20 0 7820 3864 3272 R 0.3 0.1 0:00.01 top
1 root 20 0 168296 12684 9732 S 0.0 0.3 0:00.11 systemd
Doesn’t look too bad to me. I stopped top when Xorg went up there to the second place.
edit: according to qube-manager-applet sys-firewall is eating almost 4gb of RAM now. 
I moved to Mirage-firewall 0.8 (using a nightly build from a few days ago) which uses a fixed 64MB of RAM (no swapping and no balancing). Been quite happy so far.
That’s consistent with what I see - but I don’t use swap, and it doesn’t
seem to hit performance.
I do use some headless qubes, but not for memory saving.
1 Like
This is memory usage on my Debian 11 minimal sys-net qube using top and sorting by memory. This is with Xorg and xterm running, of course.
I took a look at https://github.com/mirage/qubes-mirage-firewall and http://roscidus.com/blog/blog/2016/01/01/a-unikernel-firewall-for-qubesos/. Fascinating stuff.
2 Likes
If you’d like to try it, you can follow the instructions on that blog for the 0.7.1 build (the latest binary one) or, if you feel brave, try one of the nightly builds here: Job qubes-firewall on freebsd-12.
0.7.1 can only run in PV (due to a bug). The latest 0.8 nightly builds will run on PVH, which is better.
1 Like
Less ram use for sure…
But also is slower in packet filtering
2 Likes