Turn off rads? / terminal only? / reduce RAM?

Can Qubes use VMs that have no X server?

How does Qubes decide how much RAM to assign to a VM?

Can you reduce RAM a VM gets?

Depending on that, you might wish to disable rads. For info on rads, see:

Disabling rads could speed up booting.

For disabling it, see:
https://github.com/Whonix/rads/blob/master/etc/rads.d/30_desktop_default#L13

Eventually you might wish to add a config snippet for disabling rads + enabling kdm (harder + fastest) or reduce rads timeout (easy + not as big boot spedup gain).

Not sure.

Just ran a test by creating a new Whonix-Gateway ProxyVM with 128MB fixed RAM.

After bootup, I was able to successfully launch and use GUI apps, such as KWrite, etc.

So GUI apps (using X server?) are working with Whonix VMs using minimal fixed RAM well under the RADS threshold.

There is an “Initial memory” setting to set the base amount of RAM.

Then there is a (on by default) checkbox “Include in memory balancing” which allows you to set a “Max memory” setting. With this, Qubes automatically manages and balances memory amounts across VMs in real-time.

Default settings for memory amounts:

ProxyVMs: 300MB initial; 3000MB max

AppVMs: 400MB initial; 4000MB max

Yes. See above examples.

[quote=“Patrick, post:1, topic:768”]Depending on that, you might wish to disable rads. For info on rads, see:

Disabling rads could speed up booting.

For disabling it, see:
https://github.com/Whonix/rads/blob/master/etc/rads.d/30_desktop_default#L13

Eventually you might wish to add a config snippet for disabling rads + enabling kdm (harder + fastest) or reduce rads timeout (easy + not as big boot spedup gain).[/quote]

Yeah. Based on my test, it seems Qubes might not even be able to take advantage of RADS.

So this seems like a good idea. Faster startup is always nice to have.

Thanks Patrick! :smiley:

Did it boot up faster already?

Maybe rads was still starting KDM, that started the kde desktop environment that includes X? We’ll figure out…

Maybe even after reducing RAM, Qubes was still reporting “more than 512 available” due to this dynamic thing.

This is how rads detects available RAM:
https://github.com/Whonix/rads/blob/master/usr/lib/ram_adjusted_desktop_starter/ram_adjusted_desktop_starter#L204

 ## Check how much RAM the system has in total.
## Thanks to:
## http://stackoverflow.com/a/10277712
total_ram="$(free -m | sed -n -e '/^Mem:/s/^[^0-9]*\([0-9]*\) .*/\1/p')"

Please post the output of.

echo "$(free -m | sed -n -e '/^Mem:/s/^[^0-9]*\([0-9]*\) .*/\1/p')"

As well as the output of.

free -m

Another way to make sure KDM (X) isn’t running.

sudo service kdm stop

Maybe due the how Qubes is implemented, individual VM’s don’t even need their own X server, because it’s (securely) using a shared one.

Set configuration file “/etc/rads.d/50_desktop_default” with the following settings:

rads_autostart_decision_feature=0
rads_start_display_manager=0
rads_minium_ram=480
rads_skip_ram_test=1
rads_wait=0
rads_wait_seconds=0
rads_debug=0
rads_disable_rc_d_remove=0
x_default_dm_config_file="/etc/X11/default-display-manager"
rads_display_manager=""

Testing Whonix-Gateway ProxyVM:

With normal enabled RADS settings and dynamic memory, startup time was ~9-10 seconds.

With normal enabled RADS settings and fixed 128MB memory, startup time was ~10-12 seconds.

With modified disabled RADS settings and dynamic memory, startup time was ~9-10 seconds.

With modified disabled RADS settings and fixed 128MB memory, startup time was ~10-14 seconds.

If RADS wait time of 10 seconds is default set to on, then RADS doesn’t seem to be invoked in any case.

Whonix startup is similarly fast in Qubes for me under all tested conditions.

And I tested using HDD (non-SSD). So Qubes is fast at VM startup.

Maybe @nrgaway did something special regarding Whonix startup / RADS?

[hr]

[hr]

Don’t think so. Only reporting 113MB based on the tests, when I set to 128MB fixed RAM.

[hr]

[quote=“Patrick, post:3, topic:768”]Please post the output of.

echo "$(free -m | sed -n -e '/^Mem:/s/^[^0-9]*\([0-9]*\) .*/\1/p')"

Output with 128MB fixed RAM set:

echo "$(free -m | sed -n -e '/^Mem:/s/^[^0-9]*\([0-9]*\) .*/\1/p')"

113

[hr]

[quote=“Patrick, post:3, topic:768”]As well as the output of.

free -m

Output with 128MB fixed RAM set:

free -m

             total       used       free     shared    buffers     cached
Mem:           113        111          2          0          1         20
-/+ buffers/cache:         89         23
Swap:         1023         10       1013

[hr]

[quote=“Patrick, post:3, topic:768”]Another way to make sure KDM (X) isn’t running.

sudo service kdm stop

Not sure if this had any affect. Repeated command multiple times in a row, got same output each time:

sudo service kdm stop

[ ok ] Stopping kdm (via systemctl): kdm.service.

[hr]

I believe this is the case, based on memory of reading something like this. Also, I remember something like Joanna mentioning there was no X server trusted by Qubes (VMs?). I think GUI components are isolated to Dom0 and shared by VMs. I think Qubes R3 is supposed to be further isolating GUI components to their own domain.

Or it’s ignored for some reason due to Qubes boot implementation, that I don’t know yet very well.

To make sure it doesn’t add up boot time with default settings, please revert to default settings and add.

I guess it’s ignored.

Well, what rads is essentially doing after all the conditional checks is “sudo service kdm start”. (Or other display manager.) I guess in Qubes is does not matter if or when to run “sudo service kdm start” because of how Qubes implements VMs being able to use X. This hypothesis is strengthened by that you can run “sudo service kdm stop” (try this command in some usual KDE distro - or nevermind - it simply stops the graphical login session and mostly depending on settings it asks for a password for a virtual console) at infinitum without any effect.

[quote=“Patrick, post:5, topic:768”]To make sure it doesn’t add up boot time with default settings, please revert to default settings and add.

Reverted to defaults and then changed this setting to 60 seconds…

rads_wait_seconds=60

Testing Whonix-Gateway ProxyVM:

With RADS rads_wait_seconds=60 and dynamic memory, startup time was ~9-10 seconds.

With RADS rads_wait_seconds=60 and fixed 128MB memory, startup time was ~10-12 seconds.

Same startup results as before.

Looks like rads doesn’t interfere with Qubes then. Great. rads is a useless then, but that looks like a minor issue. Perhaps for Qubes even kdm / X does not even have to be installed.

Yes. Perhaps kdm / X does not.