[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[Ovirt-devel] Re: Configuration NICs

+++ 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 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
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?"

Attachment: pgpq6abSscT4O.pgp
Description: PGP signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]