Bug 1255408 - [RFE] New network interface dialog - show a mac from pool by default
[RFE] New network interface dialog - show a mac from pool by default
Product: ovirt-engine
Classification: oVirt
Component: Frontend.WebAdmin (Show other bugs)
Unspecified Unspecified
unspecified Severity low (vote)
: ---
: ---
Assigned To: nobody nobody
Pavel Stehlik
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2015-08-20 09:46 EDT by Jiri Belka
Modified: 2016-02-10 14:58 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-12-07 11:06:58 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: Network
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
ylavi: ovirt‑future?
rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?

Attachments (Terms of Use)

  None (edit)
Description Jiri Belka 2015-08-20 09:46:21 EDT
Description of problem:
We work in an environment where there's often issue with duplicated hwaddr in physical network. This is caused by people having engines with default mac pool ranges.

One cool thing - not fully related to the statement above! - could be to see mac range pool hwaddr in 'New network interface dialog'.

- new network interface dialog
- in grey box, there should be written a random hwaddr from current mac pool range written in grey color
- switching custom mac address would cause the random hwaddr from current pool range disappear and the box should be just white for inserting user defined hwaddr

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:

Actual results:

Expected results:

Additional info:
why? seeing this hwaddr in grey box could remind our great QE that they are using (same) default mac pool range :)
Comment 1 Dan Kenigsberg 2015-12-07 11:06:58 EST
Providing a hint on how a vNIC mac address would look like sounds indeed quite handy.

However, implementing this would require the frontend to allocate the sample mac address temporarily, and deallocate it immediately (backend would need to make sure that the frontend did not die in between, or otherwise the address would leak).

This seems a bit to complex for a nice-to-have-feature.

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