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. Agreed. > 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. Agreed. > 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. Agreed. > > 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. David [1] http://wiki.libvirt.org/page/Networking#Fedora.2FRHEL_Bridging -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list