<tt>kashyapv@linux.vnet.ibm.com 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.</tt> <tt>Alright, then this becomes the 3rd UUID (besides guest and host UUID that Scott</tt> <tt>seems to want) to initiate the setup protocol with the switch. So the list of</tt> <tt>parameters above is necessary to be provided from the 'outside'.</tt> <tt>I am wondering what the first three parameters are related to. Do they reflect</tt> <tt>specifics of a particular attached switch ? Should this information migrate with</tt> <tt>a VM to another switch and possibly cause the setup protocol to fail because that</tt> <tt>switch requires a different manager, type or type version ID for example? Not that</tt> <tt>this would then make things easier at all (to code), but at least it would provide</tt> <tt>a correct long term solution if this information actually did not go into VM</tt> <tt>metadata but was a host's local switch configuration data that could be different</tt> <tt>for every attached Ethernet interface. This information would have to then</tt> <tt>go into some local configuration file that libvirt can read when needed.</tt> <tt> Stefan</tt>