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]

Hi everyone,

i've already created a reddit but read at the docu site, to post here.

I'm new to the Apache CloudStack environment and have started building a POC. I'm using XCP-NG as the underlying platform. Originally I come from VMware and am considering removing the product from our portfolio due to the current conditions imposed by Broadcom.

There's one thing I don't quite understand, and I was hoping you could help me with it.

I've configured the networking on the XCP side: MGMT, SAN, Live Migration, etc. These are all on different VLANs except MGMT to make it able, to add hosts. MGMT is running on a 1 Gbps connection, while SAN and Live Migration are each on their own 25 Gbps fiber optic adapters. I can reach everything and it's working. I've also assigned the corresponding labels.

I installed CloudStack as a VM and started the setup. All hosts have been added successfully. However, I then got an error that storage cannot be added. By the way, I'm using XCP-NG 8.2 and CloudStack 4.20.

In the logs I could see a message for the networks from the zone (i.e. the physical networks) that basically said something like "I can't create a VLAN on a VLAN". This means CloudStack recognized the existing configuration on XCP-NG. I actually thought that by assigning the labels I was telling it which physical network to use, and not that CloudStack should try to create a new one.

Additionally, I can't access the Secondary Storage. Unlike Primary Storage, which is connected through the hosts, it seems CloudStack wants to reach Secondary Storage via the MGMT interface of the Cloudstack VM. That obviously doesn't work, because only the SAN interface/adapter has the necessary connectivity. How can I tell CloudStack to use exactly this path via the SAN adapter? Adding a PIF with an IP address from the SAN network didn't help.

Please don't stone me — I've read a lot and implemented quite a bit in this POC, but these points just aren't becoming clear to me.

Many thanks in advance for your help!

Best regards
Bastian

[CGN-087]

Hi Team, is there anyone who could help me to solve my questions?

BR
Bastian

[prashanthr2]

@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.