Bug: "Using existing Host Bridge" not fully supported

[dschier-wtd]

Hi all,

today, I wanted to create a couple VMs with the "Using existing host bridge" configuration. This works, but has a minor display issue in Cockpit.

Reference: https://libvirt.org/formatnetwork.html#examplesBridge

Reproduce:

0. Create a bridge device (via nm or similar) with the name phybr0.
1. Create a new virtual network file bridge.yml with a configuration like so:

   <network>
     <name>bridge</name>
     <forward mode="bridge" />
     <bridge name="phybr0" />
   </network>

2. Apply the configuration with virsh net-define --file bridge.yml
3. The network will be displayed properly in Cockpit
4. Activate and Autostart the new network with virsh net-start bridge && virsh net-autostart bridge
5. Create a new VM with a network configuration like below

   
   <interface type='network'>
     <source network='{{ vm_net }}'/>
     <model type='virtio'/>
   </interface>
   ´´´

6. This works basically and the auto-delegation from libvirt to the bridge device works fluently
7. But, there is a minor display bug in Cockpit, since it seems not to be aware of this auto-delegation

Current Behavior

VM off:

VM on:

Expected Behavior

The "markers" for a pending configuration are not shown.

In Case you need any more details or support to squash this, please don't hesitate to ask for more details or testing :)

[KKoukiou]

The reason that this happens in that when starting the VM the type of the NIC changes:

When the VM is shutoff:

    <interface type='network'>
      <mac address='52:54:00:82:0d:66'/>
      <source network='bridge'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
    </interface>

When the VM is running:

    <interface type='bridge'>
      <mac address='52:54:00:82:0d:66'/>
      <source network='bridge' portid='10f57b6b-c34f-4f31-9b4e-5f70ffa8c235' bridge='virbr0'/>
      <target dev='vnet2'/>
      <model type='virtio'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
    </interface>

This needs to be checked with libvirt developers, if it's an expected behavior. Thanks for reporting this @dschier-wtd

[dschier-wtd]

Thank you for the quick response, In case something is needed from my side, don't hesitate to ping me :+1:

[jonpmyatt]

Hi, just reading this as I see #1098 has been closed as a duplicate of this issue... Looking at the comment above from Feb 15 2022, it seems this needs to be checked with the libvirt developers. Who needs to do that, please? Also, where does the type of the NIC change, as described above? I see the interface defined in the xml as per above but I don't see it changing. Is it happening elsewhere? Thanks for any help.

[mpatenaude]

Hello,

I'm experiencing this issue on OL 9.3. Like @dschier-wtd, I use a common "virtual network" definition to configure my VM network interfaces.

Straight forward bridge interface br0 defined on the hypervisor, virtual network named poc-lab-network:

[testuser@poc01]$ virsh net-dumpxml poc-lab-network --inactive

<network>
  <name>poc-lab-network</name>
  <forward mode='bridge'/>
  <bridge name='br0'/>
</network>

As @KKoukiou noted, this causes normal changes in the virtual machine interface definition between the inactive and live configurations. This appears to be by design and the reasoning behind using a virtual network definition for the interface type configuration.

My tests on OL9.3 show basically the same things that were previously reported:

[testuser@poc01]$ VM_NAME=vm01 ; diff -C 100 \
                    <(virsh dumpxml ${VM_NAME} --inactive --xpath '//interface') \
                    <(virsh dumpxml ${VM_NAME}            --xpath '//interface')

*** /dev/fd/63  2024-04-19 15:41:04.749420440 -0400
--- /dev/fd/62  2024-04-19 15:41:04.750420509 -0400
***************
*** 1,7 ****
! <interface type="network">
    <mac address="52:54:00:f1:9d:d9"/>
!   <source network="poc-lab-network"/>
    <model type="virtio"/>
    <address type="pci" domain="0x0000" bus="0x01" slot="0x00" function="0x0"/>
  </interface>

--- 1,9 ----
! <interface type="bridge">
    <mac address="52:54:00:f1:9d:d9"/>
!   <source network="poc-lab-network" portid="b92fa865-4e08-4ad6-a6eb-4d3482dd4742" bridge="br0"/>
!   <target dev="vnet6"/>
    <model type="virtio"/>
+   <alias name="net0"/>
    <address type="pci" domain="0x0000" bus="0x01" slot="0x00" function="0x0"/>
  </interface>

In the test above, I think that only the difference of these two lines: between the inactive

  <interface type="network">

and live

  <interface type="bridge">

configurations are relevant to the "Changes pending" erroneous state... But I don't have any knowledge of cockpit-machines' internals, I'm just saying this based on my observations (of this and other different interface configurations).

[mpatenaude]

Scratch my last comment, based on:

https://github.com/cockpit-project/cockpit-machines/blob/bfcfb73e133322498a3cce8067e076cafdfcb2ec/src/components/common/needsShutdown.jsx#L99-L106

it looks like at least needsShutdownIfaceType() and needsShutdownIfaceSource() will require extra logic to handle XML configurations containing <interface type="network"> since at the minimum, the type and the source change upon start. I'm not certain if there is a good way to handle this without greatly complicating these functions or if it actually makes sense to track the need for shutdown this way... Instead, for the network interface, maybe it should advise the user when he does changes via the cockpit interface that it must shutdown for the changes to apply, but not do a general check against the inactive config? Just curious to hear your thoughts.