[libvirt] [RFC v1 0/6] Live Migration with ephemeral host NIC devices

[Daniel P. Berrange]

On Wed, May 13, 2015 at 09:40:23AM +0100, Dr. David Alan Gilbert wrote:
> * Peter Krempa (pkrempa at redhat.com) wrote:
> > On Wed, May 13, 2015 at 09:08:39 +0100, Dr. David Alan Gilbert wrote:
> > > * Peter Krempa (pkrempa at redhat.com) wrote:
> > > > On Wed, May 13, 2015 at 11:36:26 +0800, Chen Fan wrote:
> > > > > my main goal is to add support migration with host NIC
> > > > > passthrough devices and keep the network connectivity.
> > > > > 
> > > > > this series patch base on Shradha's patches on
> > > > > https://www.redhat.com/archives/libvir-list/2012-November/msg01324.html
> > > > > which is add migration support for host passthrough devices.
> > > > > 
> > > > >  1) unplug the ephemeral devices before migration
> > > > > 
> > > > >  2) do native migration
> > > > > 
> > > > >  3) when migration finished, hotplug the ephemeral devices
> > > > 
> > > > IMHO this algorithm is something that an upper layer management app
> > > > should do. The device unplug operation is complex and it might not
> > > > succeed which will make the current migration thread hang or fail in an
> > > > intermediate state that will not be recoverable.
> > > 
> > > However you wouldn't want each of the upper layer management apps implementing
> > > their own hacks for this; so something somewhere needs to standardise
> > > what the guest sees.
> > 
> > The guest still will see an PCI device unplug request and will have to
> > respond to it, then will be paused and after resume a new PCI device
> > will appear. This is standardised. The nonstandardised part (which can't
> > really be standardised) is how the bonding or other guest-dependant
> > stuff will be handled, but that is up to the guest OS to handle.
> 
> Why can't that be standardised?   Don't we need to provide the information
> on what to bond to the guest and that this process is happening?  The previous
> suggestion was to use guest-agent for this.

When we've had "standardized" policy decisions in libvirt before it has
come back to bite us later. The block migration code is a prime example.
Someone decided that the standardized behaviour should be that block
migrate skips readonly disks. Everything looked great for a while and
then a new use case came up in OpenStack for which this standardized
behaviour is no longer suitable. Now we have to abandon this standardized
policy and implement what we actually want in OpenStack itself.

This is the key problem with applying policy decisions inside libvirt,
and thus why our focus is on providing the mechanisms on which applications
should build the policies they specifically desire.

Regards,
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 :|