Bug 994283 - [RFE] Per cluster MAC address pool
[RFE] Per cluster MAC address pool
Status: CLOSED ERRATA
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
3.2.0
Unspecified Unspecified
high Severity high
: ovirt-4.1.0-beta
: ---
Assigned To: Martin Mucha
Meni Yakove
http://www.ovirt.org/Features/Scoped_...
: FutureFeature
: 616350 (view as bug list)
Depends On: 1317436
Blocks: 1298235 1420586
  Show dependency treegraph
 
Reported: 2013-08-06 20:51 EDT by Bryan Yount
Modified: 2017-04-24 20:53 EDT (History)
21 users (show)

See Also:
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:
: 1317436 (view as bug list)
Environment:
Last Closed: 2017-04-24 20:53:44 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Network
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
nyechiel: Triaged+
mavital: testing_plan_complete+


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 445673 None None None Never
oVirt gerrit 50755 master MERGED core: MacPool per Cluster; update db so that cluster references pool 2016-05-30 05:41 EDT
oVirt gerrit 50756 master MERGED core: MacPoolPerDc—>MacPoolPerCluster 2016-05-31 01:24 EDT
oVirt gerrit 51425 master MERGED restapi: moved reference to mac pool from DataCenter to Cluster 2016-06-01 08:24 EDT
oVirt gerrit 51426 master MERGED webadmin: moved reference to mac pool from DataCenter to Cluster 2016-06-01 06:33 EDT
oVirt gerrit 51427 master MERGED core: remove link to mac pool from storage pool. 2016-06-01 07:10 EDT
oVirt gerrit 51844 master MERGED added reference to mac pool from to Cluster, added comments. 2016-01-14 10:16 EST
oVirt gerrit 63704 master MERGED Fix the @since tag of Cluster.macPool 2016-09-13 04:15 EDT
oVirt gerrit 63705 model_4.0 MERGED Remote the Cluster.macPool attribute 2016-09-13 04:15 EDT

  None (edit)
Description Bryan Yount 2013-08-06 20:51:36 EDT
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 05:12:13 EST
*** Bug 616350 has been marked as a duplicate of this bug. ***
Comment 4 Nir Yechiel 2014-04-29 09:11:13 EDT
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 14:44:48 EDT
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 03:00:19 EDT
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 06:47:17 EDT
====== 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 04:18:47 EDT
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 19:09:17 EDT
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune@redhat.com with any questions
Comment 11 Michael Burman 2017-01-03 03:00:10 EST
Verified on - 4.1.0-0.3.beta2.el7

Note You need to log in before you can comment on or make changes to this bug.