qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Fabiano Rosas <farosas@suse.de>
To: "Arisetty, Chakri" <carisett@akamai.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"qemu-block@nongnu.org" <qemu-block@nongnu.org>
Cc: "Peter Xu <peterx@redhat.com>"@imap1.dmz-prg2.suse.org,
	"Kevin Wolf <kwolf@redhat.com>"@imap1.dmz-prg2.suse.org,
	"Eric  Blake <eblake@redhat.com>"@imap1.dmz-prg2.suse.org
Subject: Re: Issue with QEMU Live Migration
Date: Wed, 21 Aug 2024 10:56:38 -0300	[thread overview]
Message-ID: <874j7e0yjt.fsf@suse.de> (raw)
In-Reply-To: <1ABDAA2B-8582-4B98-81D3-8F71DE62718C@akamai.com>

"Arisetty, Chakri" <carisett@akamai.com> writes:

> Hello,
>
> I’m having trouble with live migration and I’m using QEMU 7.2.0 on Debian 11.
>
> Migration state switches to pre-switchover state during the RAM migration.
>
> My assumption is that disks are already migrated and there are no further dirty pages to be transferred from source host to destination host. Therefore, NBD client on the source host closes the connection to the NBD server on the destination host. But we observe that there are still some dirty pages being transferred.
> Closing prematurely NBD connection results in BLOCK JOB error.
> In the RAM migration code (migration/migration.c), I’d like to check for block mirror job’s status before RAM migration state is moved to pre-switchover. I’m unable to find any block job related code in RAM migration code.
>
> Could someone help me figuring out what might be going wrong or suggest any troubleshooting steps or advice to get around the issue?
>
> Thanks
> Chakri

Hi, I believe it was you who opened this bug as well? 

https://gitlab.com/qemu-project/qemu/-/issues/2482

So the core of the issue here is that the block job is transitioning to
ready while the migration is still ongoing so there's still dirtying
happening.

Have you looked at the documentation at
docs/interop/live-block-operations.rst? Section "QMP invocation for live
storage migration with ``drive-mirror`` + NBD", point 4 says that a
block-job-cancel should be issues after BLOCK_JOB_READY is
reached. Although there is mention of when the migration should be
performed.


  reply	other threads:[~2024-08-21 13:57 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-21 13:32 Issue with QEMU Live Migration Arisetty, Chakri
2024-08-21 13:56 ` Fabiano Rosas [this message]
2024-08-21 16:55   ` Arisetty, Chakri
2024-08-22 13:47     ` Fabiano Rosas
2024-08-23 13:30       ` Arisetty, Chakri
2024-08-23 13:41         ` Arisetty, Chakri
2024-08-23 14:42           ` Fabiano Rosas
2024-08-25 17:09             ` Arisetty, Chakri
2024-08-26 12:04               ` Prasad Pandit
2024-08-26 19:05                 ` Arisetty, Chakri

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=874j7e0yjt.fsf@suse.de \
    --to=farosas@suse.de \
    --cc="Eric  Blake <eblake@redhat.com>"@imap1.dmz-prg2.suse.org \
    --cc="Kevin Wolf <kwolf@redhat.com>"@imap1.dmz-prg2.suse.org \
    --cc="Peter Xu <peterx@redhat.com>"@imap1.dmz-prg2.suse.org \
    --cc=carisett@akamai.com \
    --cc=qemu-block@nongnu.org \
    --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).