How to have VM start on boot in the background?

[SteveC]

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.

[Quser59]

@SteveC

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

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!

[Quser59]

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

[Quser59]

@Quser59

Method 1
bash timing.sh

Method 2:
qvm-start x y

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

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

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

@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

[alzer89]

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

[Sven]

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.

[enmus]

@Quser59

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.

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.

[SteveC]

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.

[enmus]

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.

[SteveC]

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.)

[enmus]

@enmus

@Quser59

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.

After recent updates and couple of reboots, it looks to me that this is what exactly is happening now.

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

[Sven]

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.

[SteveC]

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.

[enmus]

Thanks for the feedback. The question was when several qubes are set to auto boot, are they’re waited to be booted first and then the login screen would be shown. For me it’s not happening anymore it looks.

[SteveC]

Yeah, I had no idea (before I saw this topic) that that was why it took so infernally long to boot (once, of course, I had unlocked the encrypted partition)!

So that’s a big relief. I’ll probably be a lot more willing to reboot my system now.

[weyoun.six]

hi @Sven ,

forgive me if this answer is already documented somewhere, but what method do you recommend to start applications via a script on a hotkey shortcut? i don’t want the script to remain open in the background until i close all the applications, as it does when sending qvm-run from a terminal. and i’m not sure exactly how this works, if different, when you execute qvm-run via a hotkey

[enmus]

@Sven

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

So does this mean your comp is fast, or you’re slow… making a tea

[Sven]

@weyoun.six that’s basic Unix command line usage: adding an ampersand at the end of your command will launch it and immediately return to the bash.

e.g. qvm-run work thunderbird &

[weyoun.six]

thanks for clearing that up! i’ve been using the & in my update script to start vm’s at the same time as i initiate updates, to speed up the process. should have occurred to me that this was the case…

[kenosen]

This would help my workflow immensely. I’ve drafted the below code for a single autostart script to allow a user to choose (work profile would also load requisite sys- qubes). This script requires Zenity in Dom0, which isn’t ideal, but I couldn’t quite figure out how to manage a hotkey setup, xmessage wasn’t available and less visually-appealing – thoughts and feedback always appreciated.

#!/bin/bash

declare -a work_qubes=("work-qube1" "work-qube2" "work-qube3")
declare -a system_qubes=("sys-net" "sys-firewall" "sys-usb")
declare -a admin_qubes=("" "" "")

start_qubes() {
  qubes_to_start=("${!1}")

  for qube in "${qubes_to_start[@]}"; do
    echo "Starting $qube..."
    qvm-start "$qube" || echo "Failed to start $qube"
  done
}

prompt_user() {
  startup_choice=$(zenity --list --radiolist --height 250 --width 350 --title="Select Start>

  case "$startup_choice" in
    "Work Qubes")
      echo "Starting work qubes..."
      start_qubes work_qubes[@]
      ;;
    "System Qubes")
      echo "Starting system qubes..."
      start_qubes system_qubes[@]
      ;;
    "Admin Qubes")
      echo "Starting admin qubes..."
      start_qubes admin_qubes[@]
      ;;
    *)
      echo "No option selected. Exiting."
      ;;
  esac
}

echo "QubesOS autostart script initialized"
prompt_user