Hi, Thank you for getting back to me.
Yes, I have opened the ticket https://urldefense.com/v3/__https://gitlab.com/qemu-project/qemu/-/issues/2482__;!!GjvTz_vk!SCg-a5LiuAGlWyQ6Opd9urNAW4_Z-tUtzPZARWB1d3Ulg_ws87yL3iJcxuZPktLeHNNtPztJTJZNJdE$ <https://urldefense.com/v3/__https://gitlab.com/qemu-project/qemu/-/issues/2482__;!!GjvTz_vk!SCg-a5LiuAGlWyQ6Opd9urNAW4_Z-tUtzPZARWB1d3Ulg_ws87yL3iJcxuZPktLeHNNtPztJTJZNJdE$> > 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. Yes, this is the problem I have. RAM migration state is already moved to pre-switchover and mirror block job is moved to "READY" state assuming that there are no more dirty blocks. But there are still dirty blocks and these dirty block blocks are being transferred to destination host. I've created a small patch(attached) in mirror.c to put the mirror job back into the "RUNNING" state if there are any dirty pages. But I still would like to prevent RAM migration state to be moved to pre-switchover when there are dirty blocks. > 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. Thanks for the pointer, I've looked at this part (block-job-cancel). The problem is that QEMU on the source host is still transferring the dirty blocks. That is the reason I am trying to avoid moving RAM migration state to pre-switchover when there are any dirty pages. is there a way in QEMU to know if the disk transfer is completed and stop dirty pages being transferred? Thanks Chakri On 8/21/24, 6:56 AM, "Fabiano Rosas" <faro...@suse.de <mailto:faro...@suse.de>> wrote: !-------------------------------------------------------------------| This Message Is From an External Sender This message came from outside your organization. |-------------------------------------------------------------------! "Arisetty, Chakri" <caris...@akamai.com <mailto:caris...@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://urldefense.com/v3/__https://gitlab.com/qemu-project/qemu/-/issues/2482__;!!GjvTz_vk!SCg-a5LiuAGlWyQ6Opd9urNAW4_Z-tUtzPZARWB1d3Ulg_ws87yL3iJcxuZPktLeHNNtPztJTJZNJdE$ <https://urldefense.com/v3/__https://gitlab.com/qemu-project/qemu/-/issues/2482__;!!GjvTz_vk!SCg-a5LiuAGlWyQ6Opd9urNAW4_Z-tUtzPZARWB1d3Ulg_ws87yL3iJcxuZPktLeHNNtPztJTJZNJdE$> 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.
qemu-block-job-running.patch
Description: qemu-block-job-running.patch
