[Ovirt-devel] Explicit global network modelling

Mohammed Morsi mmorsi at redhat.com
Fri Oct 24 16:53:57 UTC 2008

Daniel P. Berrange wrote:
> On Thu, Oct 23, 2008 at 04:34:47PM -0400, Mohammed Morsi wrote:
>> Daniel P. Berrange wrote:
>>> The network configuration UI discussions have all focused around
>>> the idea of configuring NICs on machines. I've been thinking that
>>> this is really not the right model. You have some kind of physical
>>> topology which is known, and has certain properties like network
>>> address and prefix, and vlan.  A host has one or more NICs, each
>>> of which is connected to a network.
>>> So if we can model a network as a global entity in its own right,
>>> we can simplify configuration of host interfaces, so simply a 
>>> matter of association, and optionally defining an address.
>>> * Network
>>>     - addr config      eg, none, static vs dhcp
>>>     - network address  eg,
>>>     - prefix           eg,  /24
>>>     - usage            eg, storage, management, guest
>>>     - vlan number      eg, 43
>>>     - vlan network     eg, name of host network
>>> * Interface
>>>     - name              eg eth1
>>>     - mac               eg 00:11:22:33:44:55
>>>     - addr config       eg, static vs dhcp vs none
>>> With the association being:
>>>            1     n           n    1
>>>   Network  <-----> Interface <----> Node
>> Based on our discussion today the following things are needed for this
>> 1. Add new networks table, subclassed into virtual and physical
>> networks, and associated with ip_addresses table
> Where does this virtual vs physical network distinction come from ?
Both will simply be subclasses of the network table, which will need to
have a 'type' column in it. Thus each can validate the fields it needs
separately, for example virtual networks would validate the vlan number
and network fields are present before allowing creation, update
operations, etc.

>> One additional thing that comes to mind as I read over the proposed
>> changes is that this network model fits nicely with DHCP assigned nics /
>> interfaces as the nic is associated with the network which it is to
>> receive that information from, but for static assignments it doesn't fit
>> so nicely. This is because the nic / interface will still need to be
>> associated with an ip address directly and not just a network. If so
>> we'd still need the associations between those tables, and might require
>> some validation to make sure the assigned ip is valid for the selected
>> network (or would no network be selected in that case?).
> Static ip info is no trouble at all. You can still associate an IP address
> with with the interface directly. In fact you could even suggest a suitable
> static addres by looking at the netmask of the Network, and what static
> addresses are already known, and pick an unused one. In addition, even if
> the network is configured for DHCP, you may still wish to give certain
> hosts static ip addrs, so you need to maintain the IP address against the
> interface anyway.
> With both the network, and interface you need to cope with multiple
> addresses - both IPv4 and v6
>             1     n           n    1
>    Network  <-----> Interface <----> Node
>      ^ 1                 ^ 1
>      |                   |
>      V n                 V n
>   NetAddress          Address
> In the NetAddress you store the network address ( and
> the network prefix (/24). In the 'Address'  you merely store the
> address ''. You can't directly enforce validity constraint
> of network address + prefix matching the NIC address, because SQL just
> isn't that expressive.
> Daniel
Just to assist in starting all this, I came up with a quick uml class
diagram for the new network changes incorporating the new classes and
relationships,  and accommodating for things like static ip addresses
and the network usage relationship. It can be accessed here
http://www.ovirt.org/page/Redesigned_Network_Configuration If anything
looks off, feel free to point it out.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/ovirt-devel/attachments/20081024/198d2090/attachment.htm>

More information about the ovirt-devel mailing list