On Mon, Jun 11, 2012 at 10:47:16AM +0100, Daniel P. Berrange wrote: > 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.
But at least on the libvirt level, <virtualport> tags are ignored if a domain is migrated from Qbsomething to a bridge? I suppose that a default <virtualport> tag cannot be generated, so migration from bridge to Qb* is impossible without the source tweaking the destinationxml? _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel