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 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list