[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [libvirt] [Fwd: first cut public API for physical host interface configuration]
- From: David Lutterkort <lutter redhat com>
- To: "Daniel P. Berrange" <berrange redhat com>
- Cc: libvir-list redhat com
- Subject: Re: [libvirt] [Fwd: first cut public API for physical host interface configuration]
- Date: Thu, 26 Mar 2009 13:42:59 -0700
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
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]