Feature request: Trunk port in VM on KVM

Discussed in #10969

^{Originally posted by bhouse-nexthop June 5, 2025}
I was curious if there is any way to tag multiple vlans on a single interface going to a VM. I'd like to be able to use VLANs inside a VM for a specific lab purpose. There may be up to a couple hundred vlans, so interfaces aren't scalable. These would need to be admin-assigned vlans ... basically managed outside of cloudstack.

Maybe a separate ticket should be opened up just to support vlan-aware bridges in the first place (vlan-filtering) as it looks like the current implementation creates a bridge per vlan.

@weizhouapache

Hey @weizhouapache,

This idea sounds interesting for a LAB/PoC, but I’m concerned about the security risks.

As @bradh352 mentioned, it creates a 1-to-1 VLAN mapping per guest network. Would the L2 network type meet your needs, even though it isn’t a trunk?

The L2 network type is very flexible (maybe too flexible). It lets you assign any VLAN ID to a guest NIC, which could allow access to sensitive networks (like Management or Storage if sharing the same NIC).

Because of that, I’d have the same concerns about exposing a trunk port directly to a guest network. What’s your take on this?

We have a very odd use-case where we need 100+ VLANs passed to a vm that is managed externally. Right now we're using L2 for that and creating a network for each vlan, but it is quite a bit to manage and a lot less efficient than just trunking them.

Specifically the request would be an extension of the current L2 type, except instead of just being able to specify a single VLAN, you'd be able to specify multiple like 50, 55, 1000-1100. There should be no security risk since it would require an admin to set the vlan mapping.

@bradh352

@bradh352 Have you tried entering untagged instead of a VLAN ID in the L2 field?

I tested it to use the port’s default VLAN. I haven’t checked with a packet inspector though, so I’m not sure if any tagged traffic is still passing through.

@daviftorres

@daviftorres
I haven't explicitly tried that, but suspect it wouldn't pass the tagged vlan frames to the vm, at least with Linux bridges. Its possible you might get different behavior on OVS as those bridges are by default vlan-aware and when you attach an interface it assumes all vlans.

Besides, that wouldn't actually fit my usecase as I'd want to restrict what vlans can actually be forwarded.

I am looking for the same function. In VMware you can select the VLAN numbers you will allow through so this has some filtering. It would be really useful to replicate that in CloudStack.

This issue is stale because it has been open for 120 days with no activity. It may be removed by administrators of this project at any time. Remove the stale label or comment to request for removal of it to prevent this.

Would using vlan 4095 work https://cwiki.apache.org/confluence/display/CLOUDSTACK/Enable+vlan+4095+'tag+passthrough'+for+KVM ?

I was just looking for this functionality as we need to host firewalls with access to physical networks and vm networks and using trunk ports would greatly simplify access to the physical part of the network.

I searched for commits on vlan 4095

on vmware: ec4d83d
on kvm: aee35c9

it looks like vlan 4095 is ignored on kvm

in my opinion, what users need may be

vm runs on bridge without tag (for example cloudbr1)
libvirt tags like https://libvirt.org/formatnetwork.html#setting-vlan-tag-on-supported-network-types-only

  <vlan trunk='yes'>
    <tag id='42' nativeMode='untagged'/>
    <tag id='47'/>
  </vlan>

I have not tested it .

I tested this and basically just changing the tags allowed on the vnet interface makes it work if connected to an L2 network that runs untagged (and as such directly connected to the physical network bridge).

I don't know if such a quick fix is desirable or if a solution similar to openstack is more wanted (bundle networks under a parent network and custom tag each of these). Something similar to openstack can have benefits as it better supports VXLAN as well.

As for the benefits, having a trunk reduces the virtual interrupts which increases efficiency. On VNF VMs with dozens of NICs passing moderate traffic, it can save some CPU cycles, especially on edge zones.

@draggeta

I tested this and basically just changing the tags allowed on the vnet interface makes it work if connected to an L2 network that runs untagged (and as such directly connected to the physical network bridge).

I don't know if such a quick fix is desirable or if a solution similar to openstack is more wanted (bundle networks under a parent network and custom tag each of these). Something similar to openstack can have benefits as it better supports VXLAN as well.

As for the benefits, having a trunk reduces the virtual interrupts which increases efficiency. On VNF VMs with dozens of NICs passing moderate traffic, it can save some CPU cycles, especially on edge zones.

@draggeta

Thanks for the testing. Good to hear

The VM configuration looks straightforward, as you mentioned.

The potential challenges may include:

How VLANs are managed (the OpenStack approach works, but may not be ideal in this context)
Handling VLAN tags in the KVM plugin, which could impact VM operations such as start and migration
Ensuring the current network configuration continues to function as expected (NICs attached to Linux bridges with VLAN tags, e.g., breth1-XXX)

@bradh352

I'm wondering if , as said by @bradh352, supporting vlan aware bridges could be a first step to simplify trunking.

Then one could introduce a list of tags in a followup PR (e.g. vlan://1000,2200,30,untagged) as a possibility where nothing would change in existing deployments. For VXLAN I don't know what would be a good option as some mapping would need to occur somewhere

A better option may be to change the vlan list into an actual list supporting ranges as well, not just comma separated lists. This would probably require more effort though (haven't looked into the Java codebase yet).

Is this something that would fit the current direction at all?

I'm wondering if , as said by @bradh352, supporting vlan aware bridges could be a first step to simplify trunking.

Then one could introduce a list of tags in a followup PR (e.g. vlan://1000,2200,30,untagged) as a possibility where nothing would change in existing deployments. For VXLAN I don't know what would be a good option as some mapping would need to occur somewhere

A better option may be to change the vlan list into an actual list supporting ranges as well, not just comma separated lists. This would probably require more effort though (haven't looked into the Java codebase yet).

Is this something that would fit the current direction at all?

yes, supporting vlan aware bridges in cloudstack would be a first step. i was actually shocked when I first started using cloudstack that wasn't already used, took me a while to wrap my head around what cloudstack was doing.

i'm just not sure exactly what an integration plan would be like. I would assume a new network type might be needed unless it detects what the user specified as the base interface and if its a vlan-filtered bridge it decides based on that.

Even if a new network type would be used or a toggle (good idea btw), I'd say that moving both VLAN and possible VXLAN to vlan aware bridges would simplify operations and it's a change that could be done separately from the rest. The only issue is that basically when upgrading you'd need to reboot to get a working network stack again. All that logic is in a few bash scripts.

part of the problem is a lot of tooling doesn't support vlan-filtered linux bridges. Last I knew, even RedHat's NetworkManager didn't fully (which I think is the only option as of RHEL 10). I wish you could just deploy ifupdown2 everywhere, but even Ubuntu doesn't support that these days.

added to 4.24.0 tentatively

@weizhouapache

Hi @weizhouapache do you have any plans for this feature on 4.24?

Navigation Menu

Repository navigation

Feature request: Trunk port in VM on KVM #11491

Discussed in #10969

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Feature request: Trunk port in VM on KVM #11491

Description

Discussed in #10969

Activity

bradh352 commented on Sep 5, 2025

daviftorres commented on Sep 8, 2025

bradh352 commented on Sep 8, 2025

daviftorres commented on Sep 8, 2025

bradh352 commented on Sep 8, 2025

jonathaanbastin commented on Sep 29, 2025

github-actions commented on Jan 28, 2026

yadvr commented on Mar 11, 2026

draggeta commented on Mar 11, 2026

weizhouapache commented on Mar 11, 2026

draggeta commented on Mar 25, 2026

weizhouapache commented on Mar 25, 2026

draggeta commented on Apr 3, 2026

bhouse-nexthop commented on Apr 3, 2026

draggeta commented on Apr 3, 2026

bhouse-nexthop commented on Apr 3, 2026

weizhouapache commented on May 8, 2026

nvazquez commented on Aug 12, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions