| Summary: | Block adding vNICs with the same MAC address(allow duplicate) to the same VM | ||
|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Michael Burman <mburman> |
| Component: | BLL.Network | Assignee: | bugs <bugs> |
| Status: | CLOSED WONTFIX | QA Contact: | Michael Burman <mburman> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 3.6.2.5 | CC: | bugs, danken, ylavi |
| Target Milestone: | --- | Flags: | sbonazzo:
ovirt-4.3-
|
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-08-01 07:54:19 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | Network | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
It may or may not cause problem, it won't cause problems if it's not on the same LAN/VLAN, right? There might be some esoteric reasons to do it - I would only issue a warning. Looking at code it seems that there is invalid object hierarchy where NewTemplateInterfaceModel inherits NewVmInterfaceModel, meaning that adding this warning to one dialog, will add it to another as well. Would that be OK? If not, this hierarchy needs to be refactored, and I doubt I'm privileged to do that. (In reply to Yaniv Kaul from comment #1) > It may or may not cause problem, it won't cause problems if it's not on the > same LAN/VLAN, right? There might be some esoteric reasons to do it - I > would only issue a warning. Unfortunately, Vdsm code expects MAC address to be unique (it identifies a device based on its address). If we do not block, VM startup fails. Unbreaking Vdsm in this regard is possible, but not so easy, and certainly not important. (In reply to Martin Mucha from comment #2) > Looking at code it seems that there is invalid object hierarchy where > NewTemplateInterfaceModel inherits NewVmInterfaceModel, meaning that adding > this warning to one dialog, will add it to another as well. Would that be > OK? If not, this hierarchy needs to be refactored, and I doubt I'm > privileged to do that. We should block duplicated MAC addresses when adding a vNIC to a VM as well as to a template, if that answers your question. *** Bug 1436980 has been marked as a duplicate of this bug. *** I have no idea why we add such limitation. I can certainly see active-backup scenarios where you use only one interface at a time, across a specific network. Yes, I don't think it's a regular scenario, but I don't see a real need to block this either. This RFE is about exposing an existing limitation in a nicer way. For many years, Vdsm has been using the mac address as a nic identifier, e.g. when correlating libvirt-allocated PCI address and a specific nic. This all blows up when to nics are provided with the same mac address. Francesco Romani has just informed me that as of libvirt-3.9 (should be in el-7.5) the user (i.e. Engine) can provide unique alias for each device https://www.redhat.com/archives/libvir-list/2017-October/msg00993.html This would make the problem I've described moot. Instead of blocking the use case, we can finally actually support it. Engine and Vdsm patches required. Closing old issues, please reopen if still needed. In any case patches are welcome. |
Description of problem: Block adding vNICs with the same MAC address(with allow duplicate) to the same VM. Such operation is allowed and should be blocked, because it can cause to multiple problems. 2016-01-17 16:28:17,767 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.HotPlugNicVDSCommand] (ajp-/127.0.0.1:8702-8) [3da9f582] START, HotPlugNicVDSCommand(HostName = silver-vdsa.qa.lab.tlv.redhat.com, VmNicDeviceVDSParameters:{runAsync='true', hostId='6e8c9954-3287-4192-8522-25fa55271889', vm.vm_name='v1', nic='VmNetworkInterface:{id='08ba3fe0-0268-4757-8cef-0a1bb8678da1', networkName='ovirtmgmt', vnicProfileName='null', vnicProfileId='13bf0730-e7d9-465f-a573-ded3d774c063', speed='1000', type='3', macAddress='00:00:00:00:00:25', active='true', linked='true', portMirroring='false', vmId='e74def3a-c65e-44ff-bc75-f49d5c4d5ab0', vmName='null', vmTemplateId='null', QoSName='null', remoteNetworkName='null'}', vmDevice='VmDevice:{id='VmDeviceId:{deviceId='08ba3fe0-0268-4757-8cef-0a1bb8678da1', vmId='e74def3a-c65e-44ff-bc75-f49d5c4d5ab0'}', device='bridge', type='INTERFACE', bootOrder='3', specParams='[]', address='', managed='true', plugged='true', readOnly='false', deviceAlias='', customProperties='[]', snapshotId='null', logicalName='null', usingScsiReservation='false'}'}), log id: 68feeb45 2016-01-17 16:29:13,588 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.HotPlugNicVDSCommand] (ajp-/127.0.0.1:8702-8) [62f92ce0] START, HotPlugNicVDSCommand(HostName = silver-vdsa.qa.lab.tlv.redhat.com, VmNicDeviceVDSParameters:{runAsync='true', hostId='6e8c9954-3287-4192-8522-25fa55271889', vm.vm_name='v1', nic='VmNetworkInterface:{id='7a94aec7-9ff8-4c2b-97a9-d0559908cf6f', networkName='ovirtmgmt', vnicProfileName='null', vnicProfileId='13bf0730-e7d9-465f-a573-ded3d774c063', speed='1000', type='3', macAddress='00:00:00:00:00:25', active='true', linked='true', portMirroring='false', vmId='e74def3a-c65e-44ff-bc75-f49d5c4d5ab0', vmName='null', vmTemplateId='null', QoSName='null', remoteNetworkName='null'}', vmDevice='VmDevice:{id='VmDeviceId:{deviceId='7a94aec7-9ff8-4c2b-97a9-d0559908cf6f', vmId='e74def3a-c65e-44ff-bc75-f49d5c4d5ab0'}', device='bridge', type='INTERFACE', bootOrder='4', specParams='[]', address='', managed='true', plugged='true', readOnly='false', deviceAlias='', customProperties='[]', snapshotId='null', logicalName='null', usingScsiReservation='false'}'}), log id: 5126c5c4 Version-Release number of selected component (if applicable): 3.6.2.5-0.1.el6 How reproducible: 100 Steps to Reproduce: 1. Add 2 vNICs to 1 VM with the same MAC address (allow duplicate in DC) Actual results: Succeed Expected results: Should be blocked.