Then, my earlier suggestion about upgrading was wrong, sorry, better to say so before you spend an evening on it.
I went and read the RPU code (it's about time!): shutdownPinnedVms only handles VM_HAS_PCI_ATTACHED, VM_HAS_VGPU and VM_HAS_SRIOV_VIF, and when anything else turns up, it hands back to XAPI's CANNOT_EVACUATE_HOST on purpose.
VM_REQUIRES_SR is not in that list, so an upgrade will not move you past it.
On the Rolling Pool Update side, the docs say all VM disks have to be on shared storage (https://docs.xcp-ng.org/management/updates), and the host reboot guide defines an agile VM as one not tied to local storage or local devices (https://docs.xcp-ng.org/guides/host-reboot).
With everything on local NVMe, that reads to me like RPU is closed to you by design rather than by bug.
The route the docs give for your case is the manual one: disable the host, shut the VMs down or migrate them, then reboot.
The Smart Reboot message looks like a separate problem. In XO's smartReboot a VM counts as suspend blocked in two different cases, either when blocked_operations.suspend is set, or when XAPI itself refuses VM.assert_operation_valid for suspend. The message only describes the first, which might be why clearing the protection changed nothing. These two will show which one you are in:
xe vm-list is-control-domain=false params=name-label,blocked-operations
xe vm-list is-control-domain=false power-state=running params=name-label,allowed-operations
If suspend is missing from allowed-operations, then XAPI is refusing it rather than a flag you set. I ran both on 8.3, so I know they print something per VM.
I have not tested any of this on a two-host pool, though, so the VM_REQUIRES_SR part is my reading of the code rather than something I reproduced.
