[Engine-devel] live migration and different technologies

[Daniel P. Berrange]

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
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|