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

David Lutterkort lutter at redhat.com
Thu Mar 26 20:42:59 UTC 2009


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.

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

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

David





More information about the libvir-list mailing list