Bug 1209795

Summary: [RFE] alert after a VM is imported while using MAC outside its MAC Pool
Product: Red Hat Enterprise Virtualization Manager Reporter: Paul Dwyer <pdwyer>
Component: RFEsAssignee: Yevgeny Zaspitsky <yzaspits>
Status: CLOSED ERRATA QA Contact: Michael Burman <mburman>
Severity: medium Docs Contact:
Priority: high    
Version: unspecifiedCC: aperotti, bgraveno, danken, eedri, gklein, jentrena, lpeer, lsurette, michal.skrivanek, myakove, nsimsolo, pdwyer, rbalakri, sbonazzo, srevivo, ykaul, ylavi, yzaspits
Target Milestone: ovirt-4.0.2Keywords: EasyFix, FutureFeature, ZStream
Target Release: 4.0.2   
Hardware: All   
OS: Linux   
URL: -
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
This is to help avoid the problem of MAC collision in the user's LAN. Such a problem could appear immediately or later, when two active NICs with the same problematic MAC could appear in the user's LAN, one on the imported virtual machine, and another one on any other network appliance that isn't managed by the this Red Hat Virtualization instance.
Story Points: ---
Clone Of:
: 1360672 1362589 (view as bug list) Environment:
Last Closed: 2016-08-23 20:23:48 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:
Embargoed:
Bug Depends On:    
Bug Blocks: 1295867, 1360672, 1362589    
Attachments:
Description Flags
Script that finds VMs with external MACs on their vNICs for ovirt-engine v3.6
none
Script that finds VMs with external MACs on their vNICs for ovirt-engine v4 none

Comment 4 Dan Kenigsberg 2016-01-20 14:09:49 UTC
Eldan suggested to override the currently-existing per-VM exclamation mark: if a VM has a vnic with a mac address outside of the relevant pool, an "!" would show to the left of the VM line.

A new exclamation mark would be added to the left of the offending vnic.

On mac pool editing dialog, it would be nice to add a warning with a counter: "X vnics are defined outside of mac pool ranges"

Comment 5 Yaniv Lavi 2016-01-20 14:22:16 UTC
(In reply to Dan Kenigsberg from comment #4)
> Eldan suggested to override the currently-existing per-VM exclamation mark:
> if a VM has a vnic with a mac address outside of the relevant pool, an "!"
> would show to the left of the VM line.
> 
> A new exclamation mark would be added to the left of the offending vnic.
> 
> On mac pool editing dialog, it would be nice to add a warning with a
> counter: "X vnics are defined outside of mac pool ranges"

This should be visible from the main VM grid.

Comment 6 Michal Skrivanek 2016-04-04 06:42:09 UTC
*** Bug 1295867 has been marked as a duplicate of this bug. ***

Comment 7 Michal Skrivanek 2016-04-04 06:43:11 UTC
For verification: please make sure you check the v2v flow described in bug 1295867 as well

Comment 8 Yaniv Kaul 2016-05-04 18:14:47 UTC
Completely missed 3.6.6. Any chance for 3.6.7?

Comment 11 Yevgeny Zaspitsky 2016-05-31 13:39:11 UTC
Created attachment 1163237 [details]
Script that finds VMs with external MACs on their vNICs for ovirt-engine v3.6

The script finds out all VMs that has an external MAC address defined on one of the vNICs.
The outputs of the script are:
* List of problematic VM/vNIC/MAC address
* Search query string to be used in the web-admin search 

Note: It requires ovirt-engine-python-sdk to be installed on the computer that the script is run from.

Comment 12 Yevgeny Zaspitsky 2016-05-31 13:42:50 UTC
Created attachment 1163240 [details]
Script that finds VMs with external MACs on their vNICs for ovirt-engine v4

Comment 13 Yevgeny Zaspitsky 2016-05-31 13:46:06 UTC
Comment on attachment 1163240 [details]
Script that finds VMs with external MACs on their vNICs for ovirt-engine v4

Please note that the v4 script requires python-ovirt-engine-sdk4 package to be installed on the computer that runs the script.

Comment 14 Yevgeny Zaspitsky 2016-05-31 13:49:23 UTC
Paul,
Could you please check with your customer if the provided scripts answer his need?

Comment 16 Julio Entrena Perez 2016-05-31 14:09:01 UTC
(In reply to Yaniv Dary from comment #5)
> This should be visible from the main VM grid.

Comment 17 Yaniv Kaul 2016-05-31 21:01:48 UTC
(In reply to Yevgeny Zaspitsky from comment #14)
> Paul,
> Could you please check with your customer if the provided scripts answer his
> need?

How can the customer test it, if it's uses v4 SDK?

Comment 18 Yevgeny Zaspitsky 2016-05-31 21:12:46 UTC
There are two versions of the script - one for v4 and another one for v3.6. Both versions are attached to this bug.

Comment 20 Dan Kenigsberg 2016-06-01 11:17:52 UTC
The script is intended as an immediate remedy to systems that already have VMs with out-of-range MACs.

Having the main VM grid indicate which VM is out-of-range (and searching for all VMs that have this indication), is too complicated to solve in a timely manner.

Alerting about out-of-range VMs during import process is more feasible; Showing an alert whenever such a VM is started may spam people that intentionally have manual MAC.

Comment 24 Dan Kenigsberg 2016-06-08 13:47:13 UTC
The down side of alerting on each startup is that it spams the audit log in case someone actually needs to use an out-of-range mac. At this stage, I'd rather limit our warning to the mass import use-case.

Comment 25 Eyal Edri 2016-06-19 12:56:56 UTC
Please make sure to clone the bug to 3.6.8, its possible even when bug is on POST.

Comment 28 Yaniv Lavi 2016-07-28 12:37:44 UTC
Should this be on qa?

Comment 29 Dan Kenigsberg 2016-08-02 15:03:07 UTC
I've cloned bug 1362589 to track what we believe is the fully-fledged feature (UI included). For 4.0-ga we are shipping only event-log alerts when an out-of-range VM is imported.

Comment 30 Michael Burman 2016-08-10 12:43:11 UTC
Verified on 4.0.2.4-0.1.el7ev (import from export domain)

Comment 31 Nisim Simsolo 2016-08-10 12:47:38 UTC
Also verified when importing from VMware, Xen and KVM

Comment 33 errata-xmlrpc 2016-08-23 20:23:48 UTC
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://rhn.redhat.com/errata/RHEA-2016-1743.html