Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 1474992 - Failed VMs are not rolling back end-to-end
Failed VMs are not rolling back end-to-end
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Automate (Show other bugs)
Unspecified Unspecified
high Severity high
: GA
: cfme-future
Assigned To: Tina Fitzgerald
Dave Johnson
Depends On:
  Show dependency treegraph
Reported: 2017-07-25 15:17 EDT by Saif Ali
Modified: 2017-12-05 10:10 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-09-27 10:00:53 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: CFME Core

Attachments (Terms of Use)

  None (edit)
Description Saif Ali 2017-07-25 15:17:02 EDT
Description of problem:
Cloudforms is not rolling back the VM end-to-end. Particularly, it’s not deleting it from vCenter & VMDB.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:

Actual results:

Expected results:

Additional info:
Comment 3 Greg McCullough 2017-07-26 11:42:57 EDT
VMs created outside of the ManageIQ Lifecycle provisioning will not have the MIQ GUID property nor will they have a "miq_provision" which is what we check in the default remove_from_provider method in automate.


My guess is that the VM is not really being created through the ManageIQ provisioning task.  

Can you describe how the VM is being provisioned as well as what is being used to verify that the VM was provisioned by a ManageIQ provision task?

As the above method shows you can also create the tag "lifecycle/retire_full" and apply that to the VM to have it removed from the provider.
Comment 10 Greg McCullough 2017-08-14 13:36:34 EDT
The screenshots are showing that we are passing the expected VM notes value to VMware during provisioning.

Was the customer able to confirm that the VM was created with that note?  Also, is there any other process that might be updating/replacing the notes on a VM within their VMware environment.

Can they track a VM that we have provisioned and compare the notes we pass (based on the provision logging) and what is on the VM when the process fails?

I would also highly suggest reviewing the last comment in https://bugzilla.redhat.com/show_bug.cgi?id=1474992#c6 and possibly changing their process to use the miq_provision relationship instead of the notes value.
Comment 12 Tina Fitzgerald 2017-09-26 17:01:17 EDT
Hi Saif,

Can we close this ticket?  There hasn't been any customer response in over a month.


Note You need to log in before you can comment on or make changes to this bug.