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