Bug 1343919
Summary: | Error MAC info when detach device from guest without designated MAC address | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Jingjing Shao <jishao> | ||||
Component: | libvirt | Assignee: | Laine Stump <laine> | ||||
Status: | CLOSED ERRATA | QA Contact: | yalzhang <yalzhang> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 7.2 | CC: | bugproxy, dyuan, dzheng, hannsj_uhl, jdenemar, laine, mprivozn, mzhan, rbalakri, xuzhang, yafu, yalzhang | ||||
Target Milestone: | rc | Keywords: | Upstream | ||||
Target Release: | 7.5 | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | libvirt-3.9.0-1.el7 | Doc Type: | If docs needed, set a value | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2018-04-10 10:36:45 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: | |||||||
Bug Blocks: | 1399177, 1476742, 1522983 | ||||||
Attachments: |
|
Description
Jingjing Shao
2016-06-08 10:25:45 UTC
(In reply to Jingjing Shao from comment #0) > Expected results: > it should report the right MAC address > i.e: > error: operation failed: no device matching mac address 52:54:00:e6:ea:f9 > found This would be totally wrong since the interface with mac address 52:54:00:e6:ea:f9 is clearly present in domain configuration. Not to mention that if the XML was good enough for libvirt to find the right interface, libvirtd could just detach it without reporting any error. The problem is that libvirt generates a new mac address for any interface XML that lacks it. We should probably stop doing that and rather report an error saying the XML does not contain enough data for libvirt to be able to find it. There have been a few attempts to remedy this - here's the latest: https://www.redhat.com/archives/libvir-list/2016-May/msg02062.html (the response points to commit ea7182c, which caused a regression fixed in c001eb5). I actually like the idea of what ea7182c was trying to do: "With this patch users can specify only those information which specify one device sufficiently". Note that this was done in virsh, not in libvirt itself. *** Bug 1497054 has been marked as a duplicate of this bug. *** Oh, I've completely forgot about the patch linked in comment 2 and started working on this because of the following upstream report: https://www.redhat.com/archives/libvir-list/2017-September/msg01078.html In the end, I've came up with something very similar: https://www.redhat.com/archives/libvir-list/2017-October/msg00015.html Created attachment 1333544 [details]
Guest XML
I've just pushed patches upstream: commit 7e9f171d8bbe5b56b8490016371e845d0f3b361a Author: Michal Privoznik <mprivozn> AuthorDate: Mon Oct 2 12:43:04 2017 +0200 Commit: Michal Privoznik <mprivozn> CommitDate: Wed Oct 4 17:10:12 2017 +0200 virDomainNetFindIdx: Ignore auto generated MAC addresses When detaching an <interface/> from a domain, the MAC address is parsed and if not present one is generated. If no corresponding interface is found in the domain, the following error is reported: error: operation failed: no device matching mac address 52:54:00:75:32:5b found where the MAC address is the auto generated one. This might be very confusing. Solution to this is to ignore auto generated MAC address when looking up the device. Signed-off-by: Michal Privoznik <mprivozn> Reviewed-by: Erik Skultety <eskultet> commit 7e62c4cd26dfde89d561a754f22cd07f23e2429e Author: Michal Privoznik <mprivozn> AuthorDate: Mon Oct 2 10:47:27 2017 +0200 Commit: Michal Privoznik <mprivozn> CommitDate: Wed Oct 4 17:10:12 2017 +0200 virmacaddr: Track if MAC address is autogenerated It will come handy to know if the MAC address was generated (e.g. during XML parse) or if it was parsed since provided by user in the XML. Signed-off-by: Michal Privoznik <mprivozn> Reviewed-by: Erik Skultety <eskultet> commit b2482c084a2f2005582e39de96abf209855287ab Author: Michal Privoznik <mprivozn> AuthorDate: Fri Sep 29 16:12:19 2017 +0200 Commit: Michal Privoznik <mprivozn> CommitDate: Wed Oct 4 17:10:12 2017 +0200 qemuParseCommandLineNet: Make it more readable Signed-off-by: Michal Privoznik <mprivozn> Reviewed-by: Erik Skultety <eskultet> v3.8.0-9-g7e9f171d8 Test with upstream patch for several scenarios, and there is one problem I'm not sure, could you please help to confirm? When there is only 1 interface in the vm, detach the interface by a xml without pci address or mac will succeed. If this is acceptable? # virsh dumpxml rhel7.4 | grep /interface -B7 <interface type='direct'> <mac address='52:54:00:44:ff:e4'/> <source dev='eno1' mode='vepa'/> <target dev='macvtap0'/> <model type='rtl8139'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> # cat net6.xml <interface type='network'> <source network='default' bridge='virbr0'/> </interface> # virsh detach-device rhel7.4 net6.xml Device detached successfully # virsh dumpxml rhel7.4 | grep /interface -B7 # When there are more than 1 interface in vm, detach by such xml, will failed with # virsh detach-device rhel7.4 net6.xml error: Failed to detach device from net6.xml error: operation failed: multiple matching devices found (In reply to yalzhang from comment #8) > Test with upstream patch for several scenarios, and there is one problem I'm > not sure, could you please help to confirm? > > When there is only 1 interface in the vm, detach the interface by a xml > without pci address or mac will succeed. If this is acceptable? > I think it is. You tell libvirt to detach interface from domain. Since there's just one do we really need users to specify which one? We don't. Therefore I think this is expected. Test on libvirt-3.9.0-1.el7.x86_64, all the results are as expected. Set bug to be verified. # virsh dumpxml rhel7.4 | grep /interface -B7 <interface type='network'> <mac address='52:54:00:8c:2a:67'/> <source network='default' bridge='virbr0'/> <target dev='vnet0'/> <model type='rtl8139'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> </interface> <interface type='direct'> <mac address='52:54:00:44:ff:e4'/> <source dev='eno1' mode='vepa'/> <target dev='macvtap0'/> <model type='rtl8139'/> <alias name='net1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> Positive test: detach interface device will match by pci or mac or together if both specified. 1. detach an interface device only by right mac will succeed 2. detach an interface device only by right pci address will succeed 3. detach an interface device by right pci with right mac will succeed Negative test: 1. by right mac + wrong pci address # virsh detach-device rhel7.4 net4.xml error: Failed to detach device from net4.xml error: operation failed: no device matching MAC address 52:54:00:8c:2a:67 found on 0000:00:03.0 2. by wrong mac + right pci address # virsh detach-device rhel7.4 net5.xml error: Failed to detach device from net5.xml error: operation failed: no device matching MAC address 52:54:00:44:ff:e4 found on 0000:00:09.0 3. no mac, no pci address # cat net6.xml <interface type='network'> <source network='default' bridge='virbr0'/> </interface> # virsh detach-device rhel7.4 net6.xml error: Failed to detach device from net6.xml error: operation failed: multiple matching devices found 4. no mac + wrong pci address # cat net8.xml <interface type='network'> <source network='default'/> <model type='rtl8139'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x11' function='0x0'/> </interface> # virsh detach-device rhel7.4 net8.xml error: Failed to detach device from net8.xml error: operation failed: no device found on 0000:00:11.0 5. no pci address + wrong mac # cat net9.xml <interface type='network'> <source network='default'/> <mac address='52:54:00:76:80:66'/> <model type='rtl8139'/> </interface> # virsh detach-device rhel7.4 net9.xml error: Failed to detach device from net9.xml error: operation failed: no device matching MAC address 52:54:00:76:80:66 found ------- Comment From santwana.samantray.com 2017-12-08 00:22 EDT------- Hi All, I validated this issue on Pegas1.1 Alpha build(k.v-4.14.0-6.el7a.ppc64le) , "libvirt-3.9.0-4.el7.ppc64le" with the positive and negative scenarios , below are the findings: 1. detach an interface device only by right mac # virsh detach-device santwana-pegas1_1 vfpool.xml --config 2. detach an interface device only by right pci address # virsh detach-device santwana-pegas1_1 vfpool.xml --config Device detached successfully 3. detach an interface device by right pci with right mac # virsh detach-device santwana-pegas1_1 vfpool.xml --config Device detached successfully Negative Tests: 1. with right mac, wrong pci address: # virsh detach-device santwana-pegas1_1 vfpool.xml --config error: Failed to detach device from vfpool.xml error: operation failed: no device matching MAC address 52:54:00:1e:78:27 found on 0000:01:02.0 2. wrong mac, right pci address: # virsh detach-device santwana-pegas1_1 vfpool.xml --config error: Failed to detach device from vfpool.xml error: operation failed: no device matching MAC address 52:54:00:1e:78:28 found on 0000:01:01.0 3. no mac, no pci address: # virsh detach-device santwana-pegas1_1 vfpool.xml --config error: Failed to detach device from vfpool.xml The above works fine only for single interface, for multiple interfaces the error is noticed. 4. no mac, wrong pci address: # virsh detach-device santwana-pegas1_1 vfpool.xml --config error: Failed to detach device from vfpool.xml error: operation failed: no device found on 0000:01:02.0 5. no pci address, wrong mac: # virsh detach-device santwana-pegas1_1 vfpool.xml --config error: Failed to detach device from vfpool.xml error: operation failed: no device matching MAC address 52:54:00:1e:78:29 found Thanks, Santwana ------- Comment From santwana.samantray.com 2018-02-06 02:19 EDT------- Hi All, I validated this issue on Pegas1.1 Snap1 build(k.v-4.14.0-37.el7a.ppc64le) , "libvirt-3.9.0-9.el7.ppc64le" with the positive and negative scenarios , below are the findings: Positive Scenario's: detach interface device will match by pci or mac or together if both specified. 1. detach an interface device only by right mac # virsh detach-device santwana-pegas1_1 vfpool.xml --config Device detached successfully 2. detach an interface device only by right pci address # virsh detach-device santwana-pegas1_1 vfpool.xml --config Device detached successfully 3. detach an interface device by right pci with right mac # virsh detach-device santwana-pegas1_1 vfpool.xml --config Device detached successfully Negative Scenario's: 1. with right mac, wrong pci address: # virsh detach-device santwana-pegas1_1 vfpool.xml --config error: Failed to detach device from vfpool.xml error: operation failed: no device matching MAC address 52:54:00:56:f1:df found on 0000:01:01.2 2. wrong mac, right pci address: # virsh detach-device santwana-pegas1_1 vfpool.xml --config error: Failed to detach device from vfpool.xml error: operation failed: no device matching MAC address 52:54:00:56:f1:af found on 0000:01:01.0 3. no mac, no pci address: # virsh detach-device santwana-pegas1_1 vfpool.xml --config error: Failed to detach device from vfpool.xml 4. no mac, wrong pci address: # virsh detach-device santwana-pegas1_1 vfpool.xml --config error: Failed to detach device from vfpool.xml error: operation failed: no device found on 0000:01:02.0 # virsh detach-device santwana-pegas1_1 vfpool.xml --config error: Failed to detach device from vfpool.xml error: operation failed: no device matching MAC address 52:54:00:56:f1:de found We can close this issue now. Thanks for your support, Santwana Retest for RBZ1343919 with kernel-3.10.0-860.el7.x86_64, libvirt-3.9.0-14.virtcov.el7.x86_64, qemu-kvm-rhev-2.10.0-21.el7.x86_64 All the results are as expected as comment 11 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/RHEA-2018:0704 |