[libvirt] [Fwd: first cut public API for physical host interface configuration]

[Daniel P. Berrange]

On Thu, Mar 26, 2009 at 01:42:59PM -0700, David Lutterkort wrote:
> On Wed, 2009-03-25 at 19:59 +0000, Daniel P. Berrange wrote:
> > When 'virNetwork' talks about "defined" vs "active" interfaces 
> > there are a few things to be aware of:
> > 
> >  - There is a concept of a persistent network. This is a network
> >    which has a config file associated with it. 
> >  - There is a concept of a transient network. This is a network
> >    which does not have any config file associated wit hit.
> 
> For interfaces, I don't think it makes much sense to deal with transient
> interfaces, especially since implementing them would require that we
> reimplement the ifup functionality.
> 
> > You can also have transient interfaces for which there is no
> > ifcfg-eth0 file. eg, if someone does 'brctl addbr foo' you
> > now have a transient interface which is active, but has no
> > config. 
> 
> But then you'd need to run dhclient or ifconfig agaonst foo etc.
> Transient interfaces get us to where we initially said we do not want to
> go: reimplementing a distro's network config scripts.

We probably don't want to do creation of transient interfaces, since
that would entail reimplementing ifup & friends. 

I think it might stil be interesting to be able to report on the
existance of transient interfaces created by external tools. 

For example, if someone  is running a VPN client, they may have a
transient tun0 device for which there is no ifcfg-XXX file, but
we should still be able to report its live configuration to the
users of the libvirt API, even if we don't let them ifup/down that
interface.

> > Typically name + UUID is sufficient
> > for most of our APIs. So given a virInterffacePtr you should be
> > able to lookup a corresponding netcf data structure based on either
> > UUID or name - whichever works best. 
> 
> Actually, UUID isn't so fun, since there's no place in the stock network
> config script to store it. For initscripts, we can just stick a
> NETCF_UUID or whatever variable into the interface config. On Debian, we
> would have to store that info in some lookaside file - and associate it
> by name with an interface, i.e. do something the application might as
> well do on its own. So I am not convinced that UUID is all that useful.

I'm inclined to agree. Perhaps we should instead provide 'hardware address'
as a unique identifier / property in its place, since that's an identifier
that many apps will want to work with when looking at interfaces.

> > To support transient networks, there's also be a use case for an API
> > taking an XML file & calling ifup on the definition immediately
> > without writing out an ifcfg-XXX file. eg
> 
> Unless somebody feels like reimplementing ifup, no transient interfaces.


Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|