[libvirt] RFC: configuring host interfaces with libvirt

[Jim Fehlig]

Adding Marius (SuSE sysconfig maintainer) in case I'm misspeaking :-)

David Lutterkort wrote:
> 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.

manual
  Interface will be set up if ifup is called manually.
ifplugd
  Interface will be controlled from  ifplugd
nfsroot
  Nearly like auto, but interfaces with this startmode will never be
  shut down via rcnetwork stop

>  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
>   

On SuSE, the related ifcfg syntax is

STARTMODE={manual|auto|hotplug|ifplugd|nfsroot|off}

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

This is probably best answered by Marius.

Jim