Bug 1314156

Summary: libvirt1.2.21 detach macvtap net device failed after live migration
Product: [Community] Virtualization Tools Reporter: Michael Liu <ztehypervisor>
Component: libvirtAssignee: Libvirt Maintainers <libvirt-maint>
Status: CLOSED DEFERRED QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: berrange, crobinso, dyuan, fjin, mzhan, yalzhang
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2024-12-17 12:10: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:

Description Michael Liu 2016-03-03 05:32:01 UTC
Description of problem:
start the virtual machine with SRIOV VF macvtap devices, detach the first macvtap device, then live migrate the vm to another host. After migration has been finished, detach one of the macvtap devices again. You will found detach operation is faild, there is an error like this one "2016-02-25 03:39:28.082+0000: 17161: error : virDomainNetFindIdx:13439 : operation failed: no device matching mac address 00:d0:d0:02:01:02 found on 0000:00:07.0".

Version-Release number of selected component (if applicable):
1.2.21

How reproducible:


Steps to Reproduce:
1. start vm with SRIOV VF macvtap devices
2. detach the first macvtap device
3. live migrate the vm to anoter host
4. detach macvtap device again

Actual results:
detaching is failed with error " error : virDomainNetFindIdx:13439 : operation failed: no device matching mac address 00:d0:d0:02:01:02 found on 0000:00:07.0"

Expected results:
detaching is successful after vm migrationg.

Additional info:
after migration newDef has been changed!
struct _virDomainObj {
    ......
    virDomainDefPtr def; /* The current definition */
    virDomainDefPtr newDef; /* New definition to activate at shutdown */
    .....
}

Comment 1 Cole Robinson 2016-04-10 22:13:10 UTC
Can you give the full VM XML and device XML you are trying to detach?
Since it appears you've poked into the code, can you try and debug a bit more what you think is going wrong?

Comment 2 Michael Liu 2016-04-26 23:06:53 UTC
(In reply to Cole Robinson from comment #1)
> Can you give the full VM XML and device XML you are trying to detach?
> Since it appears you've poked into the code, can you try and debug a bit
> more what you think is going wrong?
Late, I will chech and show the xml.
After the migration, VM config definition is diferent from live definition. When detaching the device according VM live defintion, there will be an error in detaching VM config definition.
Thanks.

Comment 3 Michael Liu 2016-04-27 06:23:11 UTC
(In reply to Cole Robinson from comment #1)
> Can you give the full VM XML and device XML you are trying to detach?
> Since it appears you've poked into the code, can you try and debug a bit
> more what you think is going wrong?
The device xml is similar to :

   <interface type='direct'>
      <mac address='00:d6:d1:00:05:03'/>
      <source dev='enp132s31f5' mode='passthrough'/>
      <target dev='macvtap0'/>
      <model type='virtio'/>
      <driver name='vhost'/>
      <link state='up'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03'function='0x0'/>
    </interface>
    <interface type='direct'>
      <mac address='00:d6:d1:00:05:03'/>
      <source dev='enp132s25f6' mode='passthrough'/>
      <target dev='macvtap1'/>
      <model type='virtio'/>
      <driver name='vhost'/>
      <link state='up'/>
      <alias name='net1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04'function='0x0'/>
    </interface>

a pair of bond network interfaces

Comment 5 Daniel Berrangé 2024-12-17 12:10:51 UTC
Thank you for reporting this issue to the libvirt project. Unfortunately we have been unable to resolve this issue due to insufficient maintainer capacity and it will now be closed. This is not a reflection on the possible validity of the issue, merely the lack of resources to investigate and address it, for which we apologise. If you none the less feel the issue is still important, you may choose to report it again at the new project issue tracker https://gitlab.com/libvirt/libvirt/-/issues The project also welcomes contribution from anyone who believes they can provide a solution.