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
Doesn’t -p (–persistent) automatically attach the drive?
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
Precisely I’m asking what’s the process I should follow.
I was wondering if I could detect in
target-vm is already up.
You should try
--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
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?
firstname.lastname@example.org loaded failed failed Start Qubes VM target-vm
Sep 28 04:02:05 dom0 qubesd: vm.target-vm: Starting target-vm
Sep 28 04:02:05 dom0 qubesd: vm.target-vm: Start failed: block device dom0:nvme1n1 not available
Sep 28 04:02:05 dom0 qvm-start: block device dom0:nvme1n1 not available
Sep 28 04:02:05 dom0 systemd: email@example.com: Main process exited, code=exited, status=1/FAILURE
Sep 28 04:02:05 dom0 systemd: firstname.lastname@example.org: Failed with result 'exit-code'.
Sep 28 04:02:05 dom0 systemd: 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: 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>
Why can’t I just
qvm-start target-vm at bootup, after a delay, like I’m trying to do above?
/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.
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?