Re: [Qemu-devel] [libvirt] [RFC 0/7] Live Migration with Pass-through Devices proposal

[Michael S. Tsirkin]

On Tue, May 19, 2015 at 03:21:49PM +0100, Daniel P. Berrange wrote:
> On Tue, May 19, 2015 at 10:15:17AM -0400, Laine Stump wrote:
> > On 05/19/2015 05:07 AM, Michael S. Tsirkin wrote:
> > > On Wed, Apr 22, 2015 at 10:23:04AM +0100, Daniel P. Berrange wrote:
> > >> On Fri, Apr 17, 2015 at 04:53:02PM +0800, Chen Fan wrote:
> > >>> backgrond:
> > >>> Live migration is one of the most important features of virtualization 
> > >>> technology.
> > >>> With regard to recent virtualization techniques, performance of network 
> > >>> I/O is critical.
> > >>> Current network I/O virtualization (e.g. Para-virtualized I/O, VMDq) 
> > >>> has a significant
> > >>> performance gap with native network I/O. Pass-through network devices 
> > >>> have near
> > >>> native performance, however, they have thus far prevented live 
> > >>> migration. No existing
> > >>> methods solve the problem of live migration with pass-through devices 
> > >>> perfectly.
> > >>>
> > >>> There was an idea to solve the problem in website:
> > >>> https://www.kernel.org/doc/ols/2008/ols2008v2-pages-261-267.pdf
> > >>> Please refer to above document for detailed information.
> > >>>
> > >>> So I think this problem maybe could be solved by using the combination 
> > >>> of existing
> > >>> technology. and the following steps are we considering to implement:
> > >>>
> > >>> -  before boot VM, we anticipate to specify two NICs for creating 
> > >>> bonding device
> > >>>    (one plugged and one virtual NIC) in XML. here we can specify the 
> > >>> NIC's mac addresses
> > >>>    in XML, which could facilitate qemu-guest-agent to find the network 
> > >>> interfaces in guest.
> > >>>
> > >>> -  when qemu-guest-agent startup in guest it would send a notification 
> > >>> to libvirt,
> > >>>    then libvirt will call the previous registered initialize callbacks. 
> > >>> so through
> > >>>    the callback functions, we can create the bonding device according 
> > >>> to the XML
> > >>>    configuration. and here we use netcf tool which can facilitate to 
> > >>> create bonding device
> > >>>    easily.
> > >> I'm not really clear on why libvirt/guest agent needs to be involved in 
> > >> this.
> > >> I think configuration of networking is really something that must be 
> > >> left to
> > >> the guest OS admin to control. I don't think the guest agent should be 
> > >> trying
> > >> to reconfigure guest networking itself, as that is inevitably going to 
> > >> conflict
> > >> with configuration attempted by things in the guest like NetworkManager 
> > >> or
> > >> systemd-networkd.
> > > There should not be a conflict.
> > > guest agent should just give NM the information, and have  NM do
> > > the right thing.
> > 
> > That assumes the guest will have NM running. Unless you want to severely
> > limit the scope of usefulness, you also need to handle systems that have
> > NM disabled, and among those the different styles of system network
> > config. It gets messy very fast.
> 
> Also OpenStack already has a way to pass guest information about the
> required network setup, via cloud-init, so it would not be interested
> in any thing that used the QEMU guest agent to configure network
> manager. Which is really just another example of why this does not
> belong anywhere in libvirt or lower.  The decision to use NM is a
> policy decision that will always be wrong for a non-negligble set
> of use cases and as such does not belong in libvirt or QEMU. It is
> the job of higher level apps to make that kind of policy decision.

Using NM is up to users. On some of my VMs, I bring up links manually
after each boot.  We can provide the into to guest, and teach NM use
that.  If someone will write bash scripts to use this info, that's also
fine.

> > > Users are actually asking for this functionality.
> > >
> > > Configuring everything manually is possible but error
> > > prone.
> > 
> > Yes, but attempting to do it automatically is also error prone (due to
> > the myriad of different guest network config systems, even just within
> > the seemingly narrow category of "Linux guests"). Pick your poison :-)
> 
> Also note I'm not debating the usefulness of the overall concept
> or the need for automation. It simply doesn't belong in libvirt or
> lower - it is a job for the higher level management applications to
> define a policy for that fits in with the way they are managing the
> virtual machines and the networking.
> 
> Regards,
> Daniel

Users are asking for this automation, so it's useful to them. We can
always tell them no. Saying no because we seem unable to be able to
decide where this useful functionality fits does not look like a good
reason.

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