Re: [libvirt] [libvirt PATCH] Port-profile ID support using IFLA_VF_PORT_PROFILE netlink msg
On Mon, 10 May 2010, Scott Feldman wrote:
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
This requires some way to manage the mappings which the recipient would
need to know to retrieve.
VSI Instance ID would come from client UUID (or is it host UUID?).
The two proposals have the MAC address of the guest interface in common but
the other parameters are different.
The VSI_intance is equivalent to the virtual interface and so is not the
same as the client UUID.
It might be preferable to follow Stefan's suggestion and separate out the
contents:
<interface type='direct'>
<source dev='static' mode='vepa'/>
<model type='virtio'/>
<vsi managerid='12' typeid='0x123456' typeidversion='1'
instanceid='fa9b7fff-b0a0-4893-8e0e-beef4ff18f8f' />
<filterref filter='clean-traffic'/>
</interface>
<interface type='direct'>
<source dev='static' mode='vepa'/>
<model type='virtio'/>
<vsi profileid='my_profile'/>
</interface>
The VirVSIType (802.1Qbg or 802.1Qbh) allows the recipient to filter out the
content. That shouls allow for the elements below while keeping the same
infrastructure (well - not the friendly name maybe).
Vivek
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
--
libvir-list mailing list
libvir-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list