[Bug 2033681] Re: Calico still uses vif type tap and it causes failures with libvirt 9.5.0
Ioana Lazea
2033681 at bugs.launchpad.net
Wed Jun 17 10:56:12 UTC 2026
##### VERIFICATION EPOXY UCA ########
# Without the patch
Create a port, change the vif_type to tap, create a VM using that port.
VM creation fails with: "ERROR nova.virt.libvirt.guest libvirt.libvirtError: Requested operation is not valid: The tap0c8de43d-d1 interface already exists"
# With the patch
1. Enable proposed repository.
2. Install the package with the fix from proposed.
ii nova-api-metadata 3:31.0.0-0ubuntu1.2~cloud2 all OpenStack Compute - metadata API frontend
ii nova-common 3:31.0.0-0ubuntu1.2~cloud2 all OpenStack Compute - common files
ii nova-compute 3:31.0.0-0ubuntu1.2~cloud2 all OpenStack Compute - compute node base
ii nova-compute-kvm 3:31.0.0-0ubuntu1.2~cloud2 all OpenStack Compute - compute node (KVM)
ii nova-compute-libvirt 3:31.0.0-0ubuntu1.2~cloud2 all OpenStack Compute - compute node libvirt support
ii python3-nova 3:31.0.0-0ubuntu1.2~cloud2 all OpenStack Compute Python 3 libraries
3. Create a new port.
$ openstack port create --network 3198962c-d95d-4f49-86bb-5eff4ff53d63
my-patched-tap-port
4. Change the vif_type of that port.
UPDATE ml2_port_bindings
SET vif_type = 'tap',
host = 'juju-fbe223-verify-sru-9',
status = 'ACTIVE'
WHERE port_id = '1db21890-0e51-41e1-90bc-134e8cadf3b3';
5. Create a VM.
$ openstack server create --flavor m1.small --image cirros-0.4.0 --port
1db21890-0e51-41e1-90bc-134e8cadf3b3 --key-name my-key my-patched-tap-vm
6. VM is able to start and is in ACTIVE state.
| OS-EXT-STS:power_state | Running |
| OS-EXT-STS:task_state | None |
| OS-EXT-STS:vm_state | active |
| name | my-patched-tap-vm |
** Tags removed: verification-epoxy-needed
** Tags added: verification-epoxy-done
--
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to Ubuntu Cloud Archive.
https://bugs.launchpad.net/bugs/2033681
Title:
Calico still uses vif type tap and it causes failures with libvirt
9.5.0
Status in Ubuntu Cloud Archive:
In Progress
Status in Ubuntu Cloud Archive caracal series:
In Progress
Status in Ubuntu Cloud Archive dalmatian series:
Won't Fix
Status in Ubuntu Cloud Archive epoxy series:
Fix Committed
Status in Ubuntu Cloud Archive flamingo series:
In Progress
Status in Ubuntu Cloud Archive gazpacho series:
Fix Committed
Status in OpenStack Compute (nova):
Fix Released
Status in nova package in Ubuntu:
Fix Released
Status in nova source package in Noble:
Fix Committed
Status in nova source package in Questing:
Won't Fix
Status in nova source package in Resolute:
Fix Released
Bug description:
[ Impact ]
Starting with libvirt 9.5.0, the default behavior for TAP devices changed; it now expects to manage the creation and lifecycle of the TAP device itself.
In the case of using OpenStack with Calico networking, Calico is designed to pre-create the TAP device before handing it off to libvirt. Because libvirt 10.0.0 tries to "own" the device Nova already created, it fails to launch the instance.
The patch explicitly adds managed="no" to the interface configuration
in the libvirt domain XML. This tells libvirt to skip its management
attempt and simply use the device provided by Nova, restoring the
intended workflow.
[ Test Plan ]
Ubuntu does not have support for Neutron Calico (it isn't packaged).
While it is possible to deploy OpenStack Caracal on Ubuntu Noble and
configure it to use Calico, doing so requires additional manual
configuration and is significantly more complex.
Calico uses the tap VIF type. In Nova, this causes the networking code
to follow a legacy, non-OpenStack-specific code path, which is the
area affected by this patch.
A way to validate this patch is as follows.
1. Deploy OpenStack with ML2/OVS
This is important because OVS allows the vif_type of a port to be
modified directly in the Neutron database. Other backends, such as
OVN, will overwrite the vif_type and force it back to ovs.
2. Create a Neutron port and note the returned port ID
$ openstack port create --network <network_id> my-tap-port
3. Modify the port binding
Connect to the MySQL database and select the Neutron database:
mysql> USE neutron;
Update the port binding to use the tap VIF type. Replace the host and
port_id values with those appropriate for your environment:
mysql> UPDATE ml2_port_bindings
SET vif_type = 'tap',
host = 'juju-adc18e-flamingo-ovs2-9',
status = 'ACTIVE'
WHERE port_id = 'b6953c43-05a9-41fc-848a-788493a2197f';
Verify the update:
mysql> SELECT port_id, host, vif_type
FROM ml2_port_bindings
WHERE port_id = 'b6953c43-05a9-41fc-848a-788493a2197f';
4. Launch a VM using the newly created TAP port
$ openstack server create --flavor m1.small --image cirros-0.4.0
--port b6953c43-05a9-41fc-848a-788493a2197f --key-name mykey my-
forced-tap-vm
# Expected Results
## Without the patch
The instance enters the ERROR state and fails to boot.
Nova logs contain an error similar to:
ERROR nova.virt.libvirt.guest libvirt.libvirtError: Requested operation is not valid: The tapc5df06f4-2d interface already exists
## With the patch
The instance boots successfully and transitions to the ACTIVE state.
This was verified on Noble/Caracal and Noble/Flamingo, both deployed
with OVS.
[Where problems could occur]
This change specifically targets the XML generation for TAP interfaces.
Since Noble requires libvirt >= 10.0.0, we are not worried about backwards compatibility with extremely old libvirt versions that might not recognize the attribute.
[ Other Info ]
The bug has been reported upstream:
https://bugs.launchpad.net/nova/+bug/2033681
This fix is already merged upstream in Nova (see:
https://review.opendev.org/c/openstack/nova/+/967570) and is required
for Nova to function correctly on any distribution using libvirt 9.5.0
or newer, which includes Ubuntu Noble.
[ Old description ]
Description
===========
Calico (out of tree) uses vif type tap. But libvirt doesn't like pre-existing tap devices https://github.com/libvirt/libvirt/commit/a2ae3d299cf from libvirt 9.5.0. This causes openstack clusters that run calico networking backend to fail during instance creation.
Steps to reproduce
==================
Expected result
===============
The VM is able to boot without any problems
Actual result
Other information
=================
13:34:38 < sean-k-mooney> calico is apparently still using vif type
tap
https://github.com/projectcalico/calico/blob/cf7fa35475eba84f5afcd7f53ac7d07dcb403202/networking-
calico/networking_calico/plugins/ml2/drivers/calico/test/lib.py#L66C31-L66C34
13:35:06 < sean-k-mooney> vif type tap is not supported by our os-vif code so its usign the legacy fallback
13:35:51 < sean-k-mooney> https://github.com/openstack/nova/blob/master/nova/virt/libvirt/vif.py#L595-L596
13:36:15 < sean-k-mooney> https://github.com/openstack/nova/blob/master/nova/virt/libvirt/vif.py#L420-L430
13:36:48 < sean-k-mooney> https://github.com/openstack/nova/blob/master/nova/virt/libvirt/designer.py#L44-L55
13:37:40 < sean-k-mooney> zer0c00l: with that said the tap was always ment to be created by libvirt so it sound like calico might have been doing things it shoudl not have been
13:38:03 < zer0c00l> sean-k-mooney: Thanks for looking into this. :(
13:38:36 < sean-k-mooney> we could proably correct this with a bug fix
13:38:52 < sean-k-mooney> jsut setting managed='no'
13:39:13 < sean-k-mooney> here https://github.com/openstack/nova/blob/master/nova/virt/libvirt/vif.py#L427
13:39:54 < sean-k-mooney> the problem is that the there is no way to test this really upstream
13:40:06 < sean-k-mooney> well beyond unit/fucntional tests
13:40:12 < sean-k-mooney> but we dont have any calico ci
13:40:37 < sean-k-mooney> calico should be the only backend using vif_type=tap
13:40:52 < sean-k-mooney> but im not sure if we woudl need a config option in the workarounds section for this or not
Potential patch
===============
diff --git a/nova/virt/libvirt/config.py b/nova/virt/libvirt/config.py
index 47e92e3..5af3ce4 100644
--- a/nova/virt/libvirt/config.py
+++ b/nova/virt/libvirt/config.py
@@ -1749,6 +1749,7 @@
self.device_addr = None
self.mtu = None
self.alias = None
+ self.managed = 'no'
def __eq__(self, other):
if not isinstance(other, LibvirtConfigGuestInterface):
@@ -1851,7 +1852,7 @@
dev.append(vlan_elem)
if self.target_dev is not None:
- dev.append(etree.Element("target", dev=self.target_dev))
+ dev.append(etree.Element("target", dev=self.target_dev, managed=self.managed))
if self.vporttype is not None:
vport = etree.Element("virtualport", type=self.vporttype)
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/2033681/+subscriptions
More information about the Ubuntu-openstack-bugs
mailing list