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
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list