Re: [libvirt] migration of vnlink VMs

Inline... be the name migrate host Whether a given parameter is unique for each guest (or let's say, whether it can be shared by two or more guests) may also be a config/policy detail for certain parameters. You should take into account that new parameters may be added later on (not only for vepa/vn-link), and could be both unique or shared. For this reason you design should be able to handle such a case. BTW, "instanceid" identifies the virtual nic, therefore it is unique (it is a UUID). instanceid The VSI Instance ID Identifier is generated when a VSI instance (i.e. a virtual interface of a virtual machine) is created. This is a globally unique identifier. Please note that the IEEE specs (802.1Qbh/1Qbg) have undergone some changes in the last few months. The two protos are going to share the same proto VDP for the port profile configuration. Also, new parameters may be introduced and already existent ones may change type. Later this year, when the IEEE drafts will be closer to final versions, there will be updates to the configuration parameters to reflect the changes in the drafts. vepa/vnlink vepa/vnlink, profile "must" in the sense that it is "mandatory"? I can see two cases: 1) src and dst networks are of different types (NOTE: I consider vepa/vnlink different for now, but this will probably change when BH and BG will both use VDP) In this case I do not see why you need to worry about whether parameter param-X used by src host should or should not be used by dst host: it should only if it is a generic parameter and (as such) it does not fall inside the config section that is specific to the network type. Trying to translate parameters between different network types may not be always easy and clean. Even the property "mandatory vs optional" may change with different network types. 2) src and dst networks are of the same type In this case it _does_ make sense to have the possibility of specifying whether a given param is needed or not. However, I believe it would make sense mainly for those parameters that represent optional/desirable features of the proto/net: such config would then be used to decide whether migration will or will not be possible, right? I like the idea of the abstraction, especially the pool of interfaces. However, I think you would have to lose a bit of abstraction in order to make it possible to have migrations between network of different types. I guess your goal is not to make migration possible between each possible combination of network types, is it? There are parameters that are specific to a given network type. How can you expect a migration from network type X to network type Y (Y != X) if you only configure the parameters for type X (and assuming Y comes with at least one mandatory parameter)? What are the combinations of (src/net, dst/net) that you would like to support? Out of curiosity, have you taken into consideration the possibility of defining an abstracted network config as a pool of network types? For example something like this: HOST: Pool of three network sub-types <network type='network'> <name>red-network</name> <source type='direct' mode='vepa'> ... </source> <source type=XXX ...> ... </source> <source type=YYY ...> ... </source> </network> GUEST WHICH ONLY ACCEPTS ONE SPECIFIC TYPE (direct/private): <interface type='network'> <source network='red-network'/> <option prio=1 type='direct' mode='private'> <virtualport type="802.1Qbh"> <parameters profile_name="profile_123"/> </virtualport> </option> </interface> GUEST WHICH ACCEPTS TWO TYPES (direct/private, direct/vepa): <interface type='network'> <source network='red-network'/> <option prio=1 type='direct' mode='private'> <virtualport type="802.1Qbh"> <parameters profile_name="profile_123"/> </virtualport> </option> <option prio=2 type='direct' mode='vepa'> <virtualport type="802.1Qbg"> <parameters managerid="11" typeid="1193047" typeidversion="2" instanceid="09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f"/> </virtualport> </option> </interface> During migration, the dst host would use the options/prios in the guest config XML to select among the options available for the same 'network' on the dst host, just like any other similar handshake. I am not suggesting this approach, I just would like to know if you ever thought about this option and, if you did, why you discarded it. An example of scenario where the above pool of network types may make sense would be the combination vepa+bridge or vnlink+bridge: if something goes wrong during migration and the vepa/OR/vnlink cannot associate the port profile, the guest can at least have a backup net connection through the bridge. It could optionally also re-try the vepa/vnlink association a number of times (libvirt would do it if configured to do so) ... while maintaining temporary connectivity through the bridge. /Chris