Bug 1982595
Summary: | Web console does not display new RHV VM in inventory | ||
---|---|---|---|
Product: | Migration Toolkit for Virtualization | Reporter: | Tzahi Ashkenazi <tashkena> |
Component: | Inventory | Assignee: | Jeff Ortel <jortel> |
Status: | CLOSED ERRATA | QA Contact: | Ilanit Stein <istein> |
Severity: | urgent | Docs Contact: | Avital Pinnick <apinnick> |
Priority: | high | ||
Version: | 2.1.0 | CC: | ahadas, fdupont, jortel |
Target Milestone: | --- | ||
Target Release: | 2.1.0 | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2021-08-26 07:09:25 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Tzahi Ashkenazi
2021-07-15 08:55:36 UTC
The root cause is a difference in events reported by different RHV instances. ENG mostly tests with: https://rhvm.v2v.bos.redhat.com/ which reports a created VM as USER_ADD_VM=34 and the VM add is properly handled and reflected in the inventory. However, the RHV instance https://rhev-red-01.rdu2.scalelab.redhat.com/ reports as: USER_ADD_VM_STARTED=37 which is not processed and results in the VM creation being missed and subsequent configuration events failing. There can be 3 events when a VM is created successfully in RHV: USER_ADD_VM(34) USER_ADD_VM_STARTED(37) USER_ADD_VM_FINISHED_SUCCESS(53) And there are two flows. (A) With asynchronous tasks: 1. First, USER_ADD_VM_STARTED is generated 2. When the async tasks are completed successfully, USER_ADD_VM_FINISHED_SUCCESS is generated (B) Without asynchronous tasks there is a single event of USER_ADD_VM. This flow depends on creation flow - if the VM is created without disks then there's no asynchronous tasks whereas when the vm is created with disks (i.e., from a template that contains disks or from the blank template and the add request asks to provision disks) there are asynchronous tasks. MTV should monitor both USER_ADD_VM and USER_ADD_VM_FINISHED_SUCCESS as an indication that a VM was added to cover both flows. (In reply to Jeff Ortel from comment #1) > ENG mostly tests with: https://rhvm.v2v.bos.redhat.com/ which reports a > created VM as USER_ADD_VM=34 and the VM add is properly handled and > reflected in the inventory. However, the RHV instance > https://rhev-red-01.rdu2.scalelab.redhat.com/ reports as: > USER_ADD_VM_STARTED=37 which is not processed and results in the VM creation > being missed and subsequent configuration events failing. OK, I have permissions to access those environments so I took a look: In rhvm.v2v.bos.redhat.com the blank template is "optimized" for Desktop which means the disks are thin-provisioned and if the add-vm request doesn't include disks, there would be no async task and USER_ADD_VM is generated. In rhev-red-01.rdu2.scalelab.redhat.com the blank template is "optimized" for Server which means the disks are cloned and no matter if add-vm request includes disks or not, the USER_ADD_VM_STARTED would be generated and followed by USER_ADD_VM_FINISHED_SUCCESS. But again, if MTV would treat USER_ADD_VM and USER_ADD_VM_FINISHED_SUCCESS the same way, that would cover all cases - also of different disk allocations. @Jeff, Could you please move this bug to MODIFIED? verified on cloud38 with MTV31 new VM name - > new-vm-test-mtv-31 on > L0_Group_0 on a new plan the new VM appears on the select VMs section as expected 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 (Migration Toolkit for Virtualization 2.1.0), 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:3278 |