9:13 p.m.
Scott Feldman <scofeldm(a)cisco.com> wrote on 05/08/2010 07:28:11 PM:
chrisw, libvir-list, libvir-list-bounces, Vivek Kashyap
On 5/8/10 12:12 PM, "Stefan Berger" <stefanb(a)us.ibm.com> wrote:
>> From: Scott Feldman <scofeldm(a)cisco.com>
>> The device XML is:
>>
>> <interface type='direct'>
>> <source dev='eth2' mode='private'
profileid='dc_test'/>
>> <mac address='00:16:3e:1a:b3:4b'/>
>> </interface>
>>
>> The port-profile ID msg is sent to source dev.
>
> Great. Now we have two competing implementations where the underlying
> technology is supposed to be VEPA in both but the parameters to set
> it up are vastly different --
> if you compare
> against Vivek's post yesterfa. Above you are providing a profile id in
> form of a string.
> Is that string above just a dummy example or a real-world parameter
that
> can actually be passed?
It was an example string. The RTM_SETLINK IFLA_VF_PORT_PROFILE msg type
uses u8 array for port_profile, with the idea that it can hold a string
(as
in the above example) or some encoded bytes.
> Vivek posted a message yesterday showing now 4 different parameters...
are
> these somehow encoded in the profileid in your case or you
simply
don't
> need them?
Yes, somehow encoded. There was discussion on the kernel netdev mailing
list on how to merge the VDP tuple into the port-profile, but I haven't
seen
the final form. Can you help push that discussion along? Our case
doesn't
need the VDP tuple encoded in port-profile. We need a string to
identify
the desired port-profile.
I thought this was the work of the standards committee ... If I understand
the
situation correctly, then there is a setup protocol that needs to be run
with
the switch to setup parameters for clients' network streams on a port.
That
protocol needs a couple of parameters. In your case you seem to need the
profile id and then the hosts' uuid. What else do you need? Do you need
the
manager ID in that protocol + type id + type id version as proposed
yesterday?
Or is the protocol not 100% defined, yet?
VSI Manager ID 1 octet
VSI Type ID 3 octets
VSI Type ID Version 1 octet
VSI Instance ID 16 octets <-- taken care of via
dimdecode
I think we can agree on these goals:
1) single RTM_SETLINK netlink msg type for set/unset of port-profile
2) single method in libvirt to send port-profile using RTM_SETLINK
3) single representation in XML
I'm not sure is 3) is possible given the different encodings of
port-profile. Can the VDP tuple be represented as a string, e.g.
"1.2345.6"?
This is fine by me, but we could also split it up into different fields.
I assume that different vendors' switches will all somehow need to see the
same parameters so they can run the protocol? Virtual machines will also
be able to migrate to hosts that are connected to different vendors'
switches
and then will always present the same set of parameters since they migrate
along. So I hope this is completely independent of what vendor's switch
is connected to a host.
> I see you are getting the host UUID
> vid dmidecode, so there are still3 parameters left. Anyway, I let you
guys
> figure that out.
Ideally, we'd like to have host UUID, guest UUID, and even name of guest
port, if available. Any extra information passed with the port-profile
The guest UUID is available in libvirt and can be passed through to where
it
is needed but I didn't see you sending it via the netlink message so far.
What is a 'guest port'? The port the cable from the host is connected to
the
switch (port)?
helps mgmt software organize the virtual ports.
> I suppose in your case we would use the external daemon to derive eth0
> from eth0.100 where the
> macvtap would be connected on along with the vlan id in eth0.100. So
the
> functions I posted
> yesterday may need to go into that code then.
In our case, the src device driver in the kernel receives the
RTM_SETLINK
msg directly; there is no external daemon on the host. Our driver
will
handle the RTM_SETLINK msg directly to make sure the virtual port is set
up
accordingly.
Yeah, I guess you can figure out in the kernel whether to contact the
hardware
for eth{0, 1, or 2} to run the protocol on.
Note the RTM_SETLINK msg is sent with multicast RTNLGRP_LINK so either a
host daemon or a kernel netdev driver may receive the port-profile msg.
>> diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
>> index 5fa8c0a..aff6f28 100644
>> --- a/src/qemu/qemu_conf.c
>> +++ b/src/qemu/qemu_conf.c
>> @@ -1479,6 +1479,11 @@ qemudPhysIfaceConnect(virConnectPtr conn,
>> net->model && STREQ(net->model, "virtio"))
>> vnet_hdr = 1;
>>
>> + if (!STREQ(net->data.direct.profileid, ""))
>> + setPortProfileId(net->data.direct.linkdev,
>> + net->data.direct.profileid,
>> + net->mac);
>> +
>
> Since setting up a port profile seems to be a step tightly connected
> to opening the macvtap I'd push this into the openMactapTap function.
I don't think port-profile should be tightly coupled with macvtap. For
example, port-profile would be applicable for vhost-net where the emu
device
sits right on top of the kernel netdev. There is no macvtap in that
case.
Though it seemed a pattern that when a macvtap was opened or closed that
the
function to set or unset the port profile was always called. So instead of
calling
the close macvtap function + the unset function for the profile in 3
different places,
just call the close macvtap function in 3 places and have the close
macvtap
call the unset function for the profile. If other components can also use
the
profile related functions, we can still export them, but at the moment we
don't
have the necessary parameters available if anything else than the
'direct' type of
interface was to be used.
Here are some of the examples use-cases for port-profile that
don't
involve
macvtap:
PCI device passthru
vhost-net
software tagging switch over simple nics that passthru tags
I'm sure there will be other ways invented to plumb the virtual device
to
the guest interface.
Yes, as said, the setPortProfile can then become {vsi|vepa}SetPortProfile,
and be exported
for other functions to use.
>
> use the libvirt function to copy string
>
>
> check for error
>
>
> use libvirt function to copy string
>
I'll resend with this fixes. Thanks for the review.
Yes, and you are using #define's that aren't available for many, yet, so
you
may need to add #ifdef's around certain code parts and fail the function
with error related to unavailable kernel functionality if #ifndef.
Also we'll probably need an rpm dependency on the dmidecode package.
Stefan
-scott