CVM on XCP-ng - "Offline" disks

[rubenmmaia]

Environment:
2× standalone XCP-ng 8.3 hosts (dedicated storage, not pooled)
StarWind VSAN Free, CVM deployment (starwind-san-and-nas-console 2.7.4482.7103)
3× 1TB HDD per node, currently attached via VBD

The issue:
Storage disks attached to the CVM showed permanently Offline on the Physical Disks page, with 0 of 3 selectable in the Storage Pool wizard. Disks were otherwise completely healthy — visible via lsblk inside the CVM (correct size, no filesystem, no errors), and confirmed currently-attached: true at the XCP-ng host level.

In ManagementConsole.log, this repeating error explained it:
ERROR | [PhysicalDiskStateConverter]: Unknown physical disk state: 'Connected'
"Connected" is the state Xen's PV blkfront protocol reports for xvdX virtual block devices — confirmed directly in kernel boot logs:
platform_pci_unplug: Blkfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated disks.

Reproduced identically on two separate CVM instances/hosts, so not a one-off.
I had attached storage via standard VBD/VDI (virtual disks). The console's error message doesn't make this limitation obvious, since it just presents as a mysterious "Offline" state rather than an explicit "unsupported disk attachment method" message.

My deployment is a Converged (CI) scenario, not Hyperconverged: two dedicated storage nodes (standalone XCP-ng hosts, not joined to any pool) each running one CVM. The official CVM guide I found is written specifically for Hyperconverged (HCI) — storage and compute nodes joined into the same pool.

Is the PCI-E passthrough requirement identical for CI, or does converged deployment have different supported storage-attachment options?
Does a standalone (non-pooled) storage node need its own local XOA, or can it be managed through the XOA instance running on the separate compute pool, given it's never joined to that pool?
Is there CI-specific documentation comparable to the HCI guide, or does CI just mean "same CVM/passthrough/networking steps, minus the pool join"?
Is there a roadmap for virtual-disk (VBD) support on XCP-ng, or is PCI-E passthrough expected to remain the only supported path for the foreseeable future?

Thanks in advance for any pointers!

[yaroslav (staff)]

Welcome to StarWind Forum!
If those are purely storage boxes, consider trying a Linux-native installation through ISO (go for a bare-metal option). If you are up for something new, you can try requesting a Debian ISO (UEFI boot, newer ZFS, etc) from the person who shared the free key with you. You can quote this forum if they are a bit weary Again, this is NOT for production purposes until the official release…
For XCP-NG, please try pass-through. XCP-NG enumerates the devices xvda*, which is an issue for Ubuntu-based CVM (Debian-based one should be better).
Pass-through is the desired approach, as it allows the elimination of virtualization overhead in the long run, resulting in slightly lower latency.
I don't think we have any preferences on XOA, I think. You can manage them through one XOA.
As for documentation, you can just split it into storage and compute parts.

[rubenmmaia]

Thanks for the detailed reply, this really helped clarify things

I reached out to the person who shared my free key requesting access to the Debian-based bare-metal ISO, but haven't heard back after a couple of follow-ups. Is there another way to get access to it, or someone else on your end who could help facilitate this?
Also, just to close the loop on the passthrough suggestion: unfortunately that's not an option for me on this hardware — the boot SSD and the data disks share the same onboard SATA controller, so passing it through would take down the host's own boot disk too, and I don't have a separate HBA to dedicate. That's part of why the bare-metal Debian route is the path I'm hoping to pursue

Appreciate the help so far

[yaroslav (staff)]

If you have Free, "you are locked here with me"
I've DM-ed you. Please note that this is for internal use only; not for prod.
Try PVSCSI option or something to expose the entire RAID (individual disks); something like RDM. We did not test it

[nceloganb]

I’m running into something similar with XCP-ng and StarWind VSAN, and the Connected state explanation makes the behavior much clearer. It would be really helpful if the console explicitly reported that VBD-attached disks aren’t supported for this use case instead of simply showing them as Offline.

[yaroslav (staff)]

I think that's too much hassle to introduce a whole separate message.
The thing is that we don't normally configure CVM to use a sort of "thick disks". They are supported configuration, but We stick with RDM or pass-through.
Furthermore, we might introduce support for those disks down the road. Wait for the Debian-based CVM this fall.