[email protected] 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
[email protected]
https://www.redhat.com/mailman/listinfo/libvir-list
