GitHub user prashanthr2 added a comment to the discussion: CloudStack 4.20 + XCP-NG 8.2: CloudStack tries to create VLANs instead of using existing labeled physical networks and Problem with Secondary Storage
@CGN-087 >> it seems CloudStack wants to reach Secondary Storage via the MGMT interface >> of the Cloudstack VM This is the default behavior. By default, CloudStack deploys the Secondary Storage VM (SSVM) and attempts to route all internal infrastructure traffic including traffic to your Secondary Storage NFS share over the Management (Private) Network interface. To isolate this and force CloudStack to route NFS traffic through your dedicated storage path, you must define a Storage Traffic Label under Zone ➔ Physical Networks. In an XCP-ng environment, this Traffic Label acts as a direct instruction to the hypervisor. You must set this label to match the exact name of the XCP-ng Network (specifically the PIF/Bond device name, such as XCP-ng Network 1 or a custom-named network bond) that is tied to your storage VLAN or SAN interfaces. Once configured, CloudStack will provision the SSVM's storage interface (eth3) and plug it directly into that specific XCP-ng network. The SSVM will then bypass the Management network entirely, utilizing the dedicated XCP-ng storage NICs to mount and communicate with your Secondary Storage repository. **Key Technical Details for XCP-ng Deployment** When mapping this out in XCP-ng (via XenCenter or XO), keep these three rules in mind: 1. Match the Network Name Exactly: The "XenServer/XCP-ng Traffic Label" you type into CloudStack must perfectly match the string name of the network asset as it appears inside XCP-ng. If your network in XCP-ng is named Storage_Network, your CloudStack traffic label must be Storage_Network. 2. IP Pool Allocation: Don't forget that after setting the traffic label, you must add a Storage IP Range in that same physical network configuration. The SSVM's storage NIC (eth3) needs a valid IP from that pool to successfully hit the NFS gateway or host target. 3. Storage Network vs. Primary Storage: Remember that in XCP-ng, Primary Storage (SRs like iSCSI or Fiber Channel) is handled natively at the host level via Xen API (XAPI). Configuring this Traffic Label in cloudstack specifically fixes the Secondary Storage (Templates/ISOs) pathway handled by the SSVM. GitHub link: https://github.com/apache/cloudstack/discussions/13369#discussioncomment-17266033 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
