Hi There,

I installed with some effort the Homeassistant and managed to make it run, made some automations at home and then restarted the unraid server today. I am using the docker HomeAssistant_inabox_v3

Somehow it gave me a failure to start the VMs (Libvirt Service failed to start), so I read some posts with similar issue, suggested to remove the libvirt.img file (with the check box function), - oh damm, what a stupid I am that did not take a backup first! - , and still not working, changed the path to where system is (cache) - /mnt/cache/system/libvirt/libvirt.img - for the image and managed to start the VM services, created a new VM using the docker, and then it got stuck here (before it was going through the /mnt/user/system path).

Side note: If you are having a similar issue, before deleting anything, try to change the libvirt.img directory to the drive, and restart with Docker not enabled, once the VM services start, start the Docker. I realized that with Docker enabled, the VM start gives me issues. (might that be another issue that i have or give some clues?)

VirshError: virsh start 'Home Assistant' failed (1): error: Failed to start domain 'Home Assistant' error: Failed to create file '/etc/libvirt/qemu/nvram/9b188b6c-ddba-415b-bf41-9656acb37b80_VARS-pure-efi.fd.new': No such file or directory

after that, gave the whole qemu directory write access to test, recreate the docker, removed and create a new VM and the same issue occurred.

I left it back to read only because I dont like the idea of a docker having write access to an unraid system directory without knowing why that should change.

Anyways, I am attaching the system diagnosis with the hope that someone can guide me on what I need to do here and why the failures. Even better if somehow the is a way to recover that image that I had, I installed HACS and some community repositories to do some automations very helpful to me.

I want as well to understand why should i give the drive path directly instead of the user path, i though that was not a good practice, but more than anything, I want to solve this problem and get some insights of best practices on this type of VM to avoid loosing all the automations that I already prepared and did.

Thank you in advance for helping me with this issue.

unraid-diagnostics-20260925-2349.zip

Thanks for the diagnostics. They show two separate problems: one is why the VM service failed, the other is why the new VM will not start now.

1. "Libvirt Service failed to start" is a Docker start-order conflict

Your side note is the actual mechanism, not a coincidence. The HomeAssistant_inabox_v3 template maps the host path /var/run/libvirt/libvirt-sock into the container. That path is a socket which libvirt creates when the VM service starts. If Docker starts first, it finds no such file and creates a directory with that name. libvirt then cannot create its socket, so the service fails.

Your syslog contains both orders:

- Previous boot: Docker reported Starting containers... at 23:32:03. rc.libvirt started in the same second and reported libvirtd: error: Unable to initialize network sockets. Unraid then unmounted /etc/libvirt.

- At 23:35:54 you restarted the VM service while Docker was still running. It failed the same way.

- Current boot: the VM service started at 23:39:33 and Docker at 23:43:55. No error.

Two conclusions follow:

- Deleting libvirt.img was not necessary. The rebuilt image failed in the same way at 23:35:54, because the cause is outside the image.

- The image path is not the fix either. Your system share is cache-only, so /mnt/user/system/libvirt/libvirt.img and /mnt/cache/system/libvirt/libvirt.img are the same file. Keep the direct pool path if you prefer it. That is a good practice for loopback images. Keep the system share on the pool.

Workaround until the container is corrected: turn off autostart for HomeAssistant_inabox_v3, and start it after the VM service is up. The VM belongs to Unraid's VM manager, so that container does not need to run for Home Assistant to run.

The same report is in topic 200514: https://forums.unraid.net/topic/200514-vm-service-fails-to-start-after-every-reboot/, the durable fix belongs in the template, which needs to map the parent directory /var/run/libvirt instead of the socket file. Please also raise it in the container's support thread: https://forums.unraid.net/topic/176028-support-homeassistant_inabox/

2. The new VM fails because the NVRAM folder is missing error: Failed to create file '/etc/libvirt/qemu/nvram/<uuid>_VARS-pure-efi.fd.new': No such file or directory

This is "not found", not "permission denied". The write-access change was not needed, and you were right to revert it.

/etc/libvirt lives inside libvirt.img. When you create a UEFI VM from Unraid's own VM form, Unraid creates /etc/libvirt/qemu/nvram and copies the UEFI variables file into it. The container defines the VM directly and lets libvirt create that variables file from the template. libvirt creates the file, but it does not create a missing parent folder. Your new libvirt.img has no nvram folder, so every start fails.

With the VM service running, run this on the server:

mkdir -p /etc/libvirt/qemu/nvram

Then start the VM. libvirt creates the variables file itself.

If you prefer the GUI: add any VM with OVMF firmware from VMs → Add VM. Unraid creates the folder. Then delete that test VM and start the Home Assistant VM.

3. Your earlier Home Assistant install is probably still on disk

libvirt.img holds only the VM definitions. Your Home Assistant data, HACS and automations are inside the virtual disk in the domains share.

Before you start anything, look at /mnt/user/domains/ and compare folder names, file sizes and dates:

- A large .qcow2 from before today is your original disk.

- A small new .qcow2 is the wizard's empty disk.

If both exist, point the VM at the original file: VMs → edit the VM → set the primary vdisk location to Manual, then give the full path of the original .qcow2. The new NVRAM starts empty, but Home Assistant OS boots from the default EFI path, so a fresh UEFI variables file is not a problem.

Post the output of ls -la /mnt/user/domains/*/ if you want confirmation of which disk is which.

4. One unrelated note

Your domains share is set to not use the pool, and the VM disk is on the array (disk1 to disk3). Home Assistant then writes to parity-protected disks and keeps them spinning. Moving the VM disk to your cache pool gives better speed and lets the array spin down. That is a separate improvement, not part of these two failures.

ohh Woo, Thank you JorgeB

That was completely spot on! I even got to understand what the problem was. The original file directly started, so once I got the VM running I had to change nothing. I was expecting more from that docker and the management of the VM from there, as SpaceInvaderOne is someone with quite a bit of traction, so many issues might face similar issues (or already did). I posted there as well about the issue, as you suggested, so I hope this helpful for other users.

I will set as well the VM disks to the Cache and set the backup plugin job to back it up overnight.

For other users that might want to try something different: You can try the homeassistant docker, and if you need HACS, then you can use this guide: https://www.simplysmart.house/terminal From what I see, the VM makes it look easier to install HACS and the Apps, but the Apps seems unnecessary if you have docker in your unraid, and the HACS can be easily installed but with a "workaround"

If you really want a VM you can set one up yourself in VM manager, nothing complicated. The inabox stuff is supposed to make it simpler and set everything automatically, but it's... not very good.

29 minutes ago, Kilrah said:

If you really want a VM you can set one up yourself in VM manager, nothing complicated. The inabox stuff is supposed to make it simpler and set everything automatically, but it's... not very good.

indeed, a VM or a docker with Homeassistant it is less troublesome than the inabox stuff

Would it work if the Docker starts with a delay of lets say 5min? what is the boot sequence, does VM starts at the same time as Docker?

46 minutes ago, [email protected] said:

Would it work if the Docker starts with a delay of lets say 5min? what is the boot sequence, does VM starts at the same time as Docker?

The VM and Docker services are started at roughly the same time during the boot sequence. The Docker service has the ability to delay the start of particular containers, but the same is not true for VMs (currently although this could change in the future). This means VMs cannot make assumptions about whether specific Docker containers are started.

9 hours ago, itimpi said:

The VM and Docker services are started at roughly the same time during the boot sequence. The Docker service has the ability to delay the start of particular containers, but the same is not true for VMs (currently although this could change in the future). This means VMs cannot make assumptions about whether specific Docker containers are started.

ok, so if I just delay the start of that docker it would work.

But after all, I think I am going to try to move everything to the docker from linuxserver, as I think it is more efficient, and if I see the need to go back to the VM, I know now how.

Thank you all for the support here.

BTW, I've asked Ed and the issue should be fixed for new installs; existing ones need to correct the mappings

7 minutes ago, JorgeB said:

BTW, I've asked Ed and the issue should be fixed for new installs; existing ones need to correct the mappings

Great, Thanks. I see that on the changelog

Change Log

September 2026

• Fixes the VM service sometimes failing to start after a reboot. It happened when this container started first. If you already have it installed, its web page shows you the one setting to change.

• Fixes new installs failing on servers with no UEFI VMs yet.

• Open Home Assistant goes to the port Home Assistant confirms, even when something else like Emulated Hue is using port 80.

• Asks GitHub for the release list far less often. When GitHub is busy or can't be reached, it uses the last list it saved.

• After a reboot, watched VMs start again as soon as the VM service is up, and the Home Assistant icon stays next to the VM rather than going back to the generic one.

• Needs Unraid 7.0 or newer.