Bug 1892130
| Summary: | Error message should be updated when set wrong type value in interface mac element | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux Advanced Virtualization | Reporter: | yalzhang <yalzhang> |
| Component: | libvirt | Assignee: | Michal Privoznik <mprivozn> |
| Status: | CLOSED ERRATA | QA Contact: | yalzhang <yalzhang> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 8.3 | CC: | jdenemar, mprivozn, virt-maint |
| Target Milestone: | rc | Keywords: | Triaged, Upstream |
| Target Release: | 8.3 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | libvirt-6.10.0-1.el8 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-05-25 06:43:38 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: | 6.10.0 |
| Embargoed: | |||
Fxied upstream as: fafeed8bed virDomainNetDefParseXML: Fix error message for unknown value of //mac/@type v6.9.0-15-gfafeed8bed (In reply to yalzhang from comment #0) > > 1. I have checked the vmware OUI definition and found this: > https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.networking. > doc/GUID-1B6A280E-0C77-4775-8F84-4B3F40673178.html > says the VMware OUI is 00:50:56, not 00:0c:29 in the patches. Am I missing > something? That doesn't mean libvirt should forbid setting a different MAC address. If anything, libvirt should generate one with that prefix (if needed at all). > > 2. Could you please tell more about the user story? as I can not understand > the scenario when " it will ignore all the checks libvirt does about the > origin of the MAC address(whether or not it's in a VMWare OUI) and forward > the original one to the ESX server telling it not to check it either". Does > it happen when we try to transform a kvm guest to a vmware guest? That is one possible scenario. The other is that something on network may require a specific MAC address (e.g. because it was registered before). But without Bastien's patches libvirt would basically instruct ESX to generate a new one, which is unfortunate: https://www.redhat.com/archives/libvir-list/2020-July/msg00645.html > > 3. How to test it as a libvirt QE without the ESX env? Depends what you mean by 'it'. If it's the MAC address generation then I guess you can play with our vmx2xmltest and see if it generates expected configs. But if 'it' means the error message then I'd say plain code inspection is okay. Test on libvirt-6.10.0-1.module+el8.4.0+8898+a84e86e1.x86_64
1. edit the interface as below:
<interface type='network'>
<mac address='52:54:00:9d:1e:83' type='new' check='yes'/>
<source network='default'/>
<model type='e1000e'/>
<address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
</interface>
Failed. Try again? [y,n,i,f,?]:
error: XML error: invalid mac address type value: 'new'. Valid values are "generated" and "static".
Failed. Try again? [y,n,f,?]:
the result is as expected, set the bug as verified.
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 (virt:av bug fix and enhancement update), 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-2021:2098 |
Description of problem: When I set wrong "type" value in the mac element, the error message says wrong "check" value Version-Release number of selected component (if applicable): libvirt-6.6.0-7.module+el8.3.0+8424+5ea525c5.x86_64 How reproducible: 100% Steps to Reproduce: 1. Start vm with different configuration with mac in "00:0c:29" range: # virsh dumpxml rhel | grep /interface -B12 ... <interface type='network'> <mac address='00:0c:29:e7:9b:cb' type='generated' check='yes'/> <source network='default'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> </interface> <interface type='network'> <mac address='00:0c:29:3b:e0:50' type='static' check='no'/> <source network='default'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x0d' slot='0x00' function='0x0'/> </interface> <interface type='network'> <mac address='00:0c:29:73:f6:dc' type='generated' check='no'/> <source network='default'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x0e' slot='0x00' function='0x0'/> </interface> <interface type='network'> <mac address='00:0c:29:aa:dc:6c' type='static' check='yes'/> <source network='default'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x0f' slot='0x00' function='0x0'/> </interface> # virsh start rhel Domain rhel started 2. negative test: Set "<mac address='52:54:00:bb:cd:89' type='next'/>" in virsh edit # virsh edit vm1 error: XML document failed to validate against schema: Unable to validate doc against /usr/share/libvirt/schemas/domain.rng Extra element devices in interleave Element domain failed to validate content Failed. Try again? [y,n,i,f,?]: ----> press 'i' error: XML error: invalid mac address check value: 'next'. Valid values are "generated" and "static". Failed. Try again? [y,n,f,?]: Actual results: In step 2, the error message need to be updated Expected results: the error message should be like: error: XML error: invalid mac address ***type*** value: 'next'. Valid values are "generated" and "static". Additional info: This new feature is introduced by patches https://patchew.org/Libvirt/20200713142305.29130-1-bastien.orivel@diateam.net/ https://patchew.org/Libvirt/20200713094413.30201-1-bastien.orivel@diateam.net/ 1. I have checked the vmware OUI definition and found this: https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.networking.doc/GUID-1B6A280E-0C77-4775-8F84-4B3F40673178.html says the VMware OUI is 00:50:56, not 00:0c:29 in the patches. Am I missing something? 2. Could you please tell more about the user story? as I can not understand the scenario when " it will ignore all the checks libvirt does about the origin of the MAC address(whether or not it's in a VMWare OUI) and forward the original one to the ESX server telling it not to check it either". Does it happen when we try to transform a kvm guest to a vmware guest? 3. How to test it as a libvirt QE without the ESX env?