Bug 890506

Summary: [RFE] Independence/uniqueness of DC - mac pool, vm/template names, directory services
Product: Red Hat Enterprise Virtualization Manager Reporter: Jiri Belka <jbelka>
Component: ovirt-engineAssignee: Nobody's working on this, feel free to take it <nobody>
Status: CLOSED NOTABUG QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 3.2.0CC: dyasny, iheim, lpeer, oramraz, pmukhedk, Rhev-m-bugs, sgrinber, yeylon, ykaul, ylavi
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: infra
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-02-18 09:06:23 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Infra RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jiri Belka 2012-12-27 11:17:00 UTC
Description of problem:

This is RFE!

DC should be highest logical entity but somehow it is not true, for example you define mac pool for those engine installation...

I would like to propose following new features:

1. per DC mac pool
2. VM names uniqueness only per DC, same VM names in different DCs should be possible
3. logical networks uniqueness only per DC, same logical networks in different DCs should be possible
4. per DC directory services

Little arguments:

1a. mac pools - one RHEV-M can support environments where one DC is related to one environment. Each client's DC should have possibility to define his own mac pool - there can be a DHCP server using mac pool, switches using this mac pool. So clients/admins using sing RHEV-M do not share one big mac pool, there should be strictly separated.

1b. mac pools - on the other hand, logical networks are related to a DC - so in some strange settings (consolication/migration), I could imagine same hwaddr existing in different DCs. As host cannot be shared between DCs, this should not be a problem at all. Another argument could be VRF.

2. DC vm names - a client could want to have complete "copy" of his "production" DC in different DC - same VM names... The reason why could be: migration/test, datacenter (location) switch, disaster recovery testing. A client could work on a migration, while "old" VM still running support team works on exact copy (same mac, ip address) in different DC, when migration is done, old VM is stopped, and routing/fw rules (VRF) are switch to point to "new" VM. Another scenario can be disaster recovery, production VM is running, exact copy is being installed/restored in different DC, then same switch on router/fw to give client ability to test DR server to testing/confirmation.

3. logical networks - again different DCs can mean different clients altough using same naming convention but using different physical networking.

4. per DC directory services - company managing RHEV-M could be personally different from those managing individual VMs. So RHEV-M services provider should be able to give access to specific sysadmins to a DC, but other permissions inside this DC should be managed by the owner (sysadmins) who can delegate additional permissions to their own users/groups in their own directory service.

This features would be great for clients who provide "just" infrastructure as service.

Comment 2 Oded Ramraz 2012-12-27 11:29:29 UTC
This issue reminds me this busy : https://bugzilla.redhat.com/show_bug.cgi?id=571340 . 
According to https://bugzilla.redhat.com/show_bug.cgi?id=571340#c3 name enforcement exists on DC level only.

Comment 6 Jiri Belka 2013-02-18 09:06:23 UTC
BZ912260, BZ912263, BZ912266, BZ912267 - separated BZs created as requested.