Can't Reboot VMs (or Force Reboot) or Start VMs - Getting Blocked by SR.Scan - But Running VMs are fine?

[MichaelCropper]

Same behaviour across XO, XOA + XCP-ng Centre.

Not had this before, I'm struggling to restart VMs. I first noticed that some of the backup tasks yesterday were running way longer than they normally do, and then still running into today which is when I started investigating the issue.

The biggest clue at the moment is when running the command;

xe task-list

uuid ( RO)                : 92b59f22-15ae-2551-8839-f0f938a07af7
          name-label ( RO): SR.scan
    name-description ( RO):
              status ( RO): pending
            progress ( RO): 0.000


uuid ( RO)                : 880f0f4a-8e84-0954-2521-81831d559dd3
          name-label ( RO): Async.VM.hard_shutdown
    name-description ( RO):
              status ( RO): pending
            progress ( RO): 0.273

Tried;

xe-toolstack-restart

Made no difference.

Just seeing if there is any more debugging I can do to try and get this working without doing a full host power off/on.

It's all strange though as the running VMs are all working fine.

The Storage Repository it appears to be getting stuck on is the one storing the ISOs for the VMs. Yet nothing has changed at all.

The Host can ping the Storage Repository fine too.

Any ideas what to test to get this back working without a full Host reboot?

I've been round the loop many times of killing the stuck tasks and then trying to Start/Stop VMs and same issue each time, just goes back to the same hung state.

Storage Repository is on a Windows machine, so the only thing that is jumping to mind is some janky automatic Windows update that has kicked in and broken something. But it's strange the running VMs are still working with their ISOs sitting in that same Storage Repository (I'm not 100% clear off the top of my head if running VMs still require access to the ISO Storage Repository to be running post-boot)

[Danp]

Check the output of dmesg -T|grep -Eiv 'guest|capacity|promiscuous' on the host. It's likely that there was a network disconnect at some point and you have a stuck mount. You could also check to see if df -h hangs when you execute it on the host.

[MichaelCropper]

@Danp

Thanks for that command, I had a similar command I found but it didn't display the timestamp fully so I couldn't pinpoint the time of the message, but I had a feeling this was there the issue was.

[Fri Aug  7 16:26:44 2026] CIFS VFS: Server 192.168.x.x has not responded in 120 seconds. Reconnecting...

Lots of these types of messages since yesterday.

And df -h does hang as that's something I was testing yesterday when debugging to see if some disk had got full that I hadn't spotted.

There has definitely been a few network disconnects over the past 24 hours as I was testing various things which requires a bit of fiddling with the cables and jumping between networks, and it's quite possible that this happened during the backup window but I can't recall for sure.

The Storage Repositories are all reporting as working correctly in XO, XOA, XCP-ng Centre.

What's the next steps to fix this?

I assume there is a way without deleting the Storage Repository in either XO/XOA/XCP-ng Centre and re-attaching it?