[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