Re: [libvirt PATCH] Port-profile ID support using IFLA_VF_PORT_PROFILE netlink msg

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Mon, 10 May 2010, Stefan Berger wrote:


kashyapv@xxxxxxxxxxxxxxxxxx wrote on 05/10/2010 03:30:10 AM:


>
> <cut...>
>
> > >     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
> >
>
> The 'VSI Instance ID' is associated with a virtual interface. Therefore, a
> guest might have multiple VSI-instance IDs - each associated with a
separate
> virtual NIC.

Alright, then this becomes the 3rd UUID (besides guest and host UUID that
Scott
seems to want) to initiate the setup protocol with the switch. So the list
of
parameters above is necessary to be provided from the 'outside'.

Yes.


I am wondering what the first three parameters are related to. Do they
reflect
specifics of a particular attached switch ? Should this information migrate

Yes, these are keys to the database that the switch consults to impose the
profiles (filter rules, qos etc.).

The 'VSI Mgr Id' is the specific database, and VSI_type_ID is the specific
profile to be applied. It is expected that the fabric management entity
may create different versions of the profiles. Therefore, the version may be
used in retrieving the exact profile to be applied.

The KVM host is really telling the switch the parameters to the actual profile to be retrieved and associated to a particular virtual network
interface (mac/vlan) instance.


with
a VM to another switch and possibly cause the setup protocol to fail because
that
switch requires a different manager, type or type version ID for example?

The switch will, using other link level protocols, access the database and download the profile. The switch is not tied to the database but is only told which database to download the profiles from.

Vivek



Not that
this would then make things easier at all (to code), but at least it would
provide
a correct long term solution if this information actually did not go into VM
metadata but was a host's local switch configuration data that could be
different
for every attached Ethernet interface. This information would have to then
go into some local configuration file that libvirt can read when needed.

   Stefan
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]