All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: amit.shah@redhat.com, cristian.klein@cs.umu.se,
	qemu-devel@nongnu.org, quintela@redhat.com
Subject: Re: [Qemu-devel] [PATCH 0/3] Migration cancel with dead network
Date: Thu, 8 Jan 2015 11:29:59 +0000	[thread overview]
Message-ID: <20150108112958.GB2423@work-vm> (raw)
In-Reply-To: <20150108112242.GB12056@redhat.com>

* Daniel P. Berrange (berrange@redhat.com) wrote:
> On Thu, Jan 08, 2015 at 11:11:29AM +0000, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
> > 
> > If the remote host, or networking dies during a migration, the socket can be
> > waiting for a long timeout, and migration_cancel can't complete the cancel
> > for a long time (and you can't start a new one to somewhere else).
> > (Where 'long' is the TCP timeout, that's ~15 mins)
> > 
> > This patch set uses the shutdown(2) syscall to unblock any write/sends that
> > are in progress to let the migrate_cancel happen quickly.
> > 
> >   1/3: socket shutdown  - An updated patch from my postcopy world to
> >                           add a shut_down method on QEMUFile - only
> >                           for 'socket' (where the syscall is supported).
> > 
> >   2/3: Handle bi-directional communication for fd migration
> >                         - A patch from Cristian Klein to use the socket
> >                           QEMUFile for FDs that are passed in, if the FDs
> >                           are sockets; this is needed so that libvirt
> >                           migrations can take advantage of the other patches.
> >                           Again this patch (and its naming) come from the
> >                           postcopy world.
> > 
> >   3/3: migration_cancel: shutdown migration socket
> >                         - A new patch that uses the shutdown in migrate_fd_cancel
> > 
> > 
> > Note this does not fix the timeout if you try to migrate to an already dead host;
> > the connect timeout is typically a much shorter 2 minutes anyway.
> 
> In any libvirt managed setup, you'd need to address the connect timeout
> issue in libvirt instead, since libvirt always uses fd based migration.
> ie libvirt estabishes the connection & then passes the TCP Socket to
> QEMU.
> 
> It should be possible for libvirt to use a non-blocking connect()
> call and catch use of its virDomainMigrateCancel APi to stop the
> connection attempt.

Yes, although as I say I've not fixed the (must shorter) connect side timeout
on the QEMU side either.

How does libvirt behave if you cancel a tunnelled migration with the network
dieing in the middle?

Dave

> 
> 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 :|
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

  reply	other threads:[~2015-01-08 11:30 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-08 11:11 [Qemu-devel] [PATCH 0/3] Migration cancel with dead network Dr. David Alan Gilbert (git)
2015-01-08 11:11 ` [Qemu-devel] [PATCH 1/3] socket shutdown Dr. David Alan Gilbert (git)
2015-01-09  6:50   ` Amit Shah
2015-01-08 11:11 ` [Qemu-devel] [PATCH 2/3] Handle bi-directional communication for fd migration Dr. David Alan Gilbert (git)
2015-01-08 11:11 ` [Qemu-devel] [PATCH 3/3] migration_cancel: shutdown migration socket Dr. David Alan Gilbert (git)
2015-01-08 11:22 ` [Qemu-devel] [PATCH 0/3] Migration cancel with dead network Daniel P. Berrange
2015-01-08 11:29   ` Dr. David Alan Gilbert [this message]
2015-01-08 11:33     ` Daniel P. Berrange
2015-01-08 12:10 ` Paolo Bonzini
2015-01-09  6:50 ` Amit Shah

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150108112958.GB2423@work-vm \
    --to=dgilbert@redhat.com \
    --cc=amit.shah@redhat.com \
    --cc=berrange@redhat.com \
    --cc=cristian.klein@cs.umu.se \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.