qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Lucas Meneghel Rodrigues <lmr@redhat.com>,
	Kevin Wolf <kwolf@redhat.com>,
	KVM mailing list <kvm@vger.kernel.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"libvir-list@redhat.com" <libvir-list@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	QEMU devel <qemu-devel@nongnu.org>,
	Juan Jose Quintela Carreira <quintela@redhat.com>,
	Avi Kivity <avi@redhat.com>
Subject: Re: [Qemu-devel] qemu and qemu.git -> Migration + disk stress introduces qcow2 corruptions
Date: Thu, 10 Nov 2011 18:42:00 +0000	[thread overview]
Message-ID: <20111110184200.GC17987@redhat.com> (raw)
In-Reply-To: <4EBC1792.3030004@codemonkey.ws>

On Thu, Nov 10, 2011 at 12:27:30PM -0600, Anthony Liguori wrote:
> What does libvirt actually do in the monitor prior to migration
> completing on the destination?  The least invasive way of doing
> delayed open of block devices is probably to make -incoming create a
> monitor and run a main loop before the block devices (and full
> device model) is initialized.  Since this isolates the changes
> strictly to migration, I'd feel okay doing this for 1.0 (although it
> might need to be in the stable branch).

The way migration works with libvirt wrt QEMU interactions is now
as follows

 1. Destination.
       Run   qemu -incoming ...args...
       Query chardevs via monitor
       Query vCPU threads via monitor
       Set disk / vnc passwords
       Set netdev link states
       Set balloon target

 2. Source
       Set  migration speed
       Set  migration max downtime
       Run  migrate command (detached)
       while 1
          Query migration status
          if status is failed or success
            break;

 3. Destination
      If final status was success
         Run  'cont' in monitor
      else
         kill QEMU process

 4. Source
      If final status was success and 'cont' on dest succeeded
         kill QEMU process
      else
         Run 'cont' in monitor


In older libvirt, the bits from step 4, would actually take place
at the end of step 2. This meant we could end up with no QEMU
on either the source or dest, if starting CPUs on the dest QEMU
failed for some reason.


We would still really like to have a 'query-migrate' command for
the destination, so that we can confirm that the destination has
consumed all incoming migrate data successfully, rather than just
blindly starting CPUs and hoping for the best.

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

  reply	other threads:[~2011-11-10 18:42 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-09 16:29 [Qemu-devel] qemu and qemu.git -> Migration + disk stress introduces qcow2 corruptions Lucas Meneghel Rodrigues
2011-11-09 16:39 ` Anthony Liguori
2011-11-09 17:02   ` Avi Kivity
2011-11-09 17:35     ` Anthony Liguori
2011-11-09 19:53       ` Juan Quintela
2011-11-09 20:18       ` Michael S. Tsirkin
2011-11-09 20:22         ` Anthony Liguori
2011-11-09 21:00           ` Michael S. Tsirkin
2011-11-09 21:01             ` Anthony Liguori
2011-11-10 10:41               ` Kevin Wolf
2011-11-10 16:50                 ` Juan Quintela
2011-11-10 17:59                   ` Anthony Liguori
2011-11-10 18:00                 ` Anthony Liguori
2011-11-09 20:57         ` Juan Quintela
2011-11-10  8:55       ` Avi Kivity
2011-11-10 17:50         ` Juan Quintela
2011-11-10 17:54         ` Anthony Liguori
2011-11-12 10:20           ` Avi Kivity
2011-11-12 13:30             ` Anthony Liguori
2011-11-12 14:36               ` Avi Kivity
2011-11-10 18:27         ` Anthony Liguori
2011-11-10 18:42           ` Daniel P. Berrange [this message]
2011-11-10 19:11             ` Anthony Liguori
2011-11-10 20:06               ` Daniel P. Berrange
2011-11-10 20:07                 ` Anthony Liguori
2011-11-10 21:30           ` Anthony Liguori
2011-11-11 10:15             ` Kevin Wolf
2011-11-11 14:03               ` Anthony Liguori
2011-11-11 14:29                 ` Kevin Wolf
2011-11-11 14:35                   ` Anthony Liguori
2011-11-11 14:44                     ` Kevin Wolf
2011-11-11 20:38                       ` Anthony Liguori
2011-11-12 10:27                 ` Avi Kivity
2011-11-12 13:39                   ` Anthony Liguori
2011-11-12 14:43                     ` Avi Kivity
2011-11-12 16:01                       ` Anthony Liguori
2011-11-12 10:25               ` Avi Kivity
2011-11-14  9:58                 ` Kevin Wolf
2011-11-14 10:10                   ` Michael S. Tsirkin
2011-11-15 13:28                   ` Avi Kivity
2011-11-14 10:16                 ` Daniel P. Berrange
2011-11-14 10:24                   ` Michael S. Tsirkin
2011-11-14 11:08                     ` Daniel P. Berrange
2011-11-14 11:21                       ` Kevin Wolf
2011-11-14 11:29                         ` Daniel P. Berrange
2011-11-14 11:34                           ` Michael S. Tsirkin
2011-11-14 11:37                             ` Daniel P. Berrange
2011-11-14 11:51                               ` Michael S. Tsirkin
2011-11-14 11:55                                 ` Daniel P. Berrange
2011-11-14 11:56                               ` Michael S. Tsirkin
2011-11-14 11:58                                 ` Daniel P. Berrange
2011-11-14 12:17                                   ` Michael S. Tsirkin
2011-11-14 11:36                           ` Gleb Natapov
2011-11-14 11:32                       ` Michael S. Tsirkin
2011-11-14 14:19                   ` Anthony Liguori
2011-11-15 13:20                     ` Juan Quintela
2011-11-15 13:56                       ` Anthony Liguori
2011-11-09 19:25 ` Juan Quintela
2011-11-09 23:33   ` Lucas Meneghel Rodrigues

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=20111110184200.GC17987@redhat.com \
    --to=berrange@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=avi@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=kwolf@redhat.com \
    --cc=libvir-list@redhat.com \
    --cc=lmr@redhat.com \
    --cc=mst@redhat.com \
    --cc=mtosatti@redhat.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).