[Ovirt-devel] Re: Configuration NICs
Perry N. Myers
pmyers at redhat.com
Fri Sep 12 19:28:32 UTC 2008
Darryl L. Pierce wrote:
> +++ Perry N. Myers [12/09/08 14:56 -0400]:
>> Darryl L. Pierce wrote:
>>> In order to configure a NIC and also use bonding/fail-over, we need
>>> a way to:
>>> 1. associate one or more BondingType objects to the Host via the Bonding
>> Should we model this by associating a BondingType to a set of NICs
>> rather than a Host? I know initially we're only going to support on
>> BondingType per Host as to simplify things, but it might make sense to
>> structure the data model to make it easier to transition to the more
>> flexible approach.
> The relationship between Host and Bonding is a one-to-many, so we're
> able to do the multiple Bondings. I don't want to do the relationship from
> the Host to the Bonding through the Nic though 'cause that's not a natural
> way of thinking about it to me; i.e., the Bonding is an aspect of the
> Host so
> it should be hung there.
Ok. So initially a Host can have multiple Bondings and each Bonding on a
Host must have the same BondingType. Eventually we'll support multiple
Bondings on each host with independent BondingTypes. This right?
>> For the time being we can make the restriction that once you're
>> created one set of bonded interfaces and have selected Type X for
>> those interfaces that all other interfaces on the Host can only use
>> type X. That's a simple restriction in the UI that doesn't affect the
>> data model.
>>> 2. associate which of the Host's Nic objects will be a part of each
>>> 3. set the ip address, netmask, etc. for a Nic that's not enslaved.
>> Or allow DHCP, right?
> Oops, forgot to mention that. If the IP address is nil then the
> generator chooses DHCP for the boot protocol.
>>> Here's a crude ASCII of what I"m thinking.
>>> [ Select a bonding type v ] [ Add ]
>>> Bonded interface alias: _bond0_____________________ [ Remove ]_
>>> Bonded interface name: _ovbond0____________________
>>> Network Interfaces:
>>> [ ] Enslave to ovbond0 IP Address: _______ Netmask: ____ |
>>> 11:22:33 [X] Enslaved to ovbond0
>>> 22:33:44 [X] Enslaved to ovbond0
>>> [ Save Changes ]
>>> 1. The user selects a bonding type and clicks "Add". The bonded
>>> fields are displayed.
>>> 2. The user clicks "Remove" to destroy the interface. When that
>>> happens, any
>>> enslaved Nic is released but not destroyed.
>>> 3. If the user clicks the checkbox to enslave an interface then the IP
>>> address and netmask fields go away.
>> So is this a UI that appears on an 'Edit Node' page? How does the
>> user get to this page? And how would it look if there were multiple
>> Bond objects? (i.e. is Bonded Interface Alias a drop down list?)
> These are the details that I was afraid to face initially without getting
> someone like Tim involved. I think that a dropdown listing the bondings
> be the way to go when we support more than one bonding.
Tim, can you work with Darryl and Scott to do a mockup of what this should
look like so we can implement it the right way :)
>> What about configuring the IP addresses statically for interfaces that
>> are not bonded?
> That's the example with mac 00:11:22 above: if the box isn't checked, then
> you can enter the ip address and netmask in the field next to the
Ok, the UI diagram above only assumes a single Bond per host... Yeah, we
need to work out a UI where multiple Bonds are allowed... It gets more
>> As an aside, we should probably allow interfaces to be 'labeled'.
>> i.e. For each Interface object associate a label that can be used by
>> a hardware Admin to know what physical network that interface is
>> attached to.
>> Interface with MAC 11:22:33:44:55:66 is on "LAN A"
>> Or something like that. Bonded interfaces all need to be on the same
>> physical network (so have the same label) and the Label associated
>> with a set of bonded interfaces is the same as the underlying interfaces.
> For the bondings that would be the alias. For the nics we could have a
> next to each mac address where the admin could enter an alias for that and
> have it persisted.
Well, the alias should be a rollup of the labels for the bonded
interfaces. i.e. if you have 2 NICs bonded and each of them are labelled
"LAN A" the alias for the bond should also be LAN A
|=- Red Hat, Engineering, Emerging Technologies, Boston -=|
|=- Email: pmyers at redhat.com -=|
|=- Office: +1 412 474 3552 Mobile: +1 703 362 9622 -=|
|=- GnuPG: E65E4F3D 88F9 F1C9 C2F3 1303 01FE 817C C5D2 8B91 E65E 4F3D -=|
More information about the ovirt-devel