Re: [libvirt] RFC: configuring host interfaces with libvirt
On Fri, 2009-01-16 at 15:06 +0000, Daniel P. Berrange wrote:
On Fri, Jan 16, 2009 at 01:13:18AM +0000, David Lutterkort wrote:
From a style point of view I'd prefer these to all have the same
top level XML element name, and use type='phys|bond|vlan|bridge'
attribute for distinction, since this follows the pattern we use
in the XML for other objects we describe. Type speciic sub-elements
can be used where there are specific extra metadat pieces we need
for that type.
Agreed - I initially thought you couldn't describe that with Relax-NG
(element content being completely different depending on the value of an
attribute), but found out that you actually can do that.
I think the fact that the XML description of the devices is quite
different, and the underling impl will be quite different, suggests
that re-using existing APIs is not worthwhile.
Agreed - that seems to be the consensus.
> * Do we expect interfaces to be in a specific state before we
create them
> or do we just tear them down and reconfigure them no matter what ?
I think we should expect the mgmt app to have put the device
in suitable state. eg, if you're creating a bridge containing
eth0, we should expect that the eth0 has been taken offline
already.
What's the mgmt app in this context ? I am thinking that if you tell
libvirt to change the config of eth0, it should just nuke whatever
config it may already have.
> * Are there crucial config options that are not covered by the
sketches
> above (e.g., setting an explicit MTU) ? Are there things in the XML
> sketches above that will be impossible to implement on some OS ?
There are almost certainly things we won't be able to implement for certain
backends. XenAPI's API does not allow for VLANs for example.
This brings up an important wrinkle: selection of the 'interface' driver
will mostly be independent of the HV, since it depends more on the
OS/distro you are running as your host than on your HV. I've been hoping
we could just sidestep Xen's network handling altogether and just focus
on doing the right thing for the host platform, regardless of HV. Since
we need that for kvm anyway, dealing with the networking part of Xen
would just add redundant driver implementations.
David