Scott Feldman <scofeldm@xxxxxxxxx> 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@xxxxxxxxxx> wrote:
>
> > * Scott Feldman (scofeldm@xxxxxxxxx) 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
>
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list