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'.
I am wondering what the first three parameters are related to. Do they reflect
specifics of a particular attached switch ? Should this information migrate 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? 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