How to auto-attach SSD to target-vm?

User Support General
1

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?

2

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

3

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

1 Like
4

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

5

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?

6

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?

7

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.

8

You should try

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

before target-vm is running

9

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/:

#!/usr/bin/bash
sleep 16
qvm-start target-vm

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

10

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

What journalctl says about this?

11

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

12

systemctl:

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

journalct:

Sep 28 04:02:05 dom0 qubesd[2959]: vm.target-vm: Starting target-vm
Sep 28 04:02:05 dom0 qubesd[2959]: vm.target-vm: 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>
13

Yes, I think this is my issue. Thanks.

I’ll take a look at this. Thanks.

14

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?

15

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.

16

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

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?