[libvirt] [libvirt PATCH] Port-profile ID support using IFLA_VF_PORT_PROFILE netlink msg

[Stefan Berger]

Scott Feldman <scofeldm at 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 at redhat.com> wrote:
> 
> > * Scott Feldman (scofeldm at 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
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20100510/e2018248/attachment-0001.htm>