How to auto-attach SSD to target-vm?

I have a secondary SSD that I always attach to the same VM (let’s call it target-vm). The SSD appears as dom0:nvme1n1. I want to attach it automatically when I start the computer. target-vm is started on boot. I can do this with:

qvm-block attach target-vm dom0:nvme1n1

Where can I run this command so it runs after target-vm has already booted up?

I’ll change my question:

How can I know if target-vm is already up?

I’ll add the code to a file in /etc/rc.d/init.d/.

Doesn’t -p (–persistent) automatically attach the drive?

1 Like

I tried. But it prevents target-vm from even starting.

Is there a file in dom0 for the VM when it is up, so I can check if the file exists, and then run qvm-block attach target-vm?

More details are needed about your target-vm and nvme1n1.
Did you try --persistent with privileges? Can you describe the whole process of what are you trying to do, step by step, until the goal fails?

My whole process so far has been running this on the command line:

qvm-block attach -p target-vm dom0:nvme1n1

Without sudo.

Precisely I’m asking what’s the process I should follow.

I was wondering if I could detect in /etc/rc.d/init.d/ if target-vm is already up.

You should try

qvm-block attach --persistent target-vm dom0:nvme1n1

before target-vm is running

As I said, this prevents target-vm from starting the next time I boot up the computer. I meant target-vm is an autostart VM. I think I wasn’t saying this clearly.

I now tried the opposite strategy: I unchecked “Start qube automatically on boot” in target-vm settings, and then tried to run this on /etc/rc.d/init.d/:

sleep 16
qvm-start target-vm

It doesn’t work either. target-vm isn’t started on boot up.

You said you tried -p while I proposed --persistent, sorry.

What journalctl says about this?

Maybe you hit into some bug, e.g. [1,2]?

If it works when you manually attach, you can also use [3] or [4] (the latter if you need encryption or wish to attach different parts of the disk to different VMs) to do it for you.
Disclaimer: I’m the author.

[1] Persistent block devices not available on AppVM start during boot · Issue #4975 · QubesOS/qubes-issues · GitHub
[2] Persistent USB device attachment does not work after dom0 reboot · Issue #5736 · QubesOS/qubes-issues · GitHub
[3] GitHub - 3hhh/qubes-callbackd: Daemon to react to Qubes OS events.
[4] GitHub - 3hhh/qcrypt: multilayer encryption tool for Qubes OS


qubes-vm@target-vm.service        loaded failed failed    Start Qubes VM target-vm


Sep 28 04:02:05 dom0 qubesd[2959]: Starting target-vm
Sep 28 04:02:05 dom0 qubesd[2959]: Start failed: block device dom0:nvme1n1 not available
Sep 28 04:02:05 dom0 qvm-start[3006]: block device dom0:nvme1n1 not available
Sep 28 04:02:05 dom0 systemd[1]: qubes-vm@target-vm.service: Main process exited, code=exited, status=1/FAILURE
Sep 28 04:02:05 dom0 systemd[1]: qubes-vm@target-vm.service: Failed with result 'exit-code'.
Sep 28 04:02:05 dom0 systemd[1]: Failed to start Start Qubes VM target-vm.
Sep 28 04:02:05 dom0 kernel: audit: type=1130 audit(1664337725.516:138): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=qubes-vm@target-vm comm="systemd" exe="/usr/lib/systemd/systemd" hostname>
Sep 28 04:02:05 dom0 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=qubes-vm@target-vm comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=fai>

Yes, I think this is my issue. Thanks.

I’ll take a look at this. Thanks.

Why can’t I just qvm-start target-vm at bootup, after a delay, like I’m trying to do above?

Is /etc/rc.d/init.d/ the wrong place for this?

Ah yes, you can do that. However it will only work once, i.e. not every time you start that VM e.g. via qubes-manager. Alternatively you could create a start shortcut for yourself that runs the commands when you click on it.

initd is not used by Qubes OS. Check out systemd to start stuff on boot. Alternatively use /etc/xdg/autostart (your display manager) with *.desktop files.

Thank you. This worked.

/etc/rc.d/init.d/README on dom0 says that:

Note that traditional init scripts continue to function on a 
systemd system. An init script /etc/rc.d/init.d/foobar is implicitly 
mapped into a service unit foobar.service during system 

But this doesn’t seem to true.

Am I right this is an “unreported issue” or am I missing something? Is it actually an upstream Fedora issue?