Bug 994283

Summary:	[RFE] Per cluster MAC address pool
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Bryan Yount <byount>
Component:	ovirt-engine	Assignee:	Martin Mucha <mmucha>
Status:	CLOSED ERRATA	QA Contact:	Meni Yakove <myakove>
Severity:	high	Docs Contact:
Priority:	high
Version:	3.2.0	CC:	amarchuk, bdoran, byount, danken, dsirrine, gchakkar, jduncan, lpeer, lsurette, mavital, mburman, nyechiel, pbatkowski, rbalakri, Rhev-m-bugs, sander.van.dinten, srevivo, tmichett, ykaul, ylavi
Target Milestone:	ovirt-4.1.0-beta	Keywords:	FutureFeature
Target Release:	---	Flags:	nyechiel: Triaged+ mavital: testing_plan_complete+
Hardware:	Unspecified
OS:	Unspecified
URL:	http://www.ovirt.org/Features/Scoped_MacPoolManager
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:	Feature: MAC Pool association was altered, so that it's possible to attach different MAC Pool to each individual cluster. Reason: Future demise of DataCenter concept. Result: Done.	Story Points:	---
Clone Of:
Clones:	1317436 (view as bug list)		Environment:
Last Closed:	2017-04-25 00:53:44 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:	1317436
Bug Blocks:	1298235, 1420586

Description Bryan Yount 2013-08-07 00:51:36 UTC

RFE request

3. What is the nature and description of the request?

There is a need to have a separate MAC address pool for a RHEL VM pool in RHEV to keep it separate from the Windows VDI network and VM pool.


4. Why does the customer need this? (List the business requirements here)

For certain environments, there are business reasons to have a specific pool of MAC addresses for some systems and a different pool of MACs for other systems


5. How would the customer like to achieve this? (List the functional requirements here)

Ability to assign a MAC pool range to a VM, template, or pool.


8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)?

RHEV 3.3 / RHEV 3.4


9. Is the sales team involved in this request and do they have any additional input?
Yes


10. List any affected packages or components.
ovirt-engine-backend
ovirt-engine-webadmin-portal


11. Would the customer be able to assist in testing this functionality if implemented?
Yes

Comment 3 Itamar Heim 2014-01-05 10:12:13 UTC

*** Bug 616350 has been marked as a duplicate of this bug. ***

Comment 4 Nir Yechiel 2014-04-29 13:11:13 UTC

Can we get more information on the way the customer is differentiating between the different environments - are they just using different logical networks, or maybe different cluster or DC? 

What is the expected level of granularity here? Does having a configurable MAC pool per DC will help?

Thanks,
Nir

Comment 5 wiley crider 2014-04-29 18:44:48 UTC

Nir, 

They essentially have secure and unsecure environments on different clusters and networks which is why they are requesting this feature. The level of granularity is per cluster as DC is too large. They require a mac address pool per cluster for security and deployment purposes.

Comment 6 Martin Mucha 2014-04-30 07:00:19 UTC

ad "pool per DC" too large:

this is first approach, can be extended in future if needed. There were lot of ideas about granularity size coming from lot of directions, so best probably offer more variants and let user select which one does he want to use.

details:
after yesterday discussion there will be proposed a change in implementation.
Pools are named, and can be shared among multiple resources. By default, each data center will have attached one default shared pool. (It's similar to "if not configured used default one" but with distinction, that this pool is configured via rest and shared pool to use for new datacenters can be changed.) Pool manipulation will have it's own rest api detached from data center.

After these changes we will have extensible rest api, which can support adding finer granularity of pools in future without breaking current one. And in code there already possibility to swap granularity via strategy.

Comment 7 Gajanan 2014-08-12 10:47:17 UTC

====== RFE Request =====

Customer from another account is looking for this feature. 

4. Why does the customer need this? (List the business requirements here)

> We would like to provide different MAC address pools to different 
clusters for security reasons and for more flexibility in IP address 
assignement with dhcp server.

5. How would the customer like to achieve this? (List the functional requirements here)

> I can imagine it through the definition of the address pool when 
creating or editing the cluster.

8. Does the customer have any specific timeline dependencies and which release would they like to target ?

> Would be nice to have it in the next RHEV release.

11. Would the customer be able to assist in testing this functionality if implemented?

> Yes of course.

Comment 9 Nir Yechiel 2014-10-21 08:18:47 UTC

Per DC MAC pool is planned for RHEVM 3.6 (BZ 912260). This bug is to track the request to add Cluster/VM pool granularity.

Comment 10 Mike McCune 2016-03-28 23:09:17 UTC

This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions

Comment 11 Michael Burman 2017-01-03 08:00:10 UTC

Verified on - 4.1.0-0.3.beta2.el7