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.
next prev parent 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).