From: Wei Wang <wei.w.wang@intel.com>
To: Quentin Grolleau <quentin.grolleau@ovhcloud.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
samuel.ortiz@intel.com
Subject: Re: [raw] Guest stuck during live live-migration
Date: Tue, 15 Dec 2020 09:46:35 +0800 [thread overview]
Message-ID: <5FD8157B.7030202@intel.com> (raw)
In-Reply-To: <e6f25c7e67ce4cfea5e01e4e46f0a3d8@ovhcloud.com>
On 11/23/2020 05:36 PM, Quentin Grolleau wrote:
> Hello,
>
> In our company, we are hosting a large number of Vm, hosted behind
> Openstack (so libvirt/qemu).
> A large majority of our Vms are runnign with local data only, stored
> on NVME, and most of them are RAW disks.
>
> With Qemu 4.0(can be even with older version)we see strange
> live-migrationcomportement:
> - some Vms live migrate at very high speed without issue (> 6 Gbps)
> - some Vms are running correctly, but migrating at a strange low
> speed (3Gbps)
> - some Vms are migrating at a very low speed (1Gbps, sometime
> less) and during the migration the guest is completely I/O stuck
> When this issue happen the VM is completly block, iostat in the Vm
> show us a latency of 30 secs
>
> First we thought it was related to an hardware issuewe check it, we
> comparing different hardware, but no issue where found there
>
> So one of my colleague had the idea to limit with "tc" the bandwidth
> on the interface the migration was done, and it worked the VM didn't
> lose any ping nor being I/O stuck
> Important point : Once the Vm have been migrate (with the limitation )
> one time, if we migrate it again right after, the migration will be
> done at full speed (8-9Gb/s) without freezing the Vm
>
> It only happen on existing VM, we tried to replicate with a fresh
> instance with exactly the same spec and nothing was happening
>
> We tried to replicate the workload inside the VM but there was no way
> to replicate the case. So it was not related to the workload nor to
> the server that hosts the Vm
>
> So we thought about the disk of the instance : the raw file.
>
> We also tried to strace -c the process during the live-migration and
> it was doing a lot of "lseek"
>
> and we found this :
> https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg00462.html
>
>
> So i rebuilt Qemu with this patch and the live-migration went well, at
> high speedand with no VM freeze
> ( https://github.com/qemu/qemu/blob/master/block/file-posix.c#L2601)
>
> Do you have a way to avoid the "lseek" mechanism as it consumes more
> resources to find the holes in the disk and don't let any for the VM ?
>
>
> Server hosting the VM :
> - Bi-Xeon hosts With NVME storage and 10 Go Network card
> - Qemu 4.0 And Libvirt 5.4
> - Kernel 4.18.0.25
>
> Guest having the issue :
> - raw image with Debian 8
>
> Here the qemu img on the disk :
> > qemu-img info disk
> image: disk
> file format: raw
> virtual size: 400G (429496729600 bytes)
> disk size: 400G
>
Could you share the migration options that you use and "info migrate"
for both stuck and non-stuck cases?
Best,
Wei
prev parent reply other threads:[~2020-12-15 1:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-23 9:36 [raw] Guest stuck during live live-migration Quentin Grolleau
2020-11-23 12:25 ` Kevin Wolf
2020-11-24 12:58 ` Quentin Grolleau
2020-12-02 15:09 ` Quentin Grolleau
2020-12-02 15:33 ` Kevin Wolf
2021-01-18 15:35 ` Alexandre Arents
2020-12-15 1:46 ` Wei Wang [this message]
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=5FD8157B.7030202@intel.com \
--to=wei.w.wang@intel.com \
--cc=qemu-devel@nongnu.org \
--cc=quentin.grolleau@ovhcloud.com \
--cc=samuel.ortiz@intel.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).