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