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 ---
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.
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.
We will deprecate the VM import feature starting with CNV 4.8. We will implement this feature in MTV 2.0.0.
The fix should be part of build mtv-operator-bundle-container-2.0.0-4 / iib:72115.
@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
(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"
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.
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
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