[netcf-devel] Bridge XML-API

Jonas Eriksson jonas.j.eriksson at ericsson.com
Mon Jun 1 09:50:45 UTC 2009


On Fri, May 29, 2009 at 03:50:24PM -0700 David Lutterkort wrote:
> On Wed, 2009-05-20 at 08:38 +0200, Jonas Eriksson wrote:
> > > As far as libvirt is concerned, this can be achieved with a private
> > > network[1] - I am not convinced that a bridge without a NIC makes much
> > > sense in general for netcf, especially since the main use case, a
> > > private network for VM's running on a host, is already covered by
> > > libvirt.
> > 
> > I do not agree. First of, the private networks assume NAT or some
> > other kind of forwarding, which is not always wanted.
> 
> No, you can set up completely private networks with libvirt; one of the
> use cases for libvirt networking is specifically allowing VM's on a
> disconnected host to communicate with each other.

Sorry, my bad. You are correct. Strange that I did not find this
when i checked earlier, as I found it right away this time.

> >  Second,
> > should not libvirt make use of netcf to do this configuration?
> > The task is not that uncommon, and ought to be supported by most
> > back-ends, or am I wrong here?
> 
> Possibly, though the libvirt code is there, and this is a little outside
> the scope of netcf, since netcf specifically tries to ease the setup of
> physical network interfaces on a machine.

This is more of a point for libvirt, which I will raise in that
forum when possible. I feel that it would be nice to have only
one type of network in libvirt, so that a network can be changed
while a running VM uses it from for example a isolated bridge to
a bridge that contains a physical interface.

> > In related news, I have discovered that some sort of address
> > definition is required (<ip> or <dhcp>) for an interface. It is
> > my strong belief that the interface-addressing should be made
> > <optional>, as you do not always want for example bridges to have
> > IP-adresses.
> 
> That is a side-effect of netcf's main purpose: easing the setup of
> _connections_ based on physical NIC's on a machine.

I'm sorry to keep going on about this, but I just don't see how
this affect the main purpose of netcf in a negative way; if
anything it makes netcf more flexible and leaves this policy to
the applications that use netcf. The implementation of policy in
this middle-layer seems somewhat misplaced, that's all I'm
saying.

> >  My example of this is a data connection that is used
> > only by VMs and not by the host, while there exist a control
> > network which the host has an IP address on.
> 
> The former, as I said is taken care of by libvirt networks; besides, the
> 'bridge-without-an-interface' only really makes sense if the VM's on
> that bridge have their networking set up statically. That seems to me
> very much a niche use case - more commonly you want your VM's to DHCP -
> again, something that libvirt's netowrking will let you do w/o much
> work.

Ok, I understand the core purpose of netcf, but the policy part
makes me a bit unsure whether this is a good choice for libvirt
to use as a network backend.

One question however remain; what kind of behavior is expected
if I have (for example) a bridge w/o interfaces (or IP) defined
in the network configuration script on my host and decide that I
should migrate to netcf? The netcf-XML that would be generated
from this config would be illegal becase of the choices made in
this case, and the existing interface can therefore not be
changed in netcf.

In the case of options that are not supported by netcf, I assume
that these can be ignored and merged with the changes committed
to netcf later on. However, policy restrictions on options that
netcf understands for cases that are perfectly legal in all
backends i know of may create some problems. What are the views
on this?

Regards,
Jonas

--
Jonas Eriksson
Consultant at AS/EAB/FLJ/IL
Combitech AB
Älvsjö, Sweden


More information about the netcf-devel mailing list