[libvirt] [Fwd: first cut public API for physical host interface configuration]
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
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.
More information about the libvir-list