<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