From: Kevin Wolf <kwolf@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Peter Krempa <pkrempa@redhat.com>, svc-armband <armband@enea.com>,
Markus Armbruster <armbru@redhat.com>,
Jeff Cody <jcody@redhat.com>,
Ciprian Barbu <Ciprian.Barbu@enea.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Max Reitz <mreitz@redhat.com>,
Alexandru Avadanii <Alexandru.Avadanii@enea.com>
Subject: Re: [Qemu-devel] nbd: Possible regression in 2.9 RCs
Date: Tue, 4 Apr 2017 16:53:48 +0200 [thread overview]
Message-ID: <20170404145348.GD4536@noname.str.redhat.com> (raw)
In-Reply-To: <d270f1a4-5814-9b23-61f6-745c73ecaadd@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1881 bytes --]
Am 04.04.2017 um 16:04 hat Paolo Bonzini geschrieben:
> On 04/04/2017 14:16, Kevin Wolf wrote:
> > Just not requesting the
> > write permission initially if runstate_check(RUN_STATE_INMIGRATE) is
> > easy. But we need to find a place to actually request it later, after
> > the mirror has completed, and before the VM is running.
>
> Isn't there already a bdrv_invalidate_cache_all or something like that
> called when the VM is started?
bdrv_invalidate_cache_all() is different in two aspects.
First, it starts at the BDS level and propagates down to children, but
not up to the parents, where the permissions are set.
Second, bdrv_invalidate_cache_all() is called immediately when migration
completes. This is before the NBD server is shut down, so we can't
actually request write permissions at this point yet.
> Having to touch all devices would be ugly. Maybe some permissions could
> be marked as "deferred".
Yes, BlockDevOps for it wasn't that great an idea.
We have a common function blkconf_apply_backend_options() that sets the
permissions for any devices that we care about with storage migration.
This function can be changed not to do this during incoming migration,
and then we would need a way to find the BlockConf later when trying to
resume the VM. Failing that, we could try to make it register a notifier
or something.
Or we could mark BlockBackends as "enforce permissions only after
migration has completed" and do this for all BlockBackends of devices.
> The big question is how this fits into release management. We have
> another important regression from the op blocker work and only a week
> to go before the last rc. Are we going to delay 2.9 arbitrarily? Are
> we going to shorten the 2.10 development period correspondingly? (I
> vote yes and yes, FWIW).
Which is the other regression?
Kevin
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2017-04-04 14:53 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-31 16:03 [Qemu-devel] nbd: Possible regression in 2.9 RCs Ciprian Barbu
2017-03-31 17:32 ` Ciprian Barbu
2017-03-31 17:36 ` Ciprian Barbu
2017-03-31 17:43 ` Max Reitz
2017-03-31 17:49 ` Ciprian Barbu
2017-03-31 17:57 ` Max Reitz
2017-03-31 19:07 ` Alexandru Avadanii
2017-04-03 18:52 ` Kashyap Chamarthy
2017-04-04 8:07 ` ciprian.barbu
2017-04-03 8:15 ` Kevin Wolf
2017-04-03 12:39 ` Max Reitz
2017-04-03 13:00 ` Kevin Wolf
2017-04-03 13:50 ` Peter Krempa
2017-04-04 12:16 ` Kevin Wolf
2017-04-04 13:51 ` Eric Blake
2017-04-04 14:04 ` Paolo Bonzini
2017-04-04 14:53 ` Kevin Wolf [this message]
2017-04-04 15:09 ` Paolo Bonzini
2017-04-05 11:01 ` Kevin Wolf
2017-04-05 21:13 ` Paolo Bonzini
2017-04-06 8:48 ` Kevin Wolf
2017-04-06 9:03 ` Kevin Wolf
2017-04-03 19:48 ` Eric Blake
2017-04-03 19:44 ` Eric Blake
2017-04-04 8:17 ` ciprian.barbu
2017-04-04 11:00 ` Paolo Bonzini
2017-04-04 11:14 ` Daniel P. Berrange
2017-04-03 12:51 ` Peter Krempa
2017-04-04 13:19 ` Kevin Wolf
2017-04-04 13:27 ` Peter Krempa
2017-04-04 13:54 ` Kevin Wolf
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=20170404145348.GD4536@noname.str.redhat.com \
--to=kwolf@redhat.com \
--cc=Alexandru.Avadanii@enea.com \
--cc=Ciprian.Barbu@enea.com \
--cc=armband@enea.com \
--cc=armbru@redhat.com \
--cc=jcody@redhat.com \
--cc=mreitz@redhat.com \
--cc=pbonzini@redhat.com \
--cc=pkrempa@redhat.com \
--cc=qemu-devel@nongnu.org \
/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).