On Thu, Jan 25, 2018 at 10:53:28AM +0100, Luca 'remix_tj' Lorenzetto wrote:
On Thu, Jan 25, 2018 at 10:08 AM, Richard W.M. Jones <rjones@redhat.com> wrote:
There's got to be some difference between your staging environment and your production environment, and I'm pretty sure it has nothing to do with the version of oVirt.
Are you running virt-v2v inside a virtual machine, and previously you ran it on bare-metal? Or did you disable nested KVM? That seems like the most likely explanation for the difference (although I'm surprised that the difference is so large).
Rich.
Hello Rich,
i'm running virt-v2v throught the import option of oVirt.
Unfortunately the ‘-i vmx’ method is not yet supported when using the oVirt UI. However it will work from the command line[0] if you just upgrade virt-v2v using the RHEL 7.5 preview repo I linked to before. ‘-i vmx’ will be by far the fastest way to transfer guests available currently, (unless you want to get into VDDK which currently requires a lot of fiddly setup[1]).
[root@kvm01 ~]# rpm -qa virt-v2v virt-v2v-1.36.3-6.el7_4.3.x86_64 [root@kvm01 ~]# rpm -qa libguestfs libguestfs-1.36.3-6.el7_4.3.x86_64 [root@kvm01 ~]# rpm -qa "redhat-virtualization-host-image-update*" redhat-virtualization-host-image-update-placeholder-4.1-8.1.el7.noarch redhat-virtualization-host-image-update-4.1-20171207.0.el7_4.noarch
(yes, i'm running RHV, but i think this shouldn't change the behaviour)
I don't set anything in the commandline or whatever, i set only the source and destination throught the API. So virt-v2v is coordinated via vdsm and runs on the bare-metal host.
The network distance is "0", because vcenter, source vmware hosts, kvm hosts and ovirt hosts lies in the same network. The only annotation is that also vCenter is a VM, running on esx environment.
Network interfaces both on source and destination are 10Gbit, but there may be a little slowdown on vcenter side because has to get the data from esx's datastore and forward to the ovirt host.
I don't know why it slowed down, but I'm pretty sure it's got nothing to do with the version of oVirt/RHV. Especially in the initial phase where it's virt-v2v reading the guest from vCenter. Something must have changed or be different in the test and production environments. Are you converting the same guests? virt-v2v is data-driven, so different guests require different operations, and those can take different amount of time to run. Rich. [0] http://libguestfs.org/virt-v2v.1.html#input-from-vmware-vmx [1] http://libguestfs.org/virt-v2v.1.html#input-from-vddk -- 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