JorgeB

It's fine to start the array, the pool will show as unmountable, but its data will remain accessible under /mnt/cashe-recovery

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.

You can use the latest release and take the opportunity to upgrade, recreate the flash drive with the current release, and then restore only the config from the backup.

The errors on disk7 are not logged as a disk problem, and SMART looks fine, so it's most likely a power/connection issue. Check/replace cables for that disk. Also, any power splitters in use?

These are typically fatal with btrfs, it means a device/controller lied about writes that weren't actually made. You can find some recovery options below, then reformat the pool https://forums.unraid.net/topic/46802-faq-for-unraid-v6/page/2/#findComment-543490

If iperf shows the low speed, it's typically a NIC (or its drive/settings), cable, switch, or client PC, try swapping some of those to rule things out.

It won't, but it would allow it to transfer the license to the new flash drive.

It's a known bug; you can follow it here https://product.unraid.net/b/unraid-os-bugs/p/7-3-0-beta-1-wrong-data-reported-in-parity-check-notifications

Check filesystem on disk1

If you are using the same container, the problem is likely with it, look for the container support thread.

You can; it should work, and if it doesn't, it would suggest an issue with the boot pool, and you could still boot again from the flash drive.

Pool was formatted correctly; it looks like just a display issue with the GUI, but I cannot see what's causing it. I recommend rebooting when you can.

Post a screenshot and new diags.

Do you mean in the GUI footer? Did you refresh the page?

The 2nd mirror has no available device, meaning, unless you can get at least one good device from that mirror, the pool will need to be destroyed and recreated.