Re: [libvirt] migration of vnlink VMs

I'll send a separate email (in a new thread, so it doesn't get lost! ;-) with a new draft of what the network XML should look like, but wanted to respond to Dan's comments inline... On 05/24/2011 10:21 AM, Daniel P. Berrange wrote: I agree, but was being accommodating :-) Since then, Dave has pointed out that the same functionality can be achieved by having the management application grab the XML for the network on the targetted host, and check for matches of any important parameters before deciding to migrate to that host. This has 2 advantages: 1) It is more flexible. The management application can check for more than just mode='vepa', but also any number of other attributes of the network on the target. 2) The result of a host's network not matching the desired mode will be "management app looks elsewhere", rather than "migration fails". The management application will need to do this anyway (even if just to check that the given network is present at all) or, again, face the prospect of the migration failing. So I'll withdraw this piece from the next draft. So the problem is that the new uses are so orthogonal to the current usage that existing management apps encountering this new XML will mistakenly believe that it's "old" XML with a bit of extra stuff that can be ignored (thus leading to mayhem). I think the most important thing is to make sure that a config for one of these new types will have at least one change to an *existing* element/attribute (mine just added a *new* attribute specifying type) that causes existing apps to realize this isn't just an old school network definition that happens to have a few kinks on the side. Your suggestion of using new values for <forward mode="..."> seems like as good an idea as any (actually I can't think of anything else that works as well :-) Right. Perhaps later it can be expanded (at least in some of the modes) to setup these devices when the network is started, but right now the network definition is just used to point to something that already exists and is functioning. Does that gain us anything, though? While it's correct information, it seems redundant (the layer can always be implied from the mode). Are you saying that in the case of a brctl mode, it would be required to fill in both of these? <forward mode="bridge-brctl" dev="br0" .../> <bridge name="br0" .../> I think I would prefer to only use the one in <forward>. Are you suggesting putting it there to help older management apps cope with the new modes? I don't really think it would help; it's really just an accident of implementation that the device in "bridge-brctl" mode happens to be a bridge device. BTW, just to clarify, when you say "SRIOV", what you really mean is "any situation where there are multiple network interface devices connected to the same physical network, and identical connectivity to the guest could be provided by any one of these devices". In other words, it doesn't need to be an SRIOV ethernet card with multiple virtual functions, it could also be an older style setup with multiple physical cards, or multiple complete devices on a single card. But since the pool of devices would only ever be used in one of the new forward modes, which an existing app wouldn't understand anyway, would that really buy us anything? I've thought about this a bit, and I think portgroup is a good idea, but I don't think the name of the device being used fits there. portgroup is a good place to put information about the characteristics of a set of connections, but which device to use is a backend implementation detail, and there isn't necessarily a 1:1 correspondence between the two. portgroup would be used, for example, to configure bandwidth (that's pretty much all VMWare uses it for, plus a blob of "vendor-specific" data), and the guest interface XML would specify which portgroup a guest was going to belong to - if you also set which physical device to use based on portgroup, that would leave the guest XML specifying which physical device to use, which is what we're trying to get away from. (and also it would mean that each physical device would need its own portgroup, which I don't think we want. Thinking more about the maxCount thing, it seems like it might be overkill for now. The case where there must be a limitation of 1 guest per NIC is macvtap passthrough mode, but that's already implied by the fact that it's passthrough. Other than that, libvirt can just attempt to load-balance as best as possible by keeping track of how many connections there are on each device, but not force any artificial limit. We may need to provide some method of reporting the number of connections to any particular network, to be used by a management application for load balancing decisions (although the amount of traffic is probably more important, and that can already be learned). Conclusion on portgroup - a good idea, but not for this, probably for configuration of bandwidth limiting. Ah, now *there's* something that fits in portgroup (since that's likely exactly what it's used for on the vepa/vnlink capable switch). I think it's reasonable to put it in both places, at the top-level (which would apply to all connections) and in portgroup (which would override the global setting for connections using that portgroup). (I think the bandwidth config could be done in the same way.