Scott Feldman <scofeldm@cisco.com> wrote on 05/10/2010 03:53:45 PM:


>
> Stefan Berger, Gerhard Stenzel, libvir-list, libvir-list-bounces
>
> 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

Sounds like this would require a whole new management API to get this mapping onto the
machine and that probably isn't anywhere in place today...

>
> VSI Instance ID would come from client UUID (or is it host UUID?).

Previously sounded to me like this would be a per interface UUID.

>
> 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?

802.1Qbg + 802.1Qbh => 802.1Qbi  :-)

Stefan

>
> -scott
>