Re: [libvirt] [libvirt PATCH] Port-profile ID support using IFLA_VF_PORT_PROFILE netlink msg
Scott Feldman <scofeldm(a)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(a)redhat.com> wrote:
> * Scott Feldman (scofeldm(a)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
Attachments:
- attachment.html (text/html — 4.1 KB)