How to have VM start on boot in the background?

General Discussion
1

How can I make the VMs which startup on boot do so in the bakcground?

What I mean is, prioritise DOM0 startup and go straight to the UI login environment, whilst the VMs startup in the background.

I also note that when I had sys-whonix etc ‘start qube automatically on boot’ enabled, it took much longer for each VM to startup than just running qvm-start VM from DOM0 terminal. Further, this feature appears to wait for each VM to start before it initiates the startup of the next VM - this led to long load times.

Currently, I have just sys-usb automatically start, and my boot times are significantly reduced.

As the title asks, is it possible to modify the ‘start qube automatically on boot’ feature, so that:

  1. VM startup is done in parallel
    (For those with NetVM dependencies I’ve noticed setting netvm=none and then re-attaching the netvm dependencies is much quicker than waiting for each VM to start sequentially).
  2. boot prioritises loading into dom0/sys-gui, so whilst dom0/sys-gui loads and the user authenticate/types password - the VMs will load in the background.

I’d also like to ask other users of their experience in:

  1. long boot times waiting for VMs to start
  2. setting netvm=none for all VMs then ataching the netvm VS waiting for VMs to start sequentially.
1 Like
2

Personally I set all my qubes to ‘autostart = false’ to reach the login screen as fast as possible.

I have then two bash scripts called ‘qubes-start’ and ‘qubes-default’: qubes-start is set to run automatically at login (~/.config/autostart) and launches sys-usb, sys-net and sys-firewall; qubes-default is hooked to a keyboard shortcut and launches all the qubes and the apps in them I usually run all the time. This gives me the choice after logging in whether I want all those to start or not in case I am doing something other than the usual.

3 Likes
3

Thanks for asking this question; I had no idea how this process worked. I’ll probably end up doing something very like what @Sven described. I not only have sys-usb, I have TWO sys-nets and sys-firewalls (one for ethernet, one for wifi), whonix stuff (which I so rarely use I should just deactivate it for startup entirely), and things having to do with my split-veracrypt setup (which I am working on a post, to describe).

Having two sets of networking qubes plus whonix starting up before I see the prompt for my password probably explains why my bootup is so doggone slow!

Given that I’m one of those people who has to use a USB keyboard and mouse, perhaps I don’t even want sys-usb to be an automatic start…let me start it manually (and first, before any networking) right after login. I’ve had a number of occasions where I couldn’t get the keyboard to work to log in (even though sys-usb is installed right) and I have to reboot and try again.

4

This is in effect what I do. However this issue remains, and I would like some essential qubes, such as sys-usb, to start-up in the background, in parallel. I’m sure I’m not the only one.

Aside from networking dependencies (which can easily be solved by setting autostart.VMS netvm none then reataching the netvms via qvm-prefs VM netvm), I’ve noticed that qvm-start is also slower with multiple VM inputs, as opposed to running qvm-start x and qvm-start y in separate tabs at the same time.

time qvm-start x y yields circa 19s
time qvm-start x with qvm-start y yields circa 12s and 15s respectively (run in parallel)

If the boot process just calls qvm-start VMS then this would account for at-least a 30% delay - but in my experience the vm autoboot sequence can take much, much longer, so I assume some other checks are going on as-well.

5

You talk about running the qvm-starts in different tabs (presumably different tabs of a terminal window). If that’s what you’re doing, obviously that can’t be automated.

What happens if you do:

qvm-start x &
qvm-start y &

in a script? That could be automated, but would it time better or worse?

6

How much is that?

7 
#!/bin/bash
time qvm-start x &
time qvm-start y

bash timing.sh
vs
qvm-start x y

qvm-start x y gives a 20-30% delay on bash timing.sh

(qvm-start is waiting for x to start before it begins starting y).

at-least a minute. This was with the standard sys-whonix, which then waited for sys-net, sys-firewall, mirage-firewall. Also, as above, this waited until sys-usb had started.

Haven’t precisely timed it, but I know it was enough to be a real PITA. It’s had one benefit though, in that now my boot feels super-quick - perhaps it’s an anti-anti-feature.

*Also, on some previous R4.1 stable revisions (IDK if it’s still an issue because I only have sys-usb autostarting now and I haven’t noticed any false-starts), there were times where qubes failed to autostart for whatever reason (I never bothered to check the logs, it was fine when starting them post sign-in).

8

So you’re saying that the bash timing script is even slower than qvm-start x y? Wow.

here’s another thought (I’m spitballing)…what if each start were a separate bash script in .config/autostart? e.g. put an start-x.sh and a start-y.sh in .config/autostart. If the system starts those up in parallel, that should work well; if it executes them in some sort of sequence, then not so good. (For one thing, if it is sequential, then there should be a definition somewhere as to how that sequence is determined since someone might want to depend on it being sequential.)

I know I’m asking you to do experiments for me, and thank you–but I’m nowhere near my qubes machine right now.

1 Like
9

My apologies, I was following on from my previous post and my syntax was incorrect, I’ve amended my post - thanks for picking up on that!

1 Like
10

R/E netvm dependencies:::

I just did a crude test which:
Kills sys-whonix, sys-firewall & mirage-firewall (they are netvm dependencies in that order).
Then I measured the time to start sys-whonix.

Method 1: qvm-start sys-whonix
Method 2: set netvm of mirage-firewall, sys-firewall & sys-whonix to none. Start them all in parallel, then reattach the netvm.

Method 1:
Run a) 34.270s
Run b) 33.446s

Method 2:
run a) 32.391s Detach_netvms=1.890s start_vms=26.913s reattach_netvms=3.488s
run b) 33.163s Detach_netvms=1.820s start_vms=27.967s reattach_netvms=3.376s

11

TIme to last VM boot.

Method 1:
run a) 20.196s
run b) 19.770s
run c) 20.515s
run d) 20.382s

Method 2:
run a) 23.395s (15.8% slower)
run b) 23.441s (18.6% slower)
run c) 24.760s (20.7% slower)
run d) 23.020s (12.9% slower)

Repeated with 3 VMS X,Y,Z:
Method 1:
run a) 29.332s
run b) 28.904s
run c) 29.049s
run d) 28.930s

Method 2:
run a) 36.905s (25.8% slower)
run b) 37.790s (30.7% slower)
run c) 35.907s (23.6% slower)
run d) 35.539s (22.8% slower)

Edit:

@Sven are you running these sequentially, i.e:

qvm-start sys-usb &
qvm-start sys-net

?

If not, it would be interesting to see what performance difference the above change makes for you. If any other users have some spare time to do this test, they can use this bash script:

#!/bin/bash
qvm-kill --force x &
qvm-kill --force y &
qvm-kill --force z
wait
time qvm-start x &
time qvm-start y &
time qvm-start z
wait
qvm-kill --force x &
qvm-kill --force y &
qvm-kill --force z
wait
time qvm-start x y z
wait
qvm-kill --force x &
qvm-kill --force y &
qvm-kill --force z
wait
time qvm-start x &
time qvm-start y &
time qvm-start z
wait
qvm-kill --force x &
qvm-kill --force y &
qvm-kill --force z
wait
time qvm-start x y z
wait
qvm-kill --force x &
qvm-kill --force y &
qvm-kill --force z
wait
time qvm-start x &
time qvm-start y &
time qvm-start z
wait
qvm-kill --force x &
qvm-kill --force y &
qvm-kill --force z
wait
time qvm-start x y z
12

That solution will work, but I was going to say, if you wanted to use systemd to start a particular Qube on boot:

$qube_name=“The name of the qube you want to start on boot”
sudo systemctl enable qubes-vm@$qube_name

You can also edit that systemd service file to configure when it executes (ie before/after/during another service has started/completed/failed/etc).

That service file is located at /usr/lib/systemd/system/qubes-vm@.service.

Up to you :slight_smile:

13

I don’t care about performance in this specific case. It’s just one qvm-start after the other and then commands to launch the respective apps.

My usual sequence is:

  1. power on
  2. check heads attestation (green light on Nitrokey)
  3. enter TPM password to unseal Luks
  4. enter login password
  5. keyboard shortcut to launch default setup
  6. lock the screen
  7. walk away and make a tea / go to the restroom

Step 7) always takes longer than the script and the system is ready for me when I return.

14

After recent updates and couple of reboots, it looks to me that this is what exactly is happening now. Can someone confirm? My “automatically boot on startup” qubes aren’t there before login screen during boot. After logging, I just can’t see what is going on, cannot start terminal, nor Qube Manager because system is busy, probably with booting those qubes.

15

Doesn’t your system pop up notifications that it’s starting VMs?

If it’s popping a ton of those up, then I think you’ve got the answer to your question. If not, it COULD be you’re just not popping up notifications OR it could be something different.

16

The question was do you see auto-booted qubes booting before logging screen, under the Plymouth.
Me not anymore. Straight to the logging screen. I’m there in 30 seconds, while before it took (and showing) my auto-booted qubes additional minute to get to the login screen.

17

True, one gets to the Login screen a lot quicker than before.

But in your previous post, it looked to me like you were complaining that once logged in. you were pretty much frozen out because the system was starting the VMs at that time–but you weren’t sure that’s what was going on.

I haven’t, yet, logged in with a startup-the-VMs script yet. (The one thing I have tried was just to log in with nothing except sys-usb turned on. I then manually started everything. So I have no idea if my script to start up “sys” qubes even works, yet.)

1 Like
18

@Sven, is this your experience too? I’m poking since you were involved in this topic.

19

I don’t use sys-gui (yet) and use the setup I described for a long time… so I wouldn’t notice any recent change in behavior of autostarted qubes.

20

Just to report, I finally rebooted my system with a script to fire up the networking qubes (I have four of them) plus the two infrastructure qubes for split veracrypt; this script lives in ~/.config/autostart-scripts and simply does a qvm-start on the six VMs–there’s no background & on the commands).

sys-usb is the only qube that actually shows in my settings as being start qube on bootup. (I’m one of those folks with a USB keyboard and mouse; I don’t know what will happen if I don’t start sys-usb that way, and I can never recall the way to get around a frozen keyboard (which still happens to me from time to time on boot–I just reboot and it usually clears up the next time).

Anyhow, the VMs did start and I was able to open a terminal in dom0 while they were doing so, without interference–they weren’t hogging all resources. It took maybe 20 seconds for them to all start. So the process is now quick boot to login, do login, have this go on for 20 seconds. Overall that’s still faster (or at least it seems so), than having all of those start up during bootup, then getting a login screen and logging in.

PS I do NOT start the whonix stuff…I literally can’t use most of the sites I typically go to via Whonix, rendering it largely useless to me…so I don’t bother.