<div dir="ltr">Originally this was being performed and tested without compression, both live and cold seem to be the same speed, around ~1.2gbps<div><br></div><div>No explicit restrictions on the core switch, same data center, same switch.<div><br></div><div>Running twin 10gb Intel X710's on Dell R630 equipment, SSD's, pretty nice rigs.</div><div><br></div><div>Whether using scp or iperf I can make ~9.6gbps </div><div><br></div><div>I mean I can work around it offline with manual chunks, it would just be really cool to do live migration at those speeds for these mammoth guest volumes.  </div></div><div><br></div><div>As you said there's something in the mix with QEMU - I guess we will wait and see, I'm glad someone's working on it.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 9, 2018 at 4:49 AM, Daniel P. Berrangé <span dir="ltr"><<a href="mailto:berrange@redhat.com" target="_blank">berrange@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, May 07, 2018 at 11:55:14AM -0400, Shawn Q wrote:<br>
> Hi folk, we are using 10gb NICs with multithreaded compression.<br>
> <br>
> We're finding that the standard `virsh migrate` gets at most ~1.2gbps,<br>
> similar to a single scp session.<br>
<br>
</span>Hmm, I didn't actively measure the throughput when I tested, but looking<br>
at the results and trying to infer bandwidth, I'm fairly sure I saw in<br>
excess of 1.2gbps. With scp I would expect transfer rate to be limited<br>
by the speed your CPUS can perform AES encryption.<br>
<br>
Your migration command is just transferring plaintext so should not be<br>
limited in that way and should thus get better results. I wonder if<br>
the compression code is harming you because that burns massive amounts<br>
of CPU time, often for minimal compression benefit.<br>
<span class=""><br>
> When we do a multipart upload with multiple scp connections we can squeeze<br>
> as high as 9.6gbps.<br>
> <br>
> Is there was a way to get `virsh migrate` to perform multiple connections<br>
> as well when transferring?<br>
<br>
</span>There is work underway in QEMU to add this feature, but it will be a<br>
while before it is ready.<br>
<span class=""><br>
> Would be useful to be able to migrate big guests using the full capacity of<br>
> the 10gb nics.<br>
> <br>
> Our example command to migrate:<br>
> <br>
> # virsh migrate --compressed --comp-methods mt --comp-mt-level 9<br>
> --comp-mt-threads 16 --comp-mt-dthreads 16 --verbose --live<br>
> --copy-storage-all --undefinesource --unsafe --persistent<br>
> <a href="http://dev-testvm790.mydomain.net" rel="noreferrer" target="_blank">dev-testvm790.mydomain.net</a> qemu+tcp://<a href="http://myhost-10g.mydomain.net/system" rel="noreferrer" target="_blank">myhost-10g.<wbr>mydomain.net/system</a><br>
<br>
</span>I would caution that the compression code should not be assumed to be<br>
beneficial. When I tested compression against extreme guest workloads,<br>
it was actually harmful[1] - it burns a lot of CPU time, which takes<br>
significant time away from the guest OS vCPUs, while not getting very<br>
good compression.<br>
<br>
If you have trouble with migration not completing, the best advice<br>
at this time is to use the post-copy migration method. This will<br>
guarantee that migration can complete in finite time, while having<br>
the lower impact on guest vCPUs, assuming you let it run pre-copy<br>
to copy bulk of RAM, before flipping to post-copy.<br>
<br>
Regards,<br>
Daniel<br>
<br>
[1] <a href="https://www.berrange.com/posts/2016/05/12/analysis-of-techniques-for-ensuring-migration-completion-with-kvm/" rel="noreferrer" target="_blank">https://www.berrange.com/<wbr>posts/2016/05/12/analysis-of-<wbr>techniques-for-ensuring-<wbr>migration-completion-with-kvm/</a><br>
<span class="HOEnZb"><font color="#888888">-- <br>
|: <a href="https://berrange.com" rel="noreferrer" target="_blank">https://berrange.com</a>      -o-    <a href="https://www.flickr.com/photos/dberrange" rel="noreferrer" target="_blank">https://www.flickr.com/photos/<wbr>dberrange</a> :|<br>
|: <a href="https://libvirt.org" rel="noreferrer" target="_blank">https://libvirt.org</a>         -o-            <a href="https://fstop138.berrange.com" rel="noreferrer" target="_blank">https://fstop138.berrange.com</a> :|<br>
|: <a href="https://entangle-photo.org" rel="noreferrer" target="_blank">https://entangle-photo.org</a>    -o-    <a href="https://www.instagram.com/dberrange" rel="noreferrer" target="_blank">https://www.instagram.com/<wbr>dberrange</a> :|<br>
</font></span></blockquote></div><br></div>