Public bug reported:
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 ================== 1. Configure calico 2. Run openstack with libvirt 9.5.0 (latest in centos 9 stream) 3. Boot a VM 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) ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/2033681 Title: Calico still uses vif type tap and it causes failures with libvirt 9.5.0 Status in OpenStack Compute (nova): New Bug 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 ================== 1. Configure calico 2. Run openstack with libvirt 9.5.0 (latest in centos 9 stream) 3. Boot a VM 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/nova/+bug/2033681/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp