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.

Pool appears to have another member; post the output from zpool import

Did you confirm it works again without issues if you downgrade? If so, it's most likely some kernel/package regression; you may need to wait for an upstream fix and retest once an Unraid release with a newer kernel is out.

Please post the diagnostics after array start

Please post the diagnostics once it happens.

I would just replace them and try rebuilding, assuming the emulated disk is still mounting like it was in the screenshot.

Nope, they can upgrade to 7.2 since it has the empty disk mover option to help with the conversion, then can update to 7.3.

As an immediate workaround, try enabling Advanced View on the Docker page and select Force Update for the container. This should pull the image and recreate the container without requiring you to delete it manually. The update checker is intended to use the credentials saved by docker login. However, it queries the registry manifest API separately from docker pull. This can explain why pulling works while the update status shows not available. Could you please provide: - The Unraid version. - The registry software and version, such as Harbor, Gitea, GitLab, or Docker Registry. - Whether the registry uses HTTP or HTTPS. - Whether its TLS certificate is publicly trusted, privately signed, or self-signed. - A sanitized image reference that preserves the hostname format, port, path depth, and tag. For example, registry:5000/team/image:latest or registry.example.com:5000/team/image:latest. - Whether Force Update works, including the complete error if it fails.

Yep, that works.

You need to boot from a flash drive to run the wizard, so still recomend what I mentioned above.

As a first step try recreating the flash drive, first backup the current one, then recreate it using the USB tool, confirm the flash drive boots with the stock install, and if yes, restore only the /config folder from the backup overwriting any existing files.