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