ad 1) mine thinking was the same. If it's optional, then upgrade process is:
'you do not have to do anything', which seemed best to me.
ad 2) yes, this has to be reflected in gui. Currently in business layer there
are checks which do not let you use multicast address (exception is thrown when
th
1) In our opinion the pool definition should be optional.
We should preserve the existing behavior. It will be useful especially for the
upgrade scenarios.
2) As well for the "Number of MACs" we proposed earlier you should take into
account the multicast addresses (if they are in the range) and
Hi,
We would like to propose a little bit better solution from user experience side.
We should have 3 fields for each range:
1) Start range
2) End range
3) Number of MACs
When you have to fill in "End range" or "Number of MACs" (when start range is
mandatory).
And the 3rd field will be filled in
Hi,
thanks for your input, I'll try to satisfy your request to be able to set range
'width' either by 'end boundary' or 'mac count' in gui design.
Prior to that there are more fundamental decisions to be made -- like whether
the pool definition is mandatory or optional, and how this influence t
ske"
> Cc: devel@ovirt.org, us...@ovirt.org
> Sent: Tuesday, April 22, 2014 11:04:31 AM
> Subject: Re: [ovirt-devel] [ovirt-users] Feature Page: Mac Pool per DC
>
> Hi,
>
> I like to answer questions. Presence of questions in "motivated environment"
> means
- Original Message -
> From: "Martin Mucha"
> To: "Itamar Heim"
> Cc: us...@ovirt.org, devel@ovirt.org
> Sent: Thursday, April 24, 2014 12:58:37 PM
> Subject: Re: [ovirt-devel] [ovirt-users] Feature Page: Mac Pool per DC
>
> >no. you don&#x
>no. you don't change mac addresses on the fly.
ok, I was just asking if that's an option. No reallocating.
>i don't see why you need to keep it in memory at all?
What I did is not a rewrite, but alteration of existing code -- I just add one
layer above existing pool implementation. I'm not sure
On 04/23/2014 11:12 AM, Martin Mucha wrote:
Hi,
I was describing current state, first iteration. Need of restart is something
which should not exist, I've removed that necessity meantime.
Altered flow: You allocate mac address for nic in data center without own pool,
it gets registered in glob
Hi,
I was describing current state, first iteration. Need of restart is something
which should not exist, I've removed that necessity meantime.
Altered flow: You allocate mac address for nic in data center without own pool,
it gets registered in global pool. Then you modify settings of that dat
On 04/18/2014 01:17 PM, Martin Mucha wrote:
Hi,
I'll try to describe it little bit more. Lets say, that we've got one data
center. It's not configured yet to have its own mac pool. So in system is only
one, global pool. We create few VMs and it's NICs will obtain its MAC from this
global pool
fied
MACs, you can, but tell system from which range those MACs will be(via mac pool
configuration).
M.
- Original Message -
From: "Sven Kieske"
To: "Martin Mucha" , "Itamar Heim"
Cc: us...@ovirt.org, devel@ovirt.org
Sent: Tuesday, April 22, 2014 8:31:31 A
Hi,
thanks for the very detailed answers.
So here is another question:
How are MACs handled which got assigned "by hand"?
Do they also get registered with a global or with
the datacenter pool?
Are they tracked anyway?
I'm currently assigning macs via API directly
to the vms and do not let ovirt
Hi,
I'll try to describe it little bit more. Lets say, that we've got one data
center. It's not configured yet to have its own mac pool. So in system is only
one, global pool. We create few VMs and it's NICs will obtain its MAC from this
global pool, marking them as used. Next we alter data ce
On 04/10/2014 09:59 AM, Martin Mucha wrote:
Hi,
I'd like to notify you about new feature, which allows to specify distinct MAC
pools, currently one per data center.
http://www.ovirt.org/Scoped_MacPoolManager
any comments/proposals for improvement are very welcomed.
Martin.
14 matches
Mail list logo
