Skip to content

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

Closed
Closed
Net Creation Fails on Second KVM Host Due to Invalid Bridge Name Format#10884
Milestone
unplanned

Description

@rbaweja
rbaweja
opened on May 16, 2025

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

Activity

  1. itobin commented on Jun 4, 2025

    @itobin
    itobin
    on Jun 4, 2025

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

  2. rbaweja commented on Jun 4, 2025

    @rbaweja
    rbaweja
    on Jun 4, 2025
    Author

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

  3. itobin commented on Jun 4, 2025

    @itobin
    itobin
    on Jun 4, 2025

    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.

  4. rbaweja commented on Jun 4, 2025

    @rbaweja
    rbaweja
    on Jun 4, 2025
    Author

    can you share your ifconfig?

  5. itobin commented on Jun 4, 2025

    @itobin
    itobin
    on Jun 4, 2025

    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

  6. rbaweja commented on Jun 4, 2025

    @rbaweja
    rbaweja
    on Jun 4, 2025
    Author

    can you share agent.log?

  7. itobin commented on Jun 4, 2025

    @itobin
    itobin
    on Jun 4, 2025

    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

  8. weizhouapache commented on Jun 4, 2025

    @weizhouapache
    weizhouapache
    on Jun 4, 2025
    Member

    @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"
    };

  9. itobin commented on Jun 4, 2025

    @itobin
    itobin
    on Jun 4, 2025

    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

  10. weizhouapache commented on Jun 5, 2025

    @weizhouapache
    weizhouapache
    on Jun 5, 2025
    Member

    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)

  11. daviftorres commented on Jun 30, 2025

    @daviftorres
    daviftorres
    on Jun 30, 2025
    Contributor

    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.

  12. weizhouapache commented on Jul 1, 2025

    @weizhouapache
    weizhouapache
    on Jul 1, 2025
    Member

    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

  13. apache
    locked and limited conversation to collaborators on Jul 7, 2025
  14. DaanHoogland
    converted this issue into a discussion #11148 on Jul 7, 2025
  15. DaanHoogland
    added this to the unplanned milestone on Sep 20, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions