Bug 1833376

Summary: Hardcoded VMware-vix-disklib version 6 - import fail with version 7
Product: Container Native Virtualization (CNV) Reporter: Robert Bohne <rbohne>
Component: V2VAssignee: Tomáš Golembiovský <tgolembi>
Status: CLOSED ERRATA QA Contact: Ilanit Stein <istein>
Severity: high Docs Contact:
Priority: high    
Version: 2.3.0CC: bthurber, cnv-qe-bugs, dagur, fdupont, istein, ptoscano, rjones, tgolembi
Target Milestone: ---Flags: bthurber: needinfo-
bthurber: needinfo-
Target Release: 2.4.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: kubevirt-v2v-conversion-container-v2.4.0-11 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-07-28 19:10:05 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1831969, 1847304    
Bug Blocks:    
Attachments:
Description Flags
Screenshot of the error none

Description Robert Bohne 2020-05-08 14:29:45 UTC
Created attachment 1686492 [details]
Screenshot of the error

Description of problem:

If you build a VDDK image with version VMware-vix-disklib-7* the import will fail because it can not find libvixDiskLib.so.6 (Screenshot attached)

Version-Release number of selected component (if applicable): OCP 4.4 & CNV 2.3

I recommend searching for "libvixDiskLib.so" because:

$ tar -tvf VMware-vix-disklib-7.0.0-15832853.x86_64.tar.gz |grep libvixDiskLib.so
lrwxrwxrwx  0 mts    mts         0 Mar 14 10:14 vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.7 -> libvixDiskLib.so.7.0.0
lrwxrwxrwx  0 mts    mts         0 Mar 14 10:14 vmware-vix-disklib-distrib/lib64/libvixDiskLib.so -> libvixDiskLib.so.7
-rwxrwxr-x  0 mts    mts   2674672 Mar 14 10:11 vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.7.0.0

tar -tvf VMware-vix-disklib-6.7.3-14389676.x86_64.tar.gz |grep libvixDiskLib.so
lrwxrwxrwx  0 root   root        0 Aug 13  2019 vmware-vix-disklib-distrib/lib64/libvixDiskLib.so -> libvixDiskLib.so.6
-rw-r--r--  0 root   root  2595040 Aug 13  2019 vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.6.7.0
lrwxrwxrwx  0 root   root        0 Aug 13  2019 vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.6 -> libvixDiskLib.so.6.7.0

I don't know if it is the right place: https://github.com/oVirt/v2v-conversion-host/blob/master/kubevirt-conversion/entrypoint#L18


How reproducible:

Create a VDDK image with version VMware-vix-disklib-7*  and run the v2v migration.

Steps to Reproduce:
1.
2.
3.

Actual results:

Can not find libvixDiskLib.so.6

Expected results:

Find the right lib.

Additional info:

Comment 3 Brett Thurber 2020-05-11 03:12:05 UTC
Duplicate of this BZ:  https://bugzilla.redhat.com/show_bug.cgi?id=1831969

Comment 4 Robert Bohne 2020-05-11 05:03:49 UTC
(In reply to Brett Thurber from comment #1)
> This looks like a similar issue when using NFS storage class with the
> conversion POD.  Can you confirm?

we don't have NFS storage, we only have local storage. [1]

[1] https://docs.openshift.com/container-platform/4.4/cnv/cnv_virtual_machines/cnv_virtual_disks/cnv-configuring-local-storage-for-vms.html




(In reply to Brett Thurber from comment #3)
> Duplicate of this BZ:  https://bugzilla.redhat.com/show_bug.cgi?id=1831969

It looks similar but is not the containerize version of the v2v migration tool.

Comment 5 Brett Thurber 2020-05-11 05:05:54 UTC
(In reply to Robert Bohne from comment #4)
> (In reply to Brett Thurber from comment #1)
> > This looks like a similar issue when using NFS storage class with the
> > conversion POD.  Can you confirm?
> 
> we don't have NFS storage, we only have local storage. [1]
> 
> [1]
> https://docs.openshift.com/container-platform/4.4/cnv/cnv_virtual_machines/
> cnv_virtual_disks/cnv-configuring-local-storage-for-vms.html
> 
> 
> 
> 
> (In reply to Brett Thurber from comment #3)
> > Duplicate of this BZ:  https://bugzilla.redhat.com/show_bug.cgi?id=1831969
> 
> It looks similar but is not the containerize version of the v2v migration
> tool.

It's the same issue as the same underlying tool is being used to convert the VM disk via vddk, virt-v2v.

Comment 6 Richard W.M. Jones 2020-05-11 09:33:57 UTC
As Brett says it's a duplicate of bug 1831969.  Already fixed upstream
and the fix is due in RHEL AV 8.2.1 (the build is already available in
brew if you want to try it out).

Comment 7 Robert Bohne 2020-05-11 09:37:57 UTC
I can not, because I'm running the migration with the CNV wizard [1]. I provide a VDDK image and CNV is looking for libvixDiskLib.so.6 (checkout screenshot). INMHO because of [2]

[1] https://docs.openshift.com/container-platform/4.4/cnv/cnv_virtual_machines/cnv_importing_vms/cnv-importing-vmware-vm.html
[2] https://github.com/oVirt/v2v-conversion-host/blob/master/kubevirt-conversion/entrypoint#L18

Comment 8 Robert Bohne 2020-05-11 09:39:09 UTC
Of course, Work-a-round is to build the VDDK image with Version 6. I'm doing this, but this is a) not mention and the documentation b) not very handy for the future.

Comment 9 Richard W.M. Jones 2020-05-11 11:01:10 UTC
We talked about this on the team call last week and I think the decision was
to document this, until RHEL AV 8.2.1 is released.  Adding Fabien.

Comment 10 Tomáš Golembiovský 2020-05-11 15:57:08 UTC
This bug is different from the virt-v2v bug and is valid. There is hardcoded check for VDDK 6.x in the container entrypoint.

Comment 12 Ilanit Stein 2020-06-09 06:29:03 UTC
Tomas,

Can you please add verification steps?

Thanks.

Comment 13 Tomáš Golembiovský 2020-06-11 13:35:14 UTC
Verification steps:

1. download VDDK library version 7.x from VMware
2. create VDDK container image with the library downloaded in step 1
3. update CNV configmap to use the newly created image
4. run a conversion and check if it finishes OK

Comment 17 Ilanit Stein 2020-06-25 16:39:20 UTC
VMware to CNV VM import, using vddk version 7 worked just fine.
Tested on CNV-2.4 latest as of June 24 2020.

Comment 20 errata-xmlrpc 2020-07-28 19:10:05 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2020:3194