Bug 1762217 - the conversion pod does not start with blockMode PVCs
Summary: the conversion pod does not start with blockMode PVCs
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Console Kubevirt Plugin
Version: 4.2.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 4.3.0
Assignee: Marek Libra
QA Contact: Nelly Credi
URL:
Whiteboard:
Depends On:
Blocks: 1762218
TreeView+ depends on / blocked
 
Reported: 2019-10-16 08:49 UTC by Tomas Jelinek
Modified: 2020-01-23 11:08 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: The kubevirt-storage-class-defaults ConfigMaps setting is not reflected for VMware imports Consequence: blockMode PVC can not be used for VMware VM import Fix: Fixed, the storage class defaults are used when requesting for VMware imported disks Result:
Clone Of: 1756328
: 1762218 (view as bug list)
Environment:
Last Closed: 2020-01-23 11:07:48 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift console pull 2991 0 'None' closed Bug 1762217: Bump kubevirt-web-ui-components v0.1.48 2020-03-01 02:16:16 UTC
Red Hat Product Errata RHBA-2020:0062 0 None None None 2020-01-23 11:08:15 UTC

Description Tomas Jelinek 2019-10-16 08:49:50 UTC
+++ This bug was initially created as a clone of Bug #1756328 +++

How reproducible:
100%

Steps to Reproduce:
1. Have a kubevirt-storage-class-defaults config map which contains "volumeMode: Block" configured for a storage class X
2. Go to the new VM dialog and try to import a VM
3. In the storage section, pick X as a storage class for any or all of the disks
4. Submit the dialog

Actual results:
The conversion pod will never start because it fails to mount the PVCs

Expected results:
The conversion succeeds

Additional info:
The problem is, that if the volume mode is Block, pvc should be mounted using volumeDevices and not volumeMounts

--- Additional comment from Tomáš Golembiovský on 2019-10-10 13:41:59 UTC ---

I have modified entrypoint script to handle the block devices. The change is here:

    https://github.com/oVirt/v2v-conversion-host/commit/cfe8e00f9d6005b6e19aac67be4c50b3d38724fe

It requires corresponding change in the pod definition where the disks should be removed from `volumeMounts` section and included in `volumeDevices` section like this:

      volumeDevices:
        - name: hdd1
          devicePath: /dev/v2v-disk1

The device path is important and must conform to the name /dev/v2v-diskX where X is a number. This is how the entrypoint will find them during execution.

--- Additional comment from Marek Libra on 2019-10-11 12:54:08 UTC ---

UI patch: https://github.com/kubevirt/web-ui-components/pull/557

Configuration of the temporary disk still needs to be resolved, discussion in progress within the PR.

Comment 1 Marek Libra 2019-10-18 07:11:48 UTC
Patch for temporary disk: https://github.com/kubevirt/web-ui-components/pull/561

Comment 3 Radim Hrazdil 2019-10-18 10:22:41 UTC
Verified that with the fix included from https://github.com/kubevirt/web-ui-components/pull/561, the conversion pod disk has correct accessMode RWO and volumeMode Filesystem and successfully binds using rook-ceph storage class.
The VM import started as expected.

Comment 6 errata-xmlrpc 2020-01-23 11:07:48 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/RHBA-2020:0062


Note You need to log in before you can comment on or make changes to this bug.