Re: [libvirt] [libvirt PATCH] Port-profile ID support using IFLA_VF_PORT_PROFILE netlink msg
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 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"?
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
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.
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.
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.
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.
-scott