Net Creation Fails on Second KVM Host Due to Invalid Bridge Name Format

[rbaweja]

problem

Summary:
When adding a second KVM host with identical bridge and VLAN configuration to an existing zone, CloudStack fails to create a VNet interface, throwing an error due to an invalid bridge name.

versions

Environment:

CloudStack Version: [e.g., 4.20.0.0]

Hypervisor: KVM

Host OS: Ubuntu 24.04 (or your exact OS)

Network Setup:

cloudbr0: Management (Access)

cloudbr1: Guest (VLAN-aware, native + trunked VLANs)

cloudbr3: Public (VLAN-aware, trunked, tagged at ACS level)

The steps to reproduce the bug

1. Create a working zone with one KVM host using ens1f0np0 for guest VLAN bridge (cloudbr1).
2. Add another KVM host with the same physical interface name.
3. Deploy a guest VM with a VLAN-enabled network (e.g., VLAN ID 1996).
4. Observe that the bridge creation fails on the second host.

What to do about it?

Observed Behavior
Agent log from new host shows:

Execution of process for command [.../modifyvlan.sh -v 1996 -p ens1f0np0 -b brens1f0np0-1996 -o add ] failed.

Error: argument "brens1f0np0-1996" is wrong: "name" not a valid ifname
... line 59: /proc/sys/net/ipv6/conf/brens1f0np0-1996/disable_ipv6: No such file or directory
Cannot find device "brens1f0np0-1996"
Failed to create br: brens1f0np0-1996

Root Cause
The bridge name brens1f0np0-1996 exceeds the 15-character IFNAMSIZ limit imposed by the Linux kernel.
Resulting bridge creation fails due to invalid interface name.

Expected Behavior
CloudStack should:
Generate compliant bridge names (≤15 characters).
OR pre-validate final bridge names before attempting creation.
OR use a shortened/hashed format (e.g., brv1996, brg123, etc.)

Temporary Workaround
Renaming physical interfaces to shorter names (e.g., eth0) avoids name length issues — but this is not sustainable or ideal in managed deployments.

Suggested Fix
Update the BridgeVifDriver or modifyvlan.sh logic to:

Enforce safe-length bridge names

Apply a safe naming convention that avoids appending full interface names + VLAN IDs blindly

[itobin]

also experiencing this issue, the vnet name needs to be reduced durting creation

[rbaweja]

i changed the name of the ETH and it worked.. also you can use bonds till this is rectified.

[itobin]

i renamed the interface in netplan which worked ok.

I also updated the bridgeto use the new name but when creating an instance it fails saying cloudbr1 doesnt exist although is does exist.

[rbaweja]

can you share your ifconfig?

[itobin]

sure, so enp11s0f0np0 is the issue, i had cloudbr1 bridged to it, as you can see below ive commented out the original nic and created a new one called csguest1 and set the mac address of enp11s0f0np0 to it. i can see the new nic and also cloudbr1 but CS says its cannot find cloudbr1

;enp11s0f0np0:
; dhcp4: false
; dhcp6: false
; optional: true

csguest1:
dhcp4: false
dhcp6: false
optional: true
match:
macaddress: 9c:6b:00:6d:80:a5
set-name: csguest1

cloudbr1:
   ;interfaces: [enp11s0f0np0]
   interfaces: [csguest1]
   dhcp4: false
   dhcp6: false
   parameters:
     stp: false
     forward-delay: 0

[rbaweja]

can you share agent.log?

[itobin]

heres the error on the management server

2025-06-04 14:13:52,604 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentConnectTaskPool-929:[ctx-59eab096]) (logid:bde67321) Notifying other nodes of to disconnect
2025-06-04 14:13:52,606 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentConnectTaskPool-929:[ctx-59eab096]) (logid:bde67321) Failed to handle host connection: com.cloud.exception.ConnectionException: Incorrect Network setup on agent, Reinitialize agent after network names are setup, details : Can not find network: cloudbr1

on the KVM host we can see the network does exist

4: csguest1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master cloudbr1 state UP group default qlen 1000
link/ether 9c:6b:00:6d:80:a5 brd ff:ff:ff:ff:ff:ff

8: cloudbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether b2:32:49:54:e2:96 brd ff:ff:ff:ff:ff:ff
inet6 fe80::b032:49ff:fe54:e296/64 scope link
valid_lft forever preferred_lft forever

[weizhouapache]

@itobin
I think the interface name csguest1 is not supported by cloudstack

the supported physical interface names are

    static String [] ifNamePatterns = {
            "^eth",
            "^bond",
            "^vlan",
            "^vx",
            "^em",
            "^ens",
            "^eno",
            "^enp",
            "^team",
            "^enx",
            "^dummy",
            "^lo",
            "^p\\d+p\\d+",
            "^vni",
            "^enc"
    };

[itobin]

that was it, i renamed the nic to enp10gb1 and now the VMs start :)

thanks for the help with it both of you.

One other question, assuming the long naming problems gets fixed, will this cause a problem if we rename the nics back to the defaults? I guess for existing VMs

[weizhouapache]

that was it, i renamed the nic to enp10gb1 and now the VMs start :)

thanks for the help with it both of you.

One other question, assuming the long naming problems gets fixed, will this cause a problem if we rename the nics back to the defaults? I guess for existing VMs

you might better keep both names (original and alias)

[daviftorres]

We encountered the same issue described in the linked thread, with an identical environment, host OS, and network setup. The suggested workaround worked for us, so we're sharing our configuration below as a reference for others:

network:
  version: 2
  ethernets:
    eth0:
      match:
        name: enp3s0f0
      set-name: eth0
    eth1:
      match:
        name: enp3s0f1
      set-name: eth1
    eth2:
      match:
        name: enp4s0f0
      set-name: eth2
    eth3:
      match:
        name: enp4s0f1
      set-name: eth3
  bridges:
    cloudbr0:
      <redacted>
      interfaces:
        - eth0
    cloudbr1:
      <redacted>
      interfaces:
        - eth3
    cloudbr2:
      <redacted>
      interfaces:
        - eth2

Important note:
Applying this configuration on a running system will likely cause failures—System VMs and Virtual Routers will need to be restarted.

Recommendation:
Make these changes during a scheduled maintenance window, ideally before applying patches or upgrading CloudStack components. This way, you can take advantage of the required restarts of the Agent and/or Management services.

Additionally:
This approach allows you to standardize interface names (e.g., eth0, eth1) across all nodes and clusters. It helps avoid unnecessary stress during NIC replacements in production, where a new interface might otherwise be assigned a different name.

[weizhouapache]

We encountered the same issue described in the linked thread, with an identical environment, host OS, and network setup. The suggested workaround worked for us, so we're sharing our configuration below as a reference for others:

network:
  version: 2
  ethernets:
    eth0:
      match:
        name: enp3s0f0
      set-name: eth0
    eth1:
      match:
        name: enp3s0f1
      set-name: eth1
    eth2:
      match:
        name: enp4s0f0
      set-name: eth2
    eth3:
      match:
        name: enp4s0f1
      set-name: eth3
  bridges:
    cloudbr0:
      <redacted>
      interfaces:
        - eth0
    cloudbr1:
      <redacted>
      interfaces:
        - eth3
    cloudbr2:
      <redacted>
      interfaces:
        - eth2

Important note: Applying this configuration on a running system will likely cause failures—System VMs and Virtual Routers will need to be restarted.

Recommendation: Make these changes during a scheduled maintenance window, ideally before applying patches or upgrading CloudStack components. This way, you can take advantage of the required restarts of the Agent and/or Management services.

Additionally: This approach allows you to standardize interface names (e.g., eth0, eth1) across all nodes and clusters. It helps avoid unnecessary stress during NIC replacements in production, where a new interface might otherwise be assigned a different name.

thanks @daviftorres for the sharing

in our testing environments, we use net.ifnames=0 biosdevname=0 in the grub config, all the servers (ubuntu, debian, rhel variants) use ethX. it makes configuration easier