Bug 1756328 - 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: Container Native Virtualization (CNV)
Classification: Red Hat
Component: V2V
Version: 2.1.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 2.2.0
Assignee: Marek Libra
QA Contact: Igor Braginsky
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-09-27 12:03 UTC by Tomas Jelinek
Modified: 2020-01-30 16:27 UTC (History)
6 users (show)

Fixed In Version: 4.2.0-0.nightly-2019-11-27-102509
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1762217 (view as bug list)
Environment:
Last Closed: 2020-01-30 16:27:15 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2020:0307 0 None None None 2020-01-30 16:27:26 UTC

Description Tomas Jelinek 2019-09-27 12:03:13 UTC
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

Comment 1 Tomáš Golembiovský 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.

Comment 2 Marek Libra 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 3 Brett Thurber 2019-10-21 13:40:20 UTC
PR merged and tested here:  https://github.com/kubevirt/web-ui-components/pull/565

Comment 4 Daniel Gur 2019-11-05 10:49:25 UTC
If it merged it has to move to "Modified,
And then I think it should automatically move to ON-QE once the target DS build  (2.1.1) is delivered to QE. 
Once we get the build with the fix will validate it.

Comment 5 Tomas Jelinek 2019-11-26 10:47:22 UTC
This was actually supposed to be moved to on_qa. Fixing it now

Comment 6 Nelly Credi 2019-12-02 11:16:30 UTC
please add 'fixed in version'

Comment 7 Marek Libra 2019-12-03 08:13:01 UTC
Merged Nov 21st to openshift/console 4.2 branch, so 4.2.0-0.nightly-2019-11-27-102509 build should contain.

Comment 8 Ilanit Stein 2019-12-12 10:40:56 UTC
Verified on Openshift 4.3/CNV 2.2.0-10:
With configmap set with volumeMode: Block (see configmap below),
managed to run Import VM several times successfully.

$ oc edit configmap kubevirt-storage-class-defaults -n openshift-cnv
apiVersion: v1
data:
  accessMode: ReadWriteMany
  local-sc.accessMode: ReadWriteOnce
  local-sc.volumeMode: Filesystem
  volumeMode: Block   <==== Block is configured
kind: ConfigMap
metadata:
  creationTimestamp: "2019-12-11T09:38:44Z"
  labels:
    app: hyperconverged-cluster
  name: kubevirt-storage-class-defaults
  namespace: openshift-cnv
  ownerReferences:
  - apiVersion: hco.kubevirt.io/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: HyperConverged
    name: hyperconverged-cluster
    uid: cd3e3687-6fdc-4526-851f-d1a5f696ddbf
  resourceVersion: "6085748"
  selfLink: /api/v1/namespaces/openshift-cnv/configmaps/kubevirt-storage-class-defaults
  uid: 0343c289-61d5-4d58-a334-630a26f11a16

Comment 10 errata-xmlrpc 2020-01-30 16:27:15 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/RHEA-2020:0307


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