unRAID: 7.3.2

Unsure which version this started with, but all my VMs aren't able to survive a reboot: force stop is required. This is for both Windows and linux VMs -- none of them have any pass through devices (did see an Nvidia reference). One of my VMs existed pre 7.3.x, and all my new 7.3.x created VMs are also showing this problem. At this point, I cannot complete creation of a Windows VM, as multiple reboots are required and Windows seems stuck in a setup loop.

Please post more details on how you are creating the VMs and when you see the issue, also the diagnostics after it happens.

26 minutes ago, JorgeB said:

Please post more details on how you are creating the VMs and when you see the issue, also the diagnostics after it happens.

Method:

1. Using guided GUI for Win 11.

2. Pinned to cores/threads that aren't in use (i9 9900k), using 4 total.

3. Initial/max memory: 8GB.

4. Machine: i440FX-10.2.

5. BIOS: OVMF-TPM.

6. Hyper-V: Yes.

7. Primary vDisk: custom location, as my NVMe isn't an Unassigned drive.

8. Networking bridge (two NICs)

9. No PCI pass through.

10. No USB pass through.

Have used "defaults" of creation for years, and the only change(s) are primary vDisk and amount of CPU/threads. Will get a diagnostic after next crash, which shouldn't take long.

Attached diagnostics zip.

greyskull-diagnostics-20260903-0801.zip

Thanks, the diags confirm that the new Windows VM was Force Stopped several times, but there is no QEMU crash or host-side error immediately before those stops. The reason=destroyed entries simply record the Force Stop itself.

Could you clarify exactly which operation fails:

- Restart from inside the guest

- Restart from the Unraid VM menu

- Stop from the Unraid VM menu

- Rebooting the Unraid server

Test Shutdown and Restart separately on one VM. When it becomes stuck again, before using Force Stop:

1. Take a screenshot of the VNC console and tell us exactly what is displayed.

2. Note the time and the action that triggered it.

3. Generate and attach fresh diagnostics.

4. Confirm whether the QEMU Guest Agent is installed and running inside the guest.

For the Windows installation, also tell us whether it remains on the restarting screen, goes black, or boots back into the installer.

I noticed that an older VM definition still references a Windows ISO that no longer exists, recommend removing or correcting that stale ISO reference, although it would not explain the same behavior affecting Linux guests.

- Restart from inside the guest

Restarting a headless linux (ubuntu server) or Windows 11 VM from the VM will not return a VNC-capable console.

- Restart from the Unraid VM menu

- Stop from the Unraid VM menu

Restart starts a reboot process (i.e. VNC console will go blank), but will not return a VNC-capable console.

Stop will not return a VNC-capable console.

Rebooting the Unraid server

Haven't tried rebooting unRAID server for VM, as force stop has worked.

1. Take a screenshot of the VNC console and tell us exactly what is displayed.

With Windows 11: the setup GUI screens are fine. With linux installer: whatever text installer is fine. I have full VNC console prior to a reboot attempt.

2-4: just got another hang, attempting to use console. Attaching a diagnostic. Oddly, a reboot after a force reboot worked. Guest agent installed on existing VM.

greyskull-diagnostics-20260903-0917.zip

Edited September 3Sep 3 by stashtv

Thanks. These diagnostics show the Linux VM being Force Stopped at 09:14:25 and starting normally nine seconds later. QEMU was still running when the diagnostics were generated, and there are no host-side errors explaining the original failure.

The next time Restart appears to fail, do not Force Stop immediately:

1. Confirm whether Unraid reports the VM as Running or Stopped.

2. Close the old VNC window and open a completely new VNC connection.

3. Check whether the guest is reachable through its normal network service—SSH for Linux, or ping/RDP for Windows.

4. Generate diagnostics while the failure is still present.

If possible, also run these from the Unraid terminal while it is stuck and post the output:

virsh domstate "<VM name>" --reason

virsh qemu-monitor-command --hmp "<VM name>" "info status"

virsh qemu-agent-command "<VM name>" '{"execute":"guest-ping"}'

For the Stop test, losing VNC is normal once the VM reaches Stopped. Start it again before checking whether VNC returns.

Since one reboot worked after the forced stop/start, this may be intermittent or limited to the VNC/display connection rather than every VM reboot failing.

Confirm whether Unraid reports the VM as Running or Stopped.

Unraid is reporting as VM as "started", showing the green play icon.

Close the old VNC window and open a completely new VNC connection.

Close, open new. Same thing, no console.

Check whether the guest is reachable through its normal network service—SSH for Linux, or ping/RDP for Windows.

No ping or RDP. Confirm its IP via my DHCP server, it will not respond by assigned IP.

Terminal outputs

root@Greyskull:~# virsh domstate "Windows 11 2026 v2" --reason

running (booted)

root@Greyskull:~# virsh qemu-monitor-command --hmp "Windows 11 2026 v2" "info status"

VM status: running

root@Greyskull:~# virsh qemu-agent-command "Windows 11 2026 v2" '{"execute":"guest-ping"}'

error: Guest agent is not responding: QEMU guest agent is not connected

I wanted to install the guest agent on this Windows 11 machine, but ran Windows updates first.

Diag attached.

greyskull-diagnostics-20260903-1242.zip

Reboots are rare to work and I managed to get far enough into a Windows 11 setup to complete guest tools installation.

virsh domstate "Windows 11 2026 v2" --reason

running (booted)

virsh qemu-monitor-command --hmp "Windows 11 2026 v2" "info status"

VM status: running

virsh qemu-agent-command "Windows 11 2026 v2" '{"execute":"guest-ping"}'

{"return":{}}

Another diagnostic added, as console is a goner and force stop is all I got.

greyskull-diagnostics-20260903-1619.zip

Since guest-ping succeeds, Windows has booted far enough for the Guest Agent to respond. This is therefore not a complete VM hang, despite the missing console.

The diagnostics also show QEMU still running and its VNC WebSocket listening. In the previous failure, the nginx-to-QEMU VNC connection was established, so this looks more like the emulated display/framebuffer failing after reboot than a noVNC connection problem.

All the VM definitions in your diagnostics use QXL video. As a test, cleanly shut down one VM, change only VNC Video Driver from QXL to VirtIO, then try several restarts. Don’t change the machine type, storage, or network configuration during that test.

If it fails again, tell us whether noVNC shows a connection error, a black screen, or a frozen image, and also run:

virsh qemu-monitor-command --hmp "<VM name>" "info vnc"

virsh qemu-agent-command "<VM name>" '{"execute":"guest-get-osinfo"}'

virsh qemu-agent-command "<VM name>" '{"execute":"guest-get-time"}'

virsh qemu-agent-command "<VM name>" '{"execute":"guest-network-get-interfaces"}'

While the Guest Agent remains responsive, you should also be able to avoid Force Stop by shutting the VM down cleanly with:

virsh shutdown "<VM name>" --mode agent

The unsuccessful ping/RDP test was from before Guest Tools were installed, so we still need to establish whether networking is working during the current agent-responsive failure.

Got another dead one here, but this is with Ubuntu server.

virsh qemu-monitor-command --hmp "Ubuntu Server" "info vnc"
default:
  Server: 0.0.0.0:5701 (ipv4 (Websocket))
    Auth: none (Sub: none)
  Server: 0.0.0.0:5901 (ipv4)
    Auth: none (Sub: none)
  Display: video0

virsh qemu-agent-command "Ubuntu Server" '{"execute":"guest-get-osinfo"}'
{"return":{"name":"Ubuntu","kernel-release":"7.0.0-31-generic","version":"26.04.1 LTS (Resolute Raccoon)","pretty-name":"Ubuntu 26.04.1 LTS","version-id":"26.04","kernel-version":"#31-Ubuntu SMP PREEMPT_DYNAMIC Sat Aug  1 04:26:38 UTC 2026","machine":"x86_64","id":"ubuntu"}}

virsh qemu-agent-command "Ubuntu Server" '{"execute":"guest-get-time"}'
{"return":1789252506843971000}

virsh qemu-agent-command "Ubuntu Server" '{"execute":"guest-network-get-interfaces"}'
{"return":[{"name":"lo","ip-addresses":[{"ip-address-type":"ipv4","ip-address":"127.0.0.1","prefix":8},{"ip-address-type":"ipv6","ip-address":"::1","prefix":128}],"statistics":{"tx-packets":2152670,"tx-errs":0,"rx-bytes":603841801,"rx-dropped":0,"rx-packets":2152670,"rx-errs":0,"tx-bytes":603841801,"tx-dropped":0},"hardware-address":"00:00:00:00:00:00"},{"name":"enp1s0","ip-addresses":[{"ip-address-type":"ipv4","ip-address":"192.168.11.9","prefix":24},{"ip-address-type":"ipv6","ip-address":"fd28:e9ff:3f5c:47d7:5054:ff:feea:8d07","prefix":64},{"ip-address-type":"ipv6","ip-address":"fe80::5054:ff:feea:8d07","prefix":64}],"statistics":{"tx-packets":1590215,"tx-errs":0,"rx-bytes":2664616098,"rx-dropped":1167,"rx-packets":3304886,"rx-errs":0,"tx-bytes":422377319,"tx-dropped":0},"hardware-address":"52:54:00:ea:8d:07"}]}

Unsure when it stopped responding, but its not accessible via ping/ssh. Attempting to use VNC via unRAID shows a frozen screen. Attached is a diag.

This also failed to stop via cli:

root@Greyskull:~# virsh shutdown "Ubuntu Server" --mode agent
 


error: Failed to shutdown domain 'Ubuntu Server'
error: guest agent command timed out: guest agent didn't respond to command within '60' seconds

greyskull-diagnostics-20260912-1537.zip

This capture is useful and differs from the earlier Windows reboot failure.

The guest-agent queries show that Ubuntu was still executing when those commands were run, but ping, SSH, and VNC were already unavailable. The later agent-assisted shutdown also timed out. This therefore appears broader than only a frozen VNC display.

The Unraid host itself looked healthy: QEMU was still running, the VNC listeners were active, system load and memory were normal, and the diagnostics contain no related kernel, QEMU, storage, or NVMe error. They do not yet identify where the guest became stuck.

Could you clarify:

1. When Ubuntu was last known to work and when it was first found unresponsive.

2. Whether this followed a reboot, update, idle period, or workload.

3. Whether the Windows VM has remained reliable since changing its video model to VirtIO.

After cleanly stopping Ubuntu, change only its video model from QXL to VirtIO and test again. Leave its CPU, memory, storage, machine type, and network unchanged.

If it happens again, please generate diagnostics before Force Stop and run these commands twice, about 30 seconds apart:

virsh domstate "Ubuntu Server" --reason

virsh domblkerror "Ubuntu Server"

virsh qemu-monitor-command --hmp "Ubuntu Server" "info status"

virsh qemu-monitor-command --hmp "Ubuntu Server" "info cpus"

virsh qemu-agent-command "Ubuntu Server" '{"execute":"guest-get-time"}'

virsh domstats "Ubuntu Server" --vcpu --balloon --block --interface

After recovering the VM, also attach its previous-boot journal:

sudo journalctl -b -1 --no-pager > previous-boot-journal.txt

If the problem still occurs with VirtIO video, the next useful comparison would be a minimal VM stored on the normal domains pool rather than the directly mounted SSD shared by the affected VMs.

1. When Ubuntu was last known to work and when it was first found unresponsive.

This VM was built around a week-ish. I don't monitor it (not critical), but the web interface (unifi server) was responsive up until at least Tuesday.

2. Whether this followed a reboot, update, idle period, or workload.

Idle period.

3. Whether the Windows VM has remained reliable since changing its video model to VirtIO.

Stopped using the Windows VM entirely, migrated to using Ubuntu for unifi server.

After cleanly stopping Ubuntu, change only its video model from QXL to VirtIO and test again. Leave its CPU, memory, storage, machine type, and network unchanged.

Will do this now that the server is responsive.

Small update @JorgeB : week-ish of uptime switching video to VirtIO on VM.

Correlation != causation, but I haven't changed anything else since. I am interested in trying the same change to a Win11 VM, just to see if it fixes the same issue.