On Wed, Jun 06, 2012 at 05:15:53PM +0300, Itamar Heim wrote: > Hi Daniel, > > on the quantum-ovirt call today the question of live migration > between multiple technologies was raised. > > iirc, you implemented the abstraction in libvirt between what the > guest sees and the actual host networking implementation for live > migration. > > can you please share if there are any considerations around live > migrations across different network implementations (bridge, sr-iov, > ovs, qbg, openflow, etc.) Yes, we added the ability to use libvirt's 'virtual network' APIs (virNetworkXXXXX) to define host networks using bridging, macvtap, etc, etc. A guest's NICs can then be configured solely using <interface type='network'>. This means that the guest XML will not have any host-specific data in it, as you see when using <interface type='bridge'> or<interface type='direct'> This means you can migrate between machines where the bridges have different names (eg br0 on host A and br7 on host B), without any limitations. You can also migrate between different impls of the same technology (eg traditional software bridging vs macvtap bridging without limitations. Finally, you can migrate between completely different technologies (eg bridging vs vepa), but you will likely loose connectivity in the guests, since the technologies are not compatible at the ethernet layer.

In summary, libvirt configuration ability should not be the limiting factor in migrating between hosts with different networking config. You should only be limited by the ethernet/kernel level compatibility. Daniel

On Sat, Jun 09, 2012 at 03:57:40PM +0300, Itamar Heim wrote: > On 06/08/2012 06:54 PM, Daniel P. Berrange wrote: > >On Wed, Jun 06, 2012 at 05:15:53PM +0300, Itamar Heim wrote: > >>Hi Daniel, > >> > >>on the quantum-ovirt call today the question of live migration > >>between multiple technologies was raised. > >> > >>iirc, you implemented the abstraction in libvirt between what the > >>guest sees and the actual host networking implementation for live > >>migration. > >> > >>can you please share if there are any considerations around live > >>migrations across different network implementations (bridge, sr-iov, > >>ovs, qbg, openflow, etc.) > > > >Yes, we added the ability to use libvirt's 'virtual network' APIs > >(virNetworkXXXXX) to define host networks using bridging, macvtap, > >etc, etc. A guest's NICs can then be configured solely using > ><interface type='network'>. This means that the guest XML will > >not have any host-specific data in it, as you see when using > ><interface type='bridge'> or<interface type='direct'> > > > >This means you can migrate between machines where the bridges have > >different names (eg br0 on host A and br7 on host B), without any > >limitations. > > > >You can also migrate between different impls of the same technology > >(eg traditional software bridging vs macvtap bridging without > >limitations. > > > >Finally, you can migrate between completely different technologies > >(eg bridging vs vepa), but you will likely loose connectivity in > >the guests, since the technologies are not compatible at the ethernet > >layer. > > can you please explain this point - how would packet going out of > the host or arriving to the guest would be different between a > bridged and a vepa implemtnaiton? I'm not the expert on VEPA - I'm just relaying what I have been told wrt VEPA modes in the past. IIUC, with VEPA modes there is quite alot of extra traffic due to a handshake negotiation between the host & switch, before any guest traffic can pass, and there needs to be a special synchronization done with VEPA during migration to maintain state in the switch.