Bug 1902742

This bug bug seem to be related to bug 1891440.

Is the same behavior observed when creating a VMImport directly?

Created attachment 1749366 [details]
migration.yaml

This bug was reported for CNV-2.5.

Testing it on CNV-2.6.0/HCO-502:

1. VM import in such a flow fail now on:

Import error (VMware)
v2v-rh8-2disks2nics could not be imported.
VMCreationFailed: Error while creating virtual machine openshift-migration/v2v-rh8-2disks2nics: admission webhook "virtualmachine-validator.kubevirt.io" denied the request: more than one interface is connected to a pod network in spec.template.spec.interfaces

2. Running it by MTV plan, cause VM import fail the same, but when checking the migration plan it is displayed as failed, with an option to Restart, but There is no error message saying why it failed.

Main problem here is that the VM import error is not propagated to the migration plan UI.

Attaching the MTV migration/plan CRs

Created attachment 1749367 [details]
plan.yaml

Based on comment #4 moving bug to MTV, to handle the VM import error propagation to MTV migration ui.

@Ilanit,

Can you provide an MTV installation with a plan in this state that I can inspect?

It is expected that error details wouldn't be on the plans page (the same place where the Restart button is), you have to click through to the VM migration details for that plan to see errors on a per-VM level. Are the error still not appearing at that level either?

I have reproducer env that I can share.

Looking inside the VM in the migration plan - The error is indeed displayed.
However it is displayed as such that failed the conversion stage, while the conversion stage was never reached.
See "Migration plan/VM failure" screenshot attached.
The VM import failed immediately - see "vm import failure" screenshot attached.
The importer and v2v pods were not run.

@istein I'm not seeing an attached screenshot, but I believe you :)

If an error is being reported at the wrong pipeline step, that's a controller issue. The UI simply displays whatever pipeline status the API provides. cc @jortel

Created attachment 1754819 [details]
vm import failure

Created attachment 1754820 [details]
Migration plan/VM failure

Thanks for the screenshots Ilanit.

@Jeff if you look at that screenshot "Migration plan/VM failure", is that error appearing on the wrong pipeline step or is it working as intended?

(In reply to Mike Turley from comment #12)
> Thanks for the screenshots Ilanit.
> 
> @Jeff if you look at that screenshot "Migration plan/VM failure", is that
> error appearing on the wrong pipeline step or is it working as intended?

Based on the screenshot, the error is reported against the image-conversion step which seems correct to me.

@Jeff,

In "Migration plan/VM failure" attachment we see failure is displayed in the conversion step.
However, the import fails even before the "importer" & " conversion" stages.
If we would have an "init" stage displayed within migration ui, it would have belonged there.
Do we have plans to add it for GA?

After discussing this with Fabien Dupont, it seems that it actually failed at the importer stage, and not in "initial" stage.
vmio reported wrongly the stage was "conversion", while the actual stage was "disk copy" (importer). 
Need to report a separate vmio bug for this.


This bug is actually on that the error is not being displayed in the migration UI - and that part works OK on latest MTV migration ui. Therefore closing on not a bug.

This indeed happens at the "CreateImport" stage, even before the DiskTransfer stage that is shown in the UI.

Here, the VMImport CR is rejected by the admission webhook, so the error should be "Could initiate VM import process", or similar.

@jortel, would it be possible to add a "Initialize" (or other name) stage for whatever is done before the VMImport CR is created and retrieved by the Migration CR ?

(In reply to Fabien Dupont from comment #16)
> This indeed happens at the "CreateImport" stage, even before the
> DiskTransfer stage that is shown in the UI.
> 
> Here, the VMImport CR is rejected by the admission webhook, so the error
> should be "Could initiate VM import process", or similar.
> 
> @jortel, would it be possible to add a "Initialize" (or other
> name) stage for whatever is done before the VMImport CR is created and
> retrieved by the Migration CR ?

Depends. 
If we plan to absorb the VMIO functionality into MTV for GA then the failure will be dealt with and reported naturally.
If not, Yes, we could add a step in the pipeline to align/report this failure.

Even if we absorb VMIO functionality, I think it makes sense to have a first stage for initialization/validation. The controller will always have to do something before triggering data transfer and that would allow reporting errors that happen in the very early times of the migration.

Seems like this particular bug: the v2v-rh8-2disks2nics image is not in the registry on the destination cluster) should be caught and reported during provider validation.  I propose we add a validation/condition of the Provider CR that checks that the image is available.
As for the new initialization/validation step in the pipeline for each VM, it's not clear to me what this step would provide beyond the contextual validations we discussed but cannot remember ATM.  Not opposed to adding the step but would to do it in the context of a specific use case that I think is separate from this BZ.

*** Bug 1902028 has been marked as a duplicate of this bug. ***

I agree with Jeff. For this specific error, the message should now be correctly displayed.

For the additional "validation" step, we'll track the implementation in BZ 1902028.

Moving to ON_QA.

MTV 2.0.0-20 (iib:69034)

HCO image: registry.redhat.io/container-native-virtualization/hyperconverged-cluster-operator@sha256:79bb6a11201f2b867b7a928220dfe628ad28acd2e70fe35933dbe115f8ce1b23
HCO operator version: v2.6.2-1
HCO index image: registry-proxy.engineering.redhat.com/rh-osbs/iib:67945
CNV version: 2.6.2
CSV creation time: 2021-04-17 03:38:06
KubeVirt: v0.36.2-22-g95642d8
CDI: v1.28.3-18-g2acbfb2
OpenShift: 4.7.7
OCS: 4.7.0-353.ci
OpenShift networkType: OpenShiftSDN

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.0.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-2021:2381