qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
To: Peter Krempa <pkrempa@redhat.com>
Cc: fam@euphon.net, kwolf@redhat.com, qemu-block@nongnu.org,
	quintela@redhat.com, dgilbert@redhat.com, qemu-devel@nongnu.org,
	stefanha@redhat.com, den@openvz.org, mreitz@redhat.com
Subject: Re: [PATCH v2 0/5] fix migration with bitmaps and mirror
Date: Fri, 3 Apr 2020 14:02:47 +0300	[thread overview]
Message-ID: <a5015250-46f4-c6ed-92b9-779f885e8a4a@virtuozzo.com> (raw)
In-Reply-To: <20191219103638.GJ4914@andariel.pipo.sk>

19.12.2019 13:36, Peter Krempa wrote:
> On Thu, Dec 19, 2019 at 11:51:01 +0300, Vladimir Sementsov-Ogievskiy wrote:
>> Hi all!
>>
>> It's a continuation for
>> "bitmap migration bug with -drive while block mirror runs"
>> <315cff78-dcdb-a3ce-2742-da3cc9f0ca97@redhat.com>
>> https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg07241.html
>>
>> The problem is that bitmaps migrated to node with same node-name or
>> blk-parent name. And currently only the latter actually work in libvirt.
>> And with mirror-top filter it doesn't work, because
>> bdrv_get_device_or_node_name don't go through filters.
> 
> I want to point out that since libvirt-5.10 we use -blockdev to
> configure the backend of storage devices with qemu-4.2 and later. This
> means unfortunately that the BlockBackend of the drive does not have a
> name any more and thus the above will not work even if you make the
> lookup code to see through filters.

Not that this series doesn't make things worse, as it loops through named
block backends when trying to use their name for migration. So with these
patches applied, qemu will just work in more possible scenarios.

> 
> As I've pointed out separately node-names are not good idea to use for
> matching either as they can be distinct on the destination of migration.
> 
> Having same node names for images during migration was not documented as
> a requiremend and even if it was the case when the mirror job is used
> the destination is a different image and thus having a different node
> name is expected.
> 
> Since it's not documented, expect the same situation as with
> autogenerated nodenames, the destination may have different node-names
> and the same node-name may refer to a different image. Implicit matching
> based on node-names is thus impossible.
> 


-- 
Best regards,
Vladimir


  parent reply	other threads:[~2020-04-03 11:04 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-19  8:51 [PATCH v2 0/5] fix migration with bitmaps and mirror Vladimir Sementsov-Ogievskiy
2019-12-19  8:51 ` [PATCH v2 1/5] block: Mark commit and mirror as filter drivers Vladimir Sementsov-Ogievskiy
2020-01-31 19:23   ` Eric Blake
2020-05-14 18:51     ` Eric Blake
2019-12-19  8:51 ` [PATCH v2 2/5] migretion/block-dirty-bitmap: refactor init_dirty_bitmap_migration Vladimir Sementsov-Ogievskiy
2020-01-31 19:28   ` Eric Blake
2019-12-19  8:51 ` [PATCH v2 3/5] block/dirty-bitmap: add bdrv_has_named_bitmaps helper Vladimir Sementsov-Ogievskiy
2020-05-14 18:30   ` Eric Blake
2019-12-19  8:51 ` [PATCH v2 4/5] migration/block-dirty-bitmap: fix bitmaps migration during mirror job Vladimir Sementsov-Ogievskiy
2020-05-14 18:52   ` Eric Blake
2019-12-19  8:51 ` [PATCH v2 5/5] iotests: 194: test also migration of dirty bitmap Vladimir Sementsov-Ogievskiy
2019-12-19 10:36 ` [PATCH v2 0/5] fix migration with bitmaps and mirror Peter Krempa
2019-12-19 11:39   ` Vladimir Sementsov-Ogievskiy
2020-04-03 11:02   ` Vladimir Sementsov-Ogievskiy [this message]
2020-04-03 11:23     ` Peter Krempa
2020-04-03 11:29       ` Vladimir Sementsov-Ogievskiy
2020-04-03 11:52         ` Vladimir Sementsov-Ogievskiy
2020-04-03 15:05           ` Dr. David Alan Gilbert
2020-04-03 15:34             ` Vladimir Sementsov-Ogievskiy
2020-05-14 18:29       ` Eric Blake
2020-05-15  5:52         ` Vladimir Sementsov-Ogievskiy
2020-05-15 11:15           ` Vladimir Sementsov-Ogievskiy
2020-05-15 17:51             ` Eric Blake
2020-05-15 19:49               ` Vladimir Sementsov-Ogievskiy
2020-01-20  9:04 ` Vladimir Sementsov-Ogievskiy

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=a5015250-46f4-c6ed-92b9-779f885e8a4a@virtuozzo.com \
    --to=vsementsov@virtuozzo.com \
    --cc=den@openvz.org \
    --cc=dgilbert@redhat.com \
    --cc=fam@euphon.net \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=pkrempa@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=stefanha@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).