Hi,

it took some time to answer due to some other stuff, but now I had the
time to look into it.

Am 21.08.2018 um 17:02 schrieb Michal Skrivanek:
> [...]
>> Hi Bernhard,
>>
>> With the latest version of the ovirt-imageio and the v2v we are
>> performing quite nicely, and without specifying
>
> the difference is that with the integrated v2v you don’t use any of
> that. It’s going through the vCenter server which is the major slowdown.
> With 10MB/s I do not expect the bottleneck is on our side in any way.
> After all the integrated v2v is writing locally directly to the target
> prepared volume so it’s probably even faster than imageio.
>
> the “new” virt-v2v -o rhv-upload method is not integrated in GUI, but
> supports VDDK and SSH methods of access which both should be faster
> you could try to use that, but you’d need to use it on cmdline
I first tried the ssh way which already improved the speed. Afterwards I
did some more experiments and ended up using vmfs-tools to mount the
vmware datastore directly and I see transfer speeds of ~50-60MB/sec when
transferring to an ovirt-export domain now. This seems to be the maximum
the used system can handle when using the fuse-vmfs-way. That would be
fast enough in my case (and is a huge improvement).

However I cannot use the rhv-upload method because my storage domain is
iSCSI and I get the error that sparse filetypes are not allowed (like
being described at https://bugzilla.redhat.com/show_bug.cgi?id=1600547
). The solution from the Bug does also not help, because then instantly
I get the error message that I'd need to use -oa sparse when using
rhv-upload. This happens with the development version 1.39.9 of
libguestfs and with the git master branch. Do you have some advice how
to fix this / which version to use?

   Regards
     Bernhard

> https://github.com/oVirt/ovirt-ansible-v2v-conversion-host/ might help
> to use it a bit more nicely
>
> Thanks,
> michal
>
>> number I can tell you that weakest link is the read rate from the
>> vmware data store. In our lab
>> I can say that we roughly peek ~40 MiB/sec reading a single vm and the
>> rest of our components(after the read from vmds)
>> have no problem dealing with that - i.e buffering -> converting ->
>> writing to imageio -> writing to storage
>>
>> So, in short, examine the read-rate from vm datastore, let us know,
>> and please specify the versions you are using.
>>
>>     _______________________________________________
>>     Users mailing list -- users@ovirt.org <mailto:users@ovirt.org>
>>     To unsubscribe send an email to users-leave@ovirt.org
>>     <mailto:users-leave@ovirt.org>
>>     Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>>     oVirt Code of Conduct:
>>     https://www.ovirt.org/community/about/community-guidelines/
>>     List Archives:
>>     https://lists.ovirt.org/archives/list/users@ovirt.org/message/KQZPRX4M7V74FSYIY5LRUPC46CCJ2DCR/
>>
>> _______________________________________________
>> Users mailing list -- users@ovirt.org <mailto:users@ovirt.org>
>> To unsubscribe send an email to users-leave@ovirt.org
>> <mailto:users-leave@ovirt.org>
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives:
>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/WYKFJPEIPGVUT7Q6TMRVLYRAFQVWBQTI/
>


--
Dipl.-Inf. Bernhard Dick
Auf dem Anger 24
DE-46485 Wesel
www.BernhardDick.de

jabber: bernhard@jabber.bdick.de

Tel : +49.2812068620
Mobil : +49.1747607927
FAX : +49.2812068621
USt-IdNr.: DE274728845
_______________________________________________
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-leave@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/
List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/CSIMWXZL744WEMIBPRWNZHLQLYCYCMHZ/