[libvirt] RFC: configuring host interfaces with libvirt

[David Lutterkort]

On Tue, 2009-01-20 at 11:35 -0700, Jim Fehlig wrote:
> David Lutterkort wrote:
> > For certain applications, we want libvirt to be able to configure host
> > network interfaces in a variety of ways; currently, we are most
> > interested in teaching libvirt how to set up ordinary ethernet
> > interfaces, bridges, bonding and vlan's.
> >
> > Below is a high-level proposal of how that could be done. Please comment
> > copiously ;)
> >
> > 1. XML Format
> > =============
> >
> > The first question is how the user would describe the host interfaces they
> > want. Below are some sketches of what an XML representation of the various
> > kinds of interfaces would look like. This covers the minimal amount of
> > settings for these to be useful, though I am sure we'll need to add more
> > over time.
> >
> > <interface device="eth0" onboot="yes">
> >   <hwaddr>00:19:d2:9f:88:96</hwaddr>
> >   <dhcp peerdns="yes"/>
> > </interface>
> >   
> 
> For onboot="yes", something like startmode="onboot" would be better
> IMO.  A startmode attribute would allow also using "manual", "hotplug",
> "ifplug", "nfsroot", etc.

This makes only sense if these additional modes are completely
orthogonal; I am not sure what the start modes 'manual', 'ifplug', and
'nfsroot' should do. For onboot, I assume you mean that they translate
into assignments in ifcfg in the following way

        no startmode attribute  -> ONBOOT=no
        startmode='onboot'      -> ONBOOT=yes
        startmode='hotplug'     -> ONBOOT=yes and HOTPLUG=yes

> WRT dhcp element, would it make sense to consider hostname (hostname to
> send to server) and if to change the local hostname to the hostname
> delivered via dhcp?  E.g.
>     hostname="foo" (default `hostname`)
>     sethostname
> 
> Also route:
>     setrouting (default "yes")
>     setdefaultroute (default "yes")
> 
> and NIS:
>     nis (default "yes")
>     setnisdomain (default "yes")

Yes, they all make sense, though I would probably not support them in
the very first cut.

> What about dhcpv6?  A separate <dhcp6 /> element?

Yeah, we probably need a separate element for that since it pulls in a
slew of other config options.

> > <interface device="eth1" onboot="yes">
> >   <hwaddr>00:19:d2:9f:88:97</hwaddr>
> >   <static ipaddr="192.168.0.5" gateway="192.168.0.1" netmask="255.255.255.0"/>
> > </interface>
> >   
> 
> Similarly, support for IPv6 here.  Either 2 formats:
> 
> ipaddr="192.168.0.5" netmask="255.255.255.0"
> ip6addr="2001:DB8:C::5/64"
> 
> or allow /len for both:
> 
> ipaddr="192.168.0.5/24"
> ipaddr="2001:DB8:ABCD::1/64"

Looks a little strange, but it would simplify notation.

> As for routing info, how about a separate route element:
> 
> <route gateway="192.168.0.1" /> # destination=default
> <route destination="default" gateway="192.168.0.1" />
> <route destination="10.0.0.0/8" gateway="192.168.0.2" />
> <route destination="2001:DB8:C::/64" gateway="2001:DB8:C::1" />
> <route destination="2001:DB8::/32"> # unrecheable route (loopback)
> 
> It would perhaps make sense to use iproute2 names, that is prefix
> instead of destination and nexthop instead of gateway.

For now, I want to stay out of setting up static routes, but I think
that has to come sooner or later.

> Don't recall if this was already brought up, but need a way to specify
> MTU and perhaps ethtool settings as well.

Yeah, that is definitely needed.

> > <interface device="eth2" onboot="yes">
> >   <hwaddr>00:19:d2:9f:88:98</hwaddr>
> > </interface>
> >
> > <bond name="bond00" onboot="yes" mode="active-backup">
> >   <slave device="eth0" primary="yes"/>
> >   <slave device="eth1"/>
> > </bond>
> >   
> 
> In addition to mode attribute for bonds, support for miimon,
> arp_interval, and arp_ip_target?

Sure .. if the initscript suports it, it's easy enough to do ;)

> > <bridge name="br0" stp="off" onboot="yes">
> >   <member device="eth2"/>
> >   <dhcp peerdns="yes"/>
> > </bridge>
> >   
> 
> Attributes to support hellotime, forwarddelay, and maxage?  This would allow
>     <bridge name="br0" stp="on" hellotime="1" maxage="4" fowarddelay="4"
> ..>

My main concern with these is that only forwarddelay, stp, and gcint are
controllable by Fedora/RHEL networking scripts. For hellotime and
maxage, we'd need to hook into the various ifup scripts atthe right
place. Are these directly supported by the SuSe infrastructure ?

David