koushik

@Cyrille Thanks for the response.

Regarding the --controllers=cloud-node-label-sync flag: RKE2 does not use an external cloud-controller-manager (CCM) by default unless explicitly configured; it relies on its internal node controllers. Because of this, it won't automatically sync the topology.k8s.xenorchestra/* labels required by your CSI topology setup.

The main issue we are running into: Even though we applied the topology labels to the node objects manually, the XenOrchestra CSI driver's ExternalProvisioning loop is failing with a ProvisioningFailed error (error generating accessibility requirements: no topology key found for node).

This happens because the CSI driver expects the specific node providerID format to match XenServer / XenOrchestra constraints so it can look up and validate those manual topology keys.

Because RKE2 sets its own providerID formatting (providerID: rke2://koushik-xen01), the CSI driver cannot map the node to its Xen pool configuration.

Is there any flag or configuration in the CSI driver to completely bypass the strict CCM/Topology validation logic for non-native cloud setups, or do we have to wait for an update that allows an option like is-the-ccm-mandatory=false?

@Cyrille

we have RKE@ managing the cluster via its own CCM and seems xenorchestra is not supporting other external CCM providers and it requires XenOrchestra CCM to be mandatory which we cannot do as RKE2 Managing our clusters.

https://github.com/vatesfr/xenorchestra-csi-driver/blob/main/docs/topology.md#is-the-ccm-mandatory

Problem:

AS RKE2 our CCM, we can't run xen CCM and hence below node objects cannot be managed by xen.

topology.k8s.xenorchestra/pool_id = <uuid>
topology.k8s.xenorchestra/host_id = <uuid>
topology.k8s.xenorchestra/pool_name_label = <name>
topology.k8s.xenorchestra/host_name_label = <name>

We tried adding them manually on the nodes, but still the PVC is waiting and complaining

Is there a workaround available for now? or is it something getting released as part of the release cycle?