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

Re: [netcf-devel] [libvirt] [RFC] Reporting host interface status/statistics via netcf/libvirt, and listing active vs. inactive interfaces



On Fri, Jun 19, 2009 at 05:39:57PM +0100, Daniel P. Berrange wrote:
> On Thu, Jun 18, 2009 at 05:53:59PM +0000, David Lutterkort wrote:
> > On Thu, 2009-06-18 at 18:06 +0100, Daniel P. Berrange wrote:
> > 
> > > VLANs are tricky, because you can define VLANs on a physical 
> > > inteface or a bond interface, and you then may want to also
> > > add a bridge on top of a VLAN, eg take 2 physical NICs, eth0
> > > and eth1, here are some possible combes
> > > 
> > >  -  One NIC for storage, another for host mgmt, and put
> > >     the guests all on VLANs
> > > 
> > >      eth0 -> br0        IP addr used for storage
> > >      eth1 -> br1        IP addr used  for host mgmt
> > >      eth1.42 -> br1.42  IP addr, used to talk to guests
> > >      eth1.43 -> br1.43  No IP, guest traffic only
> > >      eth1.44 -> br1.44  No IP, guest traffic only
> > 
> > I don't think that's the right notation, don't you mean 'eth1.42 -> br2'
> > etc. ?
> 
> Yes that was a mistake. 
> 
> > > I think the currently approach of modelling bond, bridges and NICs
> > > makes this a little hard, particularly if the netcf API only exposes
> > > 'connections' and not interfaces, because some of these setups are
> > > not really connections, only building blocks for 'n' other connections
> > 
> > For that, you'd nest them where they are used, e.g. one connection to
> > establish the base ethernet interface (that might not exist at all):
> > 
> >         <interface type="ethernet" startmode="none">
> >           <name>eth0</name>
> >           <mtu size="1492"/>
> >           <mac address="aa:bb:cc:dd:ee:ff"/>
> >           <dhcp peerdns="no"/>
> >         </interface>
> >         
> > and one for the bridge with a vlan enslaved:
> > 
> >         <interface type="bridge" startmode="onboot">
> >           <name>br0</name>
> >           ...
> >           <bridge stp="off">
> >             <interface type="vlan" device="eth0" tag="42"/>
> >           </bridge>
> >         </interface>
> > 
> > Similarly, a bond enslaved to a bridge, together with a vlan on that
> > bond also enslaved to the bridge would look like
> > 
> >         <interface type="bridge" startmode="onboot">
> >           <name>br0</name>
> >           ...
> >           <bridge stp="off">
> >             <interface type="bond">
> >               <name>bond0</name>
> >               <bond mode="active-backup">
> >                 <interface type="ethernet">
> >                   <name>eth1</name>
> >                 </interface>
> >                 <interface type="ethernet">
> >                   <name>eth0</name>
> >                 </interface>
> >               </bond>
> >             </interface>
> >             <interface type="vlan" device="bond0" tag="42"/>
> >           </bridge>
> >         </interface>
> 
> Here is a proposal that is a compromise between the single hierarchy, and
> completely flat. The break point is only introduced where VLANs appear,
> which is acceptable because when defining VLAns, you don't need to define
> the underlying inteface at the same time - it can exist in its own right
> ahead of time. Only nic+bond or nics+bridge or nic+bond+bridge need to
> be atomically defined at once.
> 
> 
> There are 4 possible arrangements of physical NIC, bond and vlan,
> each of which can use a bridge. This gives 8 total configs
> 
>  1. Physical NIC
> 
>  2. Physical NIC + bridge
> 
>  3. Physical NIC + bond
> 
>  4. Physical NIC + bond + bridge
> 
>  5. Physical NIC + vlan
> 
>  6. Physical NIC + vlan + bridge
> 
>  7. Physical NIC + bond + vlan
> 
>  8. Physical NIC + bond + vlan + bridge
> 
> 
> Of those, the last 4 are the 'hard' ones since there are 'n'
> source points and 'm' end points. The end points are the core
> object the public API wants to deal in.
> 
> The first 4 configs can all be expressed in terms of a single
> interface object, since there is a single end point. The last
> 4 configs suggest one base interface followed by 'n' additional
> interfaces, with the break being where the 1 -> 'n' relation
> appears. The idea of having the intermediate 'end point' appear
> as an interface object in the public API makes sense, because
> these can exist in their own right, before VLANs are added.
> Only bonds/bridges need to be defined as a single entity.
> 
> So the possible configs would appear as XML like
> 
>  1. Physical NIC
> 
>       <interface type='ethernet'>
>          <name>eth0</name>
>       </interface>
> 
>  2. Physical NIC + bridge
> 
>       <interface type="bridge">
>          <name>br0</name>
>          <bridge>
>            <interface type='ethernet'>
>              <name>eth0</name>
>            </interface>
>          </bridge>
>       </interface>
> 
>  3. Physical NIC + bond
> 
>       <interface type="bond">
>          <name>bond0</name>
>          <bond>
>            <interface type='ethernet'>
>              <name>eth0</name>
>            </interface>
>            <interface type='ethernet'>
>              <name>eth1</name>
>            </interface>
>          </bond>
>       </interface>
> 
>  4. Physical NIC + bond + bridge
> 
>       <interface type="bridge">
>          <name>br0</name>
>          <bridge>
>            <interface type="bond">
>               <name>bond0</name>
>               <bond>
>                  <interface type='ethernet'>
>                    <name>eth0</name>
>                  </interface>
>                  <interface type='ethernet'>
>                    <name>eth1</name>
>                  </interface>
>               </bond>
>            </interface>
>          </bridge>
>       </interface>
> 
>  5. Physical NIC + 2 * vlan
> 
>       <interface type="ethernet">
>          <name>eth0</name>
>       </interface>
> 
>       <interface type="vlan">
>          <name>vlan42</name>
>          <vlan tag='42'>
>            <interface type='ethernet'>
>              <name>eth0</name>
>            </inteface>
>          </vlan>
>       </inteface>
> 
>       <interface type="vlan">
>          <name>vlan48</name>
>          <vlan tag='48'>
>            <interface type='ethernet'>
>              <name>eth0</name>
>            </inteface>
>          </vlan>
>       </inteface>
> 
> 
>  6. Physical NIC + 2 * vlan + bridge
> 
>       <interface type="ethernet">
>          <name>eth0</name>
>       </interface>
> 
>       <interface type='bridge'>
>          <name>br42</name>
>          <bridge>
>             <interface type="vlan">
>                <name>vlan42</name>
>                <vlan tag='42'>
>                  <interface type='ethernet'>
>                    <name>eth0</name>
>                  </inteface>
>                </vlan>
>             </inteface>
>          </bridge>
>       </interface>
> 
>       <interface type='bridge'>
>          <name>br42</name>
>          <bridge>
>             <interface type="vlan">
>                <name>vlan42</name>
>                <vlan tag='42'>
>                  <interface type='ethernet'>
>                    <name>eth0</name>
>                  </inteface>
>                </vlan>
>             </inteface>
>          </bridge>
>       </interface>
> 
> 
>  7. Physical NIC + bond + 2 * vlan
> 
>       <interface type="bond">
>          <name>bond0</name>
>          <bond>
>            <interface type='ethernet'>
>              <name>eth0</name>
>            </interface>
>            <interface type='ethernet'>
>              <name>eth1</name>
>            </interface>
>          </bond>
>       </interface>
> 
>       <interface type="vlan">
>          <name>vlan42</name>
>          <vlan tag='42'>
>            <interface type='bond'>
>              <name>bond0</name>
>            </inteface>
>          </vlan>
>       </inteface>
> 
>       <interface type="vlan">
>          <name>vlan48</name>
>          <vlan tag='48'>
>            <interface type='bond'>
>              <name>bond0</name>
>            </inteface>
>          </vlan>
>       </inteface>
> 
>  8. Physical NIC + bond + 2 * vlan + bridge
> 
> 
>       <interface type="bond">
>          <name>bond0</name>
>          <bond>
>            <interface type='ethernet'>
>              <name>eth0</name>
>            </interface>
>            <interface type='ethernet'>
>              <name>eth1</name>
>            </interface>
>          </bond>
>       </interface>
> 
>       <interface type='bridge'>
>          <name>br42</name>
>          <bridge>
>             <interface type="vlan">
>                <name>vlan42</name>
>                <vlan tag='42'>
>                  <interface type='bond'>
>                    <name>bond0</name>
>                  </inteface>
>                </vlan>
>             </inteface>
>          </bridge>
>       </interface>
> 
>       <interface type='bridge'>
>          <name>br42</name>
>          <bridge>
>             <interface type="vlan">
>                <name>vlan42</name>
>                <vlan tag='42'>
>                  <interface type='bond'>
>                    <name>bond0</name>
>                  </inteface>
>                </vlan>
>             </inteface>
>          </bridge>
>       </interface>
> 
> 
> 
> Of course, you could actually have a hybrid of 7/8, where some vlans
> where bridged, and others direct endpoints. That's trivally handled
> there of course.

  Hum, since an XML can only have one single root, I suggest to put a
wrapper around multiple definitions and if you call it <interfaces>
that looks a bit like my own proposal but more recursive.
  I still suggest to change having name as an attribute on the 
<interface> tags because it allows to easilly do the ID/IDREF matching.
for references.

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel veillard com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/


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