A clunky way of doing this is having qube A be the network VM of qube B. Is there a better way?
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
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
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
I was going to suggest exactly what @rustybird did.
For me it worked fine without these 
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
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.
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