Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1884256

Summary:	If a source VM is inaccessible during migration, the migration plan displays an appropriate error message
Product:	Migration Toolkit for Virtualization	Reporter:	Ilanit Stein <istein>
Component:	General	Assignee:	Fabien Dupont <fdupont>
Status:	CLOSED ERRATA	QA Contact:	Maayan Hadasi <mguetta>
Severity:	medium	Docs Contact:	Avital Pinnick <apinnick>
Priority:	medium
Version:	2.0.0	CC:	amastbau, aos-bugs, apinnick, cnv-qe-bugs, fdupont, fkrepins, istein, jortel, tjelinek
Target Milestone:	---
Target Release:	2.0.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:	1884250	Environment:
Last Closed:	2021-06-10 17:11:26 UTC	Type:	---
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:
Bug Blocks:	1884250

Description Ilanit Stein 2020-10-01 13:08:31 UTC

This bug is for the back end to provide information on VMs being "inaccessible",
that the bellow UI bug can be implemented.

+++ This bug was initially created as a clone of Bug #1884250 +++

Description of problem:
On OCP-4.6, VMware inaccessible VMs listed in VM import wizard in UI, are not mentioned as such.
Please either display they are inaccessible, or remove them all together from the VMs to import list.   

Version-Release number of selected component (if applicable):
OCP-4.6/CNV-2.5

--- Additional comment from Ilanit Stein on 2020-10-01 12:55:27 UTC ---



--- Additional comment from Ilanit Stein on 2020-10-01 12:56:15 UTC ---

Comment 1 Filip Krepinsky 2020-10-01 13:18:24 UTC

The CR should mimic the behaviour of vCenter as mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1884250 and flag or remove the VMs.

Comment 2 Fabien Dupont 2020-10-07 07:02:23 UTC

The first thing to do is to identify how to retrieve this attribute.

@Jeff, I've added you to this BZ because that's an attribute we'll want in the MTV Inventory too.

Comment 3 Fabien Dupont 2021-04-19 19:18:46 UTC

We will deprecate the VM import feature starting with CNV 4.8. We will implement this feature in MTV 2.0.0.

Comment 4 Fabien Dupont 2021-05-03 12:09:00 UTC

The fix should be part of build mtv-operator-bundle-container-2.0.0-4 / iib:72115.

Comment 5 Maayan Hadasi 2021-05-11 08:01:54 UTC

@istein @fdupont 

I am not sure how to cause a VMware VM to be "inaccessible" (i.e. to see 'inaccessible' next to the VM's name)
I followed this article: https://kb.vmware.com/s/article/1003742 that says:
In vCenter Server, an "orphaned" virtual machine is one that exists in the vCenter Server database but is no longer present in ESX host inventory. An "invalid" virtual machine is a VM that is inaccessible because the ESXi host is offline or inaccessible, the VM configuration file is locked or corrupt or contains a bad option, or other possible causes.

And tried those scenarios:
1. Removed the VMware VM's .vmx file (perhaps I removed some other files) -> the VM became "orphaned"
2. Moved a VMware VM to datastore that is exposed to ESXi host -> powered off that host -> datastore became "inaccessible", the VM became "disconnected"

In both cases I could see the related VM in VMs selection in plan creation wizard,
mtv-operator-bundle-container-2.0.0-12


Moving the issue back to ASSIGNED

Comment 6 Maayan Hadasi 2021-05-11 08:38:30 UTC

(In reply to Maayan Hadasi from comment #5)

> ...
> 
> And tried those scenarios:
> 1. Removed the VMware VM's .vmx file (perhaps I removed some other files) ->
> the VM became "orphaned"
> 2. Moved a VMware VM to datastore that is exposed to ESXi host -> powered off that host -> datastore became "inaccessible", the VM became "disconnected"
I realized that the datastore here (scenario 2) is locally, not shared storage, so it makes sense that it became "inaccessible"

Comment 7 Fabien Dupont 2021-05-11 10:18:20 UTC

What has been decided is not to hide the VMs in the plan selection list, but to fail the VM with a clear error message when the plan is executed.

The reason is that a VM can be inaccessible when the plan is created due to a transient issue, and that the issue is solved when the plan is started.
And again, the fact that a plan fails is not a big issue, since it can be restarted. It is just incomplete on the first pass.

How to test this:

1. Put a VM in disconnected state
2. Create a plan with the disconnected VM
3. Start the plan
4. The VM should fail and the error message should tell that the VM is disconnected.


Moving back to ON_QA.

Comment 8 Maayan Hadasi 2021-05-11 10:30:42 UTC

Thank you so much for the clarification @fdupont 

So in both cases described in comment #5 the migration plan fail with this error as expected:
VM id:vm-2545 name:'mguetta-bug' is not connected

Verified as fixed.
mtv-operator-bundle-container-2.0.0-12

Comment 11 errata-xmlrpc 2021-06-10 17:11:26 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 (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