[Ovirt-devel] Re: Configuration NICs
Darryl L. Pierce
dpierce at redhat.com
Fri Sep 12 19:06:43 UTC 2008
+++ 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
>> class.
>
> 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 already
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.
> 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 Bonding
>> object.
>> 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 configuration
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:
>>
>> 00:11:22 [ ] 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 interface
>> 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 would
be the way to go when we support more than one bonding.
> 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 interface.
> 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 field
next to each mac address where the admin could enter an alias for that and
have it persisted.
--
Darryl L. Pierce, Sr. Software Engineer
Red Hat, Inc. - http://www.redhat.com/
oVirt - Virtual Machine Management - http://www.ovirt.org/
"What do you care what other people think, Mr. Feynman?"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/ovirt-devel/attachments/20080912/9323b6a1/attachment.sig>
More information about the ovirt-devel
mailing list