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