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