All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Jiri Denemark <jdenemar@redhat.com>,
	qemu-devel@nongnu.org, quintela@redhat.com, famz@redhat.com,
	peterx@redhat.com
Subject: Re: [Qemu-devel] [PATCH] migration: Don't activate block devices if using -S
Date: Tue, 10 Apr 2018 16:47:56 +0200	[thread overview]
Message-ID: <20180410144756.GG7026@localhost.localdomain> (raw)
In-Reply-To: <20180410142253.GG2559@work-vm>

Am 10.04.2018 um 16:22 hat Dr. David Alan Gilbert geschrieben:
> * Kevin Wolf (kwolf@redhat.com) wrote:
> > Am 10.04.2018 um 12:40 hat Dr. David Alan Gilbert geschrieben:
> > > Hmm; having chatted to Jiri I'm OK with reverting it, on the condition
> > > that I actually understand how this alternative would work first.
> > > 
> > > I can't currently see how a block-inactivate would be used.
> > > I also can't see how a block-activate unless it's also with the
> > > change that you're asking to revert.
> > > 
> > > Can you explain the way you see it working?
> > 
> > The key is making the delayed activation of block devices (and probably
> > delayed announcement of NICs? - you didn't answer that part) optional
> > instead of making it the default.
> 
> NIC announcments are broken in similar but slightly different ways;  we
> did have a series on list to help a while ago but it never got merged;
> I'd like to keep that mess separate.

Okay. I just thought that it would make sense to have clear migration
phases that are the same for all external resources that the QEMU
processes use.

> > We can use Jirka's suggestion of adding a migration capability that
> > enables it, or I suppose a new option to -incoming could work, too. It
> > doesn't really matter what the syntax is, but the management tool must
> > request it explicitly.
> 
> A new capability is easy to gate the change in behaviour that this patch
> added; I'll do that first thing for 2.13 (given today is rc3 tag it's
> too late).
> 
> However, once we turn this on, to cope with the situation of a block user
> that must start prior to the 'cont' when this behaviour is active, we'd
> also need the 'block-activate' command.

Yes, that's right.

Kevin

  reply	other threads:[~2018-04-10 14:48 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-28 17:02 [Qemu-devel] [PATCH] migration: Don't activate block devices if using -S Dr. David Alan Gilbert (git)
2018-03-28 17:38 ` [Qemu-devel] [PATCH for-2.12] " Eric Blake
2018-03-29  9:45 ` [Qemu-devel] [PATCH] " Dr. David Alan Gilbert
2018-03-31  7:56 ` no-reply
2018-04-03 14:38 ` Kevin Wolf
2018-04-03 20:52   ` Dr. David Alan Gilbert
2018-04-04 10:03     ` Kevin Wolf
2018-04-09 10:27       ` Dr. David Alan Gilbert
2018-04-09 13:40         ` Kevin Wolf
2018-04-09 14:04           ` Dr. David Alan Gilbert
2018-04-09 15:25             ` Kevin Wolf
2018-04-09 15:35               ` Dr. David Alan Gilbert
2018-04-10  7:36           ` Jiri Denemark
2018-04-10  8:18             ` Kevin Wolf
2018-04-10  8:45               ` Dr. David Alan Gilbert
2018-04-10  9:14                 ` Kevin Wolf
2018-04-10 10:40                   ` Dr. David Alan Gilbert
2018-04-10 12:26                     ` Kevin Wolf
2018-04-10 14:22                       ` Dr. David Alan Gilbert
2018-04-10 14:47                         ` Kevin Wolf [this message]
2018-04-11 10:01                           ` Jiri Denemark
2018-04-11 12:49                             ` Kevin Wolf
2018-04-11 13:12                               ` Dr. David Alan Gilbert
2018-04-09 15:28       ` Jiri Denemark

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=20180410144756.GG7026@localhost.localdomain \
    --to=kwolf@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=famz@redhat.com \
    --cc=jdenemar@redhat.com \
    --cc=peterx@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 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.