Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1448913

Summary:	import kvm libvirt failure on buffer size mismatch (when working against an old libvirt)
Product:	[oVirt] ovirt-engine	Reporter:	Ross <bugzilla>
Component:	General	Assignee:	Tomáš Golembiovský <tgolembi>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Nisim Simsolo <nsimsolo>
Severity:	low	Docs Contact:
Priority:	low
Version:	4.1.1.6	CC:	bugs, bugzilla, nsimsolo, tjelinek
Target Milestone:	ovirt-4.2.0	Flags:	rule-engine: ovirt-4.2+
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-02-22 09:58:45 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Virt	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Ross 2017-05-08 15:47:43 UTC

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.

Comment 1 Tomas Jelinek 2017-05-10 13:40:15 UTC

what is the version of the libvirt it happens on? We have tried the ones from RHEL6 and 7 and it worked well.

Comment 2 Ross 2017-05-11 20:20:41 UTC

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.

Comment 3 Tomas Jelinek 2017-05-12 06:12:32 UTC

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.

Comment 4 Ross 2017-05-13 17:06:31 UTC

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.

Comment 5 Nisim Simsolo 2018-02-18 09:40:06 UTC

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.

Comment 6 Sandro Bonazzola 2018-02-22 09:58:45 UTC

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.