Shelly, could you please take a look? Is it something we have in 4.10?

I asked for more information from Ilanit, it needs further investigation

Checked on OCP-4.9.12/CNV-4.9.2-27/MTV-2.2 GA

1. A suitable storage cannot be found 
DV:
message: PVC rhv-no-storage-961ffd10-1b15-47e2-8fb8-d03b8555aa9d-45w5v Pending
reason: Pending

MTV Migration UI show Disk Transfer in state 'pending'

  vms:
  - id: 961ffd10-1b15-47e2-8fb8-d03b8555aa9d
    name: v2v-rhel8
    phase: CopyDisks
    pipeline:
    - completed: 2022-01-27T10:40:49Z
      description: Initialize migration.
      name: Initialize
      progress:
        completed: 1
        total: 1
      started: 2022-01-27T10:40:00Z
    - annotations:
        unit: MB
      description: Transfer disks.
      name: DiskTransfer
      phase: Pending
      progress:
        completed: 0
        total: 102400
      reason: Pending
      tasks:
      - annotations:
          unit: MB
        name: 8028ba4a-2d6d-4e05-85c7-782e7cf3d241

    
2. VDDK init image is not configured:
DV:
message: waiting for v2v-vmware configmap for VDDK image
reason: AwaitingVDDK

MTV Migration UI show Disk Transfer in state 'pending'

  vms:
  - id: vm-689
    name: mini-rhel7-istein
    phase: CopyDisks
    pipeline:
    - completed: 2022-01-27T10:29:11Z
      description: Initialize migration.
      name: Initialize
      progress:
        completed: 1
        total: 1
      started: 2022-01-27T10:28:32Z
    - annotations:
        unit: MB
      description: Transfer disks.
      name: DiskTransfer
      phase: Pending
      progress:
        completed: 0
        total: 10240
      reason: AwaitingVDDK
      tasks:
      - annotations:
          unit: MB
        name: '[rhv-v2v-performance-testing] mini-rhel7-istein/mini-rhel7-istein_2.vmdk'
        phase: Pending
        progress:
          completed: 0
          total: 10240
        reason: AwaitingVDDK
    - description: Convert image to kubevirt.
      name: ImageConversion
      progress:
        completed: 0
        total: 1
    restorePowerState: "Off"
    started: 2022-01-27T10:28:32Z


Seems there are 2 problems:
1. MTV propagates reason and not message field.
2. The messages are not detailed enough/not accurate:
   A. The message for no storage doesn't detail the problem - in this case no PV in 
      correct size
   B. I think the message for VDDK should change but I am not sure exactly to what. 
      v2v-vmware config map was used in the past. in CNV-4.9 we add it in 
      kubevirt-hyperconverged hco. 
      Not sure for CNV-4.10 what should be the correct message.

Matthew/Sam,
Would you please address these problems?

Yes, the VDDK message should change. I don't think upstream CDI can assume the presence of HCO or MTV, so I don't think the message can be detailed enough to be passed straight through to the MTV UI. There is a per-DataVolume initImageURL spec field for VDDK imports now, maybe it would be better to mention that instead of v2v-vmware or kubevirt-hyperconverged.

I'm not so sure what to do about the message for when there's no available PVs though.

It looks like there may be a bug in that reasons/phases are not always cleared, so at times the wrong message appears. Also, when there are no available PVs, unfortunately both the phase and reason on the DV are reported by CDI as "Pending". However, it seems that CDI puts more detailed information in a "message" field on the DV condition, and we could have MTV report that in the status alongside the phase and reason. For the AwaitingVDDK case, we can report our own more detailed message in place of the "v2v-vmware configmap" message from CDI.

So I want to understand:
1) for the VDDK there is nothing that can be done in CDI.
2) MTV needs to take the `message` field from the DV alongside the reason.
3)for the size case you do believe it is something that should be changed in CDI?
did I get it right? If so, maybe for (1),(2) a new BZ should be opened?

Thank you Matthew, Sam, and Shelly for your replies.

Moving this bug to MTV product to propagate the Data volume 'message' content to Migration/plan CR and migration UI.

Tested on MTV-2.3.0-37:

1. A suitable storage cannot be found 
Migration from VMware to NFS of a VM with a disk larger than available PVs  

Result:

In UI:

Transfer disk state field show:
"Pending - Pending; PVC istein1-vm-35010-gwd4k Pending"
See "pending_storage_screenshot" attached

Message in the DV:
message: PVC istein1-vm-35010-gwd4k Pending

plan yaml:
 reason: Pending; PVC istein1-vm-35010-gwd4k Pending

2. VDDK init image is not configured:
As in MTV-2.3 there was a change of moving the VDDK init image to MTV: Add provider,
and it is an obligatory field I could not create the scenario of having it not configured.
What I did instead was setting a wrong value for it. That resulted a different CDI importer response - The impoter pod was in PodInitializing state,
and that state is also propagated to MTV Migration UI
See "wrong_vddk_screenshot" attached

There is no "message" field in the DV.

=====================

Mike,

Regarding scenario #1,
there seem to be a duplication of the status displayed in the UI, repeating twice at the beginning:
"Pending - Pending; PVC istein1-vm-35010-gwd4k Pending"

Sam,

Regarding scenario #2,
Is there a way we can reflect to the user vddk init image URL is wrong?
I understand that this can't be validated when adding vddk init image in UI, but maybe at a later stage it can be spotted and reported?

> Regarding scenario #1,
> there seem to be a duplication of the status displayed in the UI, repeating twice at the beginning:
> "Pending - Pending; PVC istein1-vm-35010-gwd4k Pending"

For each pipeline step, the UI renders both the `phase` and `reason` properties of the step, joined by a dash. So in this case the step object contains a `phase` of "Pending" and a `reason` of `Pending; PVC istein1-vm-35010-gwd4k Pending`. This could be corrected on the backend by removing that first Pending from the `reason` field.

I can't really fix that message on the backend in a general way. The DataVolume reports a phase, a reason, and an extended message elaborating on the reason. The controller simplifies the latter two into one field called `reason` that contains the short reason and the message. In this case, the phase, reason, and message all include the word "pending". If it were Pending for a different reason, like in the case of the VDDK image being missing, we'd see something like the reason field containing "AwaitingVDDK; <message about why it's waiting>".

MTV does not really have any way to know if the image URL the user provided is correct or not. It's getting that message about the importer pod from the DataVolume's status, and if the DataVolume doesn't recognize it as an error state then MTV can't do much about it.

I could add some UI logic to check if the reason string starts with the same characters as the phase string, and if so, exclude the phase?

Thanks Sam, Mike,
I think we'll leave it as is for now.

On mtv-2.3.0-37:

"1. A suitable storage cannot be found" case:
 was tested and now the DV message is propagated to MTV UI 

"2. VDDK init image is not configured" case:
On MTV-2.3 It is not possible to reach to the "AwaitingVDDK reason.
Not even when the provider, plan and migration CRs are added from CLI.
Therefore it is not possible to check the DV message 
("message: waiting for v2v-vmware configmap for VDDK image" in this case) is propagated to MTV. 


Based on the above moving bug to VERIFIED.

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 (MTV 2.3.0 images), 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-2022:1183