<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.
>
> 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.
Would splitting into different fields make it easier for the recipients to
only access the needed fields rather than parse a complex string? If so,
splitting it makes it easier.
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
Is guest port == virtual interface? And the name as seen in guest??
thanks
Vivek
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list