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