chrisw, libvir-list, libvir-list-bounces, Vivek Kashyap
On 5/8/10 12:12 PM, "Stefan Berger" <stefanb@us.ibm.com> wrote:
From: Scott Feldman <scofeldm@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
Scott Feldman <scofeldm@cisco.com> wrote on 05/08/2010 07:28:11 PM: 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
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 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)? 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