Thanks Peter, that’s what I figured that the actual copy is done by the qemu process.

The copy job is setup by openstack volume migration and translate into

</mirror>

From what I observed the issue is more noticeable when I see more fdatasync calls during the copy but I haven’t been able to correlate that to the issue 100% yet

Thanks

Bjoern

From: Peter Krempa <pkrempa@redhat.com>
Date: Tuesday, April 19, 2022 at 6:20 AM
To: Bjoern Teipel <bjoern.teipel@RACKSPACE.COM>
Cc: libvirt-users@redhat.com <libvirt-users@redhat.com>
Subject: Re: Virtio-scsi and block mirroring

CAUTION: This message originated externally, please use caution when clicking on links or opening attachments!

On Thu, Apr 14, 2022 at 16:36:38 +0000, Bjoern Teipel wrote:
> Hello everyone,

Hi,

>
> I’m looking at an issue where I do see guests freezing (Dl) process state during a block disk mirror from one storage to another storage (NFS) where the network stack of the guest can freeze for up to 10 seconds.
> Looking at the storage and IO I noticed good throughput ad low latency <3ms and I am having trouble to track down the source for the issue, as neither storage nor networking show issues. Interestingly when I do the same test with virtio-blk I do not really see the process freezes at the frequency or duration compared to virtio-scsi which seem to indicate a client side rather than storage side problem.

Hmm, this is really weird if the difference is in the guest-facing
device frontend.

Since libvirt is merely setting up the block job for the copy and the
copy itself is handled by qemu I suggest you contact the
qemu-block@nongnu.org mailing list.

Unfortunately you didn't provide any information on the disk
configuration (the VM XML) or how you start the blockjob, which I could
translate for you into qemu specifics. If you provide such information I
can do that to ensure that the qemu folks have all the relevant
information.