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

Re: [libvirt] RFC: configuring host interfaces with libvirt

Hi Mark,

On Fri, 2009-01-16 at 09:00 +0000, Mark McLoughlin wrote:
> Hi David,
> On Fri, 2009-01-16 at 01:13 +0000, David Lutterkort wrote:
> > 
> > <bond name="bond00" onboot="yes" mode="active-backup">
> >   <slave device="eth0" primary="yes"/>
> >   <slave device="eth1"/>
> > </bond>
> > 
> > <bridge name="br0" stp="off" onboot="yes">
> >   <member device="eth2"/>
> >   <dhcp peerdns="yes"/>
> > </bridge>
> I don't think we want to define a bridge here, but more that an
> interface is shared - i.e. this is a property of eth2.
> The main concern is that this is the way I'd expect NetworkManager to
> support it - i.e. that you could configure NetworkManager to share eth0,
> rather than ask it to create br0 and add eth0 to it.
> If you just want to create a bridge, you can creati a virtual network.

Is it possible to use DHCP to configure the bridge device itself using
that, similar to what's described in [1] ? And have guest's DHCP
requests forwarded across the bridge ? The docs only talk about static
IP assignments for the bridge device.

> > <vlan device="eth0" tag="42" reorder_hdr="yes"/>
> I think these last three are also interfaces and should be described
> with an <interface> tag e.g.


> I don't think I like this much - these APIs manage a "virtual network"
> which I see as a distinct concept from configuring host hardware.
> Really, I think keeping the two things separate will actually reduce
> confusion in the long run.


> This sounds good, but "interface" is pretty damn generic :-)
>   virNetInterface
>   virNetDevice
>   ...

Sure, virInterface is pretty generic; maybe virNetDevice, though we'd
have to call it <net-device> in the XML for consistency. Naming is
NP-hard ;)

> What I don't like about any of these is that I've always imagined we
> might add further APIs to libvirt for changing a domain's configuration
> without munging XML e.g.
>   int virDomainGetInterfaces(virDomainPtr domain,
>                              virInterfacePtr interfaces,
>                              int *ninterfaces);
>   int virInterfaceSetMacAddress(virInterfacePtr interface,
>                                 const uint8_t mac[6]);
> So, you can see the potential namespace conflicts ...

Not really, since this still follows the naming convention 'vir' +
class_name + method_name. There's a virDomainInterfaceStats, and it
doesn't seem all that confusing to me to distinguish that from a
virInterfaceStats (i.e. stats for all interfaces on the host)

> > 3. Implementation
> > =================
> > 
> > Configuring network interfaces is highly OS and OS-variant/distro
> > dependant. There are at least two different ways how libvirt can go about
> > modifying the host to create interfaces:
> > 
> >   1. Modify the system's network setup scripts (ifcfg-XXX on RH)
> > 
> >   2. Directly use the system's network utilities like ifconfig
> > 
> >   3. Rely on NetworkManager (not an option right now, as NM doesn't know
> >     about bridges and the like)
> It has to be an option - even if it only supports a subset of what the
> other options support.
> I really wouldn't like to see us push ahead with this until we have a
> plan for how this will work with NetworkManager (and a rough agreement
> for how future support for bonding etc. in NetworkManager might be
> configured)

Yeah, I started talking to Dan Williams about their plans etc. Of
course, their main use case (wireless networking) is unimportant for
libvirt. But we should be able to find a way to share some of the
backend bits and the general model for interfaces, umm, net-devices ;)

> The thing is, this has to integrate with existing configuration -
> there's no point in futzing about with "ip link set eth0 ..." if the
> user has configured eth0 with NetworkManager or the distro's networking
> scripts.


> > If we want 'autostart' for an interface to mean 'bring up the interface
> > as soon as the system boots', we are pretty much forced to go with
> > option (1).
> Why?

Because those are what brings up networking at boot - otherwise we'd
define 'autostart' as 'whenever libvirtd starts' - but it doesn't seem
like nay of this is controversial, anyway.


[1] http://wiki.libvirt.org/page/Networking#Fedora.2FRHEL_Bridging

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