Bug 1949432

Summary: live update interface fail as the live interface type changed
Product: Red Hat Enterprise Linux 9 Reporter: Yanqiu Zhang <yanqzhan>
Component: libvirtAssignee: Laine Stump <laine>
libvirt sub component: General QA Contact: Yanqiu Zhang <yanqzhan>
Status: CLOSED MIGRATED Docs Contact:
Severity: unspecified    
Priority: unspecified CC: laine, virt-maint, xuzhang, yalzhang
Version: 9.0Keywords: MigratedToJIRA, Triaged
Target Milestone: betaFlags: pm-rhel: mirror+
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1887775 Environment:
Last Closed: 2023-09-22 12:19:51 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1887775    
Bug Blocks:    

Description Yanqiu Zhang 2021-04-14 09:42:28 UTC
Reproduces on:
libvirt-7.0.0-4.el9.x86_64
qemu-kvm-5.2.0-11.el9.x86_64
kernel-5.11.0-2.el9.x86_64


+++ This bug was initially created as a clone of Bug #1887775 +++

Description of problem:
update interface with <interface type='network'> will fail as the live interface type changed to direct/bridge. The patch
https://www.spinics.net/linux/fedora/libvir/msg203162.html fix the bridge type, but for the direct type and bridge type interface connected to ovs bridge, the issue still exists.

Version-Release number of selected component (if applicable):
libvirt-6.6.0-6.virtcov.el8.x86_64

How reproducible:
100%

Steps to Reproduce:
1. prepare a macvtap network like:
# virsh net-dumpxml direct-bridge
<network>
  <name>direct-bridge</name>
  <uuid>ab3c21e0-2282-47e0-8211-e8df2118664f</uuid>
  <forward dev='eno1' mode='bridge'>
    <interface dev='eno1'/>
    <interface dev='eno2'/>
  </forward>
</network>

and prepare interface xml as:
# cat interface.xml
<interface type='network'>
<source network='direct-bridge'/>
<mac address='52:54:00:59:cb:11'/>
<model type='virtio'/>
</interface>

 start the vm.

2. hotplug the interface device, then check the live xml, the interface type changed from <interface type='network'>  to <interface type='direct'>
# virsh attach-device rhel interface.xml
# virsh dumpxml rhel | grep /interface -B12
<interface type='direct'>
      <mac address='52:54:00:59:cb:11'/>
      <source network='direct-bridge' portid='a2dac94a-37b2-4fed-a166-b7ffc9931868' dev='eno1' mode='bridge'/>
      <target dev='macvtap0'/>
      <model type='virtio'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
    </interface>

3. use the xml with interface type='network' to do the update-device, it failed
# cat interface.xml
<interface type='network'>
<source network='direct-bridge'/>
<model type='virtio'/>
<link state='down'/>
  <mac address='52:54:00:59:cb:11'/>
</interface>
# virsh update-device rhel interface.xml
error: Failed to update device from interface.xml
error: Operation not supported: unable to change config on 'network' network type

Actual results:
in step 3, the live update failed

Expected results:
the live update should pass

Additional info:
This is the similar scenario with https://www.spinics.net/linux/fedora/libvir/msg203162.html

For ovs bridge, the live update will also fail.

--- Additional comment from Laine Stump on 2020-10-14 01:48:32 UTC ---

It appears that we're comparing the "ActualType" (direct in this case) to the config type of the modified interface ("network" in this case) rather than to the actual type that resolves to. This sounds eerily similar to:

commit bc85c34ea91c46588423fa24e56e09ca5aab31dd
Author: Laine Stump <laine>
Date:   Thu May 28 18:04:24 2020 -0400

    qemu: don't reject interface update when switching to/from bridged network
    

which went into upstream before 6.5.0, so should be in the build referenced here (6.6.0). I would guess that either I missed some case, or caused a regression. I can look at it next week.

Comment 2 Jaroslav Suchanek 2022-09-20 13:28:03 UTC
*** Bug 1887775 has been marked as a duplicate of this bug. ***

Comment 3 RHEL Program Management 2023-09-22 12:18:45 UTC
Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

Comment 4 RHEL Program Management 2023-09-22 12:19:51 UTC
This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.