Description of problem: Configure a virtual network using openvswitch and VLANs. Libvirt will refuse to boot a guest connected to this saying VLANs are not supported This is a regression introduced by the network refactoring in 5.5.0 Version-Release number of selected component (if applicable): 5.5.0 How reproducible: Always Steps to Reproduce: 1. Create an openvswithc bridge 'ovs-vsctl add-br ovsbr0' 2. Create a network $cat > ovs.xml <<EOF <network> <name>ovs-network</name> <uuid>2df1f528-f9ba-49d3-a4e9-08523c77c846</uuid> <forward mode='bridge'/> <bridge name='ovsbr0'/> <virtualport type='openvswitch'/> <portgroup name='vlan-prod'> <vlan> <tag id='20'/> </vlan> </portgroup> </network> EOF virsh net-define ovs.xml virsh net-start ovs-network 3. Create a guest using the network for one of its NICs: <interface type='network'> <mac address='52:54:00:d4:83:05'/> <source network='ovs-network' portgroup='vlan-prod'/> <model type='e1000'/> </interface> 4. Try to start the guest Actual results: error: unsupported configuration: an interface connecting to network 'ovs-network' is requesting a vlan tag, but that is not supported for this type of network Expected results: Guest starts Additional info:
Upstream fix is commit 93c1d5fe7bb7a62ef884eb41b505b2809d1704b6 Author: Daniel P. Berrangé <berrange> Date: Thu Aug 8 13:42:24 2019 +0100 network: fix ability to use openvswitch with vlans Use the correct enum constant when validating vlan usage. This fixes a merge error in commit 6cb0ec48bd95c95489a987e05a88e8bcf1f9109c Author: Daniel P. Berrangé <berrange> Date: Mon Sep 3 17:34:22 2018 +0100 network: convert networkAllocateActualDevice to virNetworkPortDef Reviewed-by: Michal Privoznik <mprivozn> Signed-off-by: Daniel P. Berrangé <berrange>
Reproduce on libvirt-5.6.0-1.el8.x86_64 and verify on libvirt-5.6.0-3.module+el8.1.0+4110+a6d45c3d.x86_64 with below scenarios, the result is as expected. 1. Scenario 1: # virsh net-dumpxml ovs-network <network> <name>ovs-network</name> <uuid>2df1f528-f9ba-49d3-a4e9-08523c77c846</uuid> <forward mode='bridge'/> <bridge name='ovsbr0'/> <virtualport type='openvswitch'/> <portgroup name='vlan-prod'> <vlan> <tag id='20'/> </vlan> </portgroup> </network> # virsh dumpxml vm1 | grep /interface -B5 <interface type='network'> <mac address='52:54:00:d9:17:2f'/> <source network='ovs-network'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </interface> # virsh start vm1 Domain vm1 started # virsh dumpxml vm1 | grep /interface -B10 <interface type='bridge'> <mac address='52:54:00:d9:17:2f'/> <source network='ovs-network' portid='e721a175-3705-4ec7-973f-7f4d758701ed' bridge='ovsbr0'/> <virtualport type='openvswitch'> <parameters interfaceid='58dde164-5966-46ce-9c49-d707b50133a8'/> </virtualport> <target dev='vnet0'/> <model type='virtio'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </interface> 2. Scenario 2: # virsh net-dumpxml ovs-network <network> <name>ovs-network</name> <uuid>2df1f528-f9ba-49d3-a4e9-08523c77c846</uuid> <forward mode='bridge'/> <bridge name='ovsbr0'/> <virtualport type='openvswitch'/> <portgroup name='vlan-prod'> <vlan> <tag id='20' nativeMode='untagged'/> </vlan> </portgroup> <portgroup name='port_4'> <vlan> <tag id='4' nativeMode='tagged'/> </vlan> </portgroup> </network> # virsh dumpxml vm1 | grep /interface -B5 <interface type='network'> <mac address='52:54:00:d9:17:2f'/> <source network='ovs-network' portgroup='vlan-prod'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </interface> <interface type='network'> <mac address='52:54:00:80:44:a0'/> <source network='ovs-network' portgroup='port_4'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x07' slot='0x00' function='0x0'/> </interface> # virsh start vm1 Domain vm1 started # virsh dumpxml vm1 | grep /interface -B13 <interface type='bridge'> <mac address='52:54:00:d9:17:2f'/> <source network='ovs-network' portgroup='vlan-prod' portid='2109cfd0-ade9-4288-a2eb-f4b504a2c014' bridge='ovsbr0'/> <vlan> <tag id='20' nativeMode='untagged'/> </vlan> <virtualport type='openvswitch'> <parameters interfaceid='c0e79cd8-6f92-4dd1-a881-c495003e075c'/> </virtualport> <target dev='vnet0'/> <model type='virtio'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </interface> <interface type='bridge'> <mac address='52:54:00:80:44:a0'/> <source network='ovs-network' portgroup='port_4' portid='af4375e0-7405-4d30-8408-2b9a3ae95d94' bridge='ovsbr0'/> <vlan> <tag id='4' nativeMode='tagged'/> </vlan> <virtualport type='openvswitch'> <parameters interfaceid='cf35685c-3996-4d47-bb0a-59bfbf1d29e8'/> </virtualport> <target dev='vnet1'/> <model type='virtio'/> <alias name='net1'/> <address type='pci' domain='0x0000' bus='0x07' slot='0x00' function='0x0'/> </interface> # ovs-vsctl list port vnet0 _uuid : 72e4a9b6-afe8-4452-9740-0ebb171ec8e1 bond_active_slave : [] bond_downdelay : 0 bond_fake_iface : false bond_mode : [] bond_updelay : 0 cvlans : [] external_ids : {} fake_bridge : false interfaces : [df00a9bb-65b8-46fb-80e4-07ce95801031] lacp : [] mac : [] name : "vnet0" other_config : {} protected : false qos : [] rstp_statistics : {} rstp_status : {} statistics : {} status : {} tag : 20 trunks : [] vlan_mode : native-untagged # ovs-vsctl list port vnet1 _uuid : 5076ee98-dc66-4217-9f71-b2a45609ea9b bond_active_slave : [] bond_downdelay : 0 bond_fake_iface : false bond_mode : [] bond_updelay : 0 cvlans : [] external_ids : {} fake_bridge : false interfaces : [85e73498-eec6-4270-bf31-f27ba51685ba] lacp : [] mac : [] name : "vnet1" other_config : {} protected : false qos : [] rstp_statistics : {} rstp_status : {} statistics : {} status : {} tag : 4 trunks : [] vlan_mode : native-tagged
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:3723