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 <[email protected]> > 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 _______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
