Description of problem: When doing an import of a vm via the UI of "kvm (via libvirt)", ovirt calls kvm2ovirt.py to do the disk copy which has a default buffersize of 1048676 bytes. If this buffersize is larger than the one defined on the remote/source libvirt configuration, then the import will fail with the following libvirt error in /var/log/vdsm/import/import-#UUID#.log file: "size > maximum buffer size" Version-Release number of selected component (if applicable): tested against: ovirt engine v4.1.1.6 How reproducible: consistent with legacy libvirt source systems. Additional info/Possible Fix: kvm2ovirt.py has a mechanism for specifying a different buffer size upon execution already (which works correctly). Adding an option to the ovirt engine UI upon import to specify/change this option allows for on-the-fly fixing of this issue when dealing with legacy kvm/ovirt imports. Jury rig test of this fix was to redefine bufsize in "/usr/lib/python2.7/site-packages/vdsm/kvm2ovirt.py" line 79: "default=1048676" to a smaller value eg: "default=65535". Note that smaller buffer size means slower imports.
what is the version of the libvirt it happens on? We have tried the ones from RHEL6 and 7 and it worked well.
Mine was an old (0.8.3) libvirt system, but from the following details, it would be nice to be able to scale up to larger sizes with current versions of libvirt. Details from: https://libvirt.org/html/libvirt-libvirt-domain.html ... virDomainBlockPeek ... NB. The remote driver imposes a 64K byte limit on 'size'. For your program to be able to work reliably over a remote connection you should split large requests to <= 65536 bytes. However, with 0.9.13 this RPC limit has been raised to 1M byte. Starting with version 1.0.6 the RPC limit has been raised again. Now large requests up to 16M byte are supported.
hmmm, that sounds good actually. But I don't think we want to expose this kinds of low level stuff in the UI nor I think that guesstimating the size according to the version of libvirt is worth doing - a simple vdsm.conf property + a documentation should do. Targeting this to 4.2, mostly because the import can fail as the original report says with a side effect that the import performance can be tweaked this way.
I concur with doing a vdsm.conf property/doco instead of a UI change - I was only suggesting a way of being able to set the buffersize variable (and documenting the problem if someone else came across it). This is a fairly rare situation (having to make a smaller size) only found when dealing with importing from a legacy system. A vdsm.conf property would make future version changes (to larger 1M+ buffers) also easier or for those sites with the hardware bandwidth available to use imports from recent versions.
Verified: rhvm-4.2.2-0.1.el7 vdsm-4.20.18-1.el7ev.x86_64 qemu-kvm-rhev-2.9.0-16.el7_4.14.x86_64 libvirt-client-3.2.0-14.el7_4.9.x86_64 sanlock-3.5.0-1.el7.x86_64 Verification test case added to external trackers.
This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017. Since the problem described in this bug report should be resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.