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.
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
/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
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
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
rc.local before the first
qrexec-client-vm command in the script.