Can I make VM A start every time I start VM B?

User Support
1

A clunky way of doing this is having qube A be the network VM of qube B. Is there a better way?

2

You can use qrexec to pass the command to dom0, and use a policy to control which qubes are allowed to execute the command.

1 Like
3

Yes, you can.
Use && with the shortcut that you run your VM B. For example:
qvm-run -q -a --service -- personal qubes.StartApp+firefox-esr && qvm-run -q -a --service -- work qubes.StartApp+firefox-esr

But keep in mind, that the process is synchronous, so it will fire the personal qube, then launch firefox, then start work qube and then launch work’s firefox

4

Expanding on @renehoj’s suggestion: If you add the line

admin.vm.Start + B A allow target=dom0

to /etc/qubes/policy.d/30-user.policy in dom0, this would allow B to run

qrexec-client-vm A admin.vm.Start </dev/null

(e.g. as part of its /rw/config/rc.local startup script)

Edit: Fixed the policy (by adding target=dom0) and qrexec command (by adding </dev/null)

2 Likes
5

I was going to suggest exactly what @rustybird did.

For me it worked fine without these :person_shrugging:

6

Take a look at the exit code of the qrexec-client-vm command: It’s 127 if target=dom0 is missing in the policy, because it tried to run the admin.vm.Start RPC in A, where it doesn’t exist. Conceptually nonsense, but in this case it still causes dom0 to start the VM in the process of attempting to run the RPC, lol

2 Likes
7

There seems to be some race condition that prevents this to work sometimes, so I had to put it at the bottom of /rw/config/rc.local in VM B.

8

Yes, I forgot about that:

As a workaround I always add the line

/etc/qubes-rpc/qubes.WaitForSession

in rc.local before the first qrexec-client-vm command in the script.

3 Likes