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