<tt>Scott Feldman <scofeldm@cisco.com> wrote on 05/10/2010 03:53:45 PM: </tt> <tt>> > Stefan Berger, Gerhard Stenzel, libvir-list, libvir-list-bounces</tt> <tt>> > On 5/10/10 12:14 PM, "Chris Wright" <chrisw@redhat.com> wrote: > > > * Scott Feldman (scofeldm@cisco.com) wrote: > >>> Now the slight differences in technology > >>> that we seem to try to support here are reflected in the parameters that > >>> go into the XML and end up in the netlink messages. Any way to > >>> consolidate that? > >> > >> I doesn't appear we'll be able to consolidate the parameters > between the two > >> technologies based on what I've seen from Arnd's latest patch on the kernel > >> mailing list. The latest proposal is to define a single netlink msg that > >> can handle two disjoint sets of parameters. If there is no way for further > >> consolidation, it probably makes more senses to have two different netlink > >> msgs, one for each parameter set. > > > > Right, and would point to a flag to differentiate the two in xml too. > > Here's a proposal to consolidate both technologies: > > 1) Use the IFLA_VF_PORT_PROFILE netlink msg I defined which has three basic > sets of information: > > a) port-profile name > b) mac addr of guest interface > c) auxiliary info such as host UUID, client UUID, etc. > > 2) Define the XML to pass the above using mcast netlink msg. > > 3) Create a port-profile manager for LLDPAD to map port-profile to internal > protocol settings. The mapping would resolve VDP parameters, for example, > given a port-profile. Like: > > port-profile: "joes-garage" ---> VSI Manager ID: 15 > VSI Type ID: 12345 > VSI Type ID Ver: 1</tt> <tt>Sounds like this would require a whole new management API to get this mapping onto the</tt> <tt>machine and that probably isn't anywhere in place today...</tt> <tt> > > VSI Instance ID would come from client UUID (or is it host UUID?).</tt> <tt>Previously sounded to me like this would be a per interface UUID.</tt> <tt> > > This proposal has these good qualities: > > 1) single netlink msg for kernel and user-space > 2) single parameter set for sender's perspective (libvirt) > 3) single XML spec > 4) single code path in libvirt > 5) (potential) cross-vendor-switch VM migration > 6) user-friendly port-profile names > 7) works for the following use-cases: > > a) firmware adapter that talks to external switch directly > b) software switch that talks to external switch directly > c) host daemon agent that talks to external switch indirectly > > The details of the port-profile mgr would need to be worked out. Is there > local mapping per host or across hosts? > > Comments?</tt> <tt>802.1Qbg + 802.1Qbh => 802.1Qbi :-)</tt> <tt>Stefan</tt> <tt> > > -scott > </tt>