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(a)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