Hello, we are using oVirt on a production system with a three node hyperconverged-cluster based on GlusterFS with a 10Gbit storage backbone network. Everything runs smooth except OVA exports. Each node has a NFS mount mounted on /data/ova with custom mount option "soft". The NFS server used is a plain vanilla CentOS7 host with /etc/exports containing a line /data/ova *(rw,all_squash,anonuid=36,anongid=36) When exporting VM's as OVA using the engine web gui, the export is terribly slow (~4MiB/s), it succeeds for small disks (up to 20GB), exporting larger disks fails with a timeout. The network link between oVirt-nodes and NFS server is 1Gbit. I have done a little testing and looked at the code in /usr/share/ovirt-engine/playbooks/roles/ovirt-ova-pack/files/pack_ova.py. It seems, the export is done by setting up a loop device /dev/loopX on the exporting node linked to a freshly generated sparse file /data/ova/{vmname}.tmp on the NFS share and then exporting the disk using qemu-img with target /dev/loopX. Using iotop on the node doing the export I can see write rates ranging from 2-5 Mib/s on the /dev/loopX device. When copying to the NFS share /data/ova using dd or qemu-img *directly* (that is using /data/ova/test.img instead of the loop device as target) I am getting write rates of ~100MiB/s which is the expected performance of the NFS servers underlying harddisk-system and the network connection. It seems that the loop device is the bottleneck. So far I have been playing with NFS mount options and the options passed to qemu-img in /usr/share/ovirt-engine/playbooks/roles/ovirt-ova-pack/files/pack_ova.py without any success. Any ideas or anyone with similar problems ? 😊 -- juergen walch