Richard W.M. Jones
2022-Jan-09 18:51 UTC
[Libguestfs] Virt-v2v performance benchmarking part 3
Part 1: https://listman.redhat.com/archives/libguestfs/2022-January/msg00055.html Part 2: https://listman.redhat.com/archives/libguestfs/2022-January/msg00057.html This is part 3 of my performance analysis of virt-v2v over the last year. In this email I cover conversion from VMware to a local disk using VDDK. This is a more realistic test than doing local disk to local disk conversions. As you can see from the new chart in the attached file [LibreOffice Calc format] modular virt-v2v has got a little faster over all, with conversion taking slightly longer and copying being slightly faster. If you expand the hidden columns (between columns F & M) you will also see clearly the new flushing behaviour of nbdcopy, where it always flushes the output to disk, versus "qemu-img convert" which used the page cache (notice the Sync times in column L). This can make old virt-v2v appear to be much faster, but the appearance is not real. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html -------------- next part -------------- A non-text attachment was scrubbed... Name: results.ods Type: application/vnd.oasis.opendocument.spreadsheet Size: 38949 bytes Desc: not available URL: <http://listman.redhat.com/archives/libguestfs/attachments/20220109/848dbd04/attachment.ods>
Richard W.M. Jones
2022-Jan-09 19:19 UTC
[Libguestfs] Virt-v2v performance benchmarking part 3
On Sun, Jan 09, 2022 at 06:51:42PM +0000, Richard W.M. Jones wrote:> > Part 1: > https://listman.redhat.com/archives/libguestfs/2022-January/msg00055.html > Part 2: > https://listman.redhat.com/archives/libguestfs/2022-January/msg00057.html > > This is part 3 of my performance analysis of virt-v2v over the last > year. In this email I cover conversion from VMware to a local disk > using VDDK. This is a more realistic test than doing local disk to > local disk conversions. > > As you can see from the new chart in the attached file [LibreOffice > Calc format] modular virt-v2v has got a little faster over all, with > conversion taking slightly longer and copying being slightly faster. > > If you expand the hidden columns (between columns F & M) you will also > see clearly the new flushing behaviour of nbdcopy, where it always > flushes the output to disk, versus "qemu-img convert" which used the > page cache (notice the Sync times in column L). This can make old > virt-v2v appear to be much faster, but the appearance is not real.I meant to record the virt-v2v command I used, which was: $ virt-v2v -ic 'esx://root at example.com/?no_verify=1' \ -it vddk \ -io vddk-libdir=vddk-7.0.0/vmware-vix-disklib-distrib \ -io vddk-thumbprint=<thumbprint> \ -ip /tmp/vmware-passwd \ 'Fedora 35 standard test' -o local -os /var/tmp The version of VDDK was 7.0.0 in all tests. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW
On 01/09/22 19:51, Richard W.M. Jones wrote:> > Part 1: > https://listman.redhat.com/archives/libguestfs/2022-January/msg00055.html > Part 2: > https://listman.redhat.com/archives/libguestfs/2022-January/msg00057.html > > This is part 3 of my performance analysis of virt-v2v over the last > year. In this email I cover conversion from VMware to a local disk > using VDDK. This is a more realistic test than doing local disk to > local disk conversions. > > As you can see from the new chart in the attached file [LibreOffice > Calc format] modular virt-v2v has got a little faster over all, with > conversion taking slightly longer and copying being slightly faster. > > If you expand the hidden columns (between columns F & M) you will also > see clearly the new flushing behaviour of nbdcopy, where it always > flushes the output to disk, versus "qemu-img convert" which used the > page cache (notice the Sync times in column L). This can make old > virt-v2v appear to be much faster, but the appearance is not real.So this confirms that there is no performance regression in the "VMware to a local disk using VDDK" conversion case -- this is the result we've been looking for, right? Thanks, Laszlo