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

[Scott Feldman]

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

VSI Instance ID would come from client UUID (or is it host 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?

-scott