Re: [libvirt] [Fwd: first cut public API for physical host interface configuration]
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 :|