Bug 1306119

Summary: Add a section for Archive, Orphaned, and Disconnected VM status
Product: Red Hat CloudForms Management Engine Reporter: Shikha <snansi>
Component: DocumentationAssignee: Red Hat CloudForms Documentation <cloudforms-docs>
Status: CLOSED WONTFIX QA Contact: Red Hat CloudForms Documentation <cloudforms-docs>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 5.5.0CC: adahms, jhardy, mfeifer, obarenbo, pmukhedk
Target Milestone: GA   
Target Release: cfme-future   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: doc
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-10-08 23:42:09 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:
Bug Depends On: 499109, 1301560    
Bug Blocks:    

Description Shikha 2016-02-10 04:35:25 UTC
Document URL: https://access.redhat.com/documentation/en/red-hat-cloudforms/version-4.0/provisioning-virtual-machines-and-hosts/

Section Number and Name: 

Describe the issue: 
Add a section for Archive, Orphaned, and Disconnected VM status, similar to Chapter 6 Retirement: https://access.redhat.com/documentation/en/red-hat-cloudforms/version-4.0/provisioning-virtual-machines-and-hosts/#retirement

Suggestions for improvement: 
1) More explanation for the VM statuses
2) Explanation for associated CFME procedures
3) Explain the difference between the statuses 

Regards,
Shikha

Comment 2 Shikha 2016-02-18 14:31:46 UTC
Hi Prasad,
Thanks for your offer to help. A little background of the problem is that while working on this bug -https://bugzilla.redhat.com/show_bug.cgi?id=1301560, we came across this issue that customers want a better understanding of VM statuses. ATM, we have only covered Retirement in our CFME documents:
https://access.redhat.com/documentation/en/red-hat-cloudforms/version-4.0/provisioning-virtual-machines-and-hosts/#retirement

As a part of this bug resolution, I offered to create new sections explaining the other VM statuses, Archiving, Orphaned, and Disconnected.
https://bugzilla.redhat.com/show_bug.cgi?id=1306119

I do not have the required setup to find out the procedures associated with these statuses, or what all would a user want to do for obtaining/changing the VM status to Archive, Orphaned, or Disconnected.

So far, I have collected the following information regarding these statuses:

Archive: An archived virtual machine has no host or datastore associated with it. Archiving is done to move virtual machines to a low-cost storage, either on demand or during retirement, if requested, to avoid incurring extra cost on a virtualized infrastructure due to virtual machine sprawl.

Archive Setup:

● Archive\retrieve by VM button
● Check current datastore and archive\retrieve if not on desired datastore
● Desired datastore determined through tagging as 'low cost' or 'normal'
● Initiate VMware Storage vMotion if necessary
● Monitor task using check_task state
● Notify user via email during processing
● Tag as archive\d once complete
● During retirement, archive if VM tagged as 'archive on retire enabled'

Questions:
1) I could not test any of the above processes on my instance 10.65.15.143.
2) What Archive operations are done in CFME?
3) Can we schedule an Archive request through Automate?
4) Any other Archive customization function/procedure.

Orphaned:  An orphaned virtual machine has no host but has a datastore associated with it. Orphaned virtual machines are those that have been removed from their providers but still exists on the storage. An orphan virtual machine is not able to identify the associated host. A virtual machine also shows as orphaned if it exists on a different host than the host expected by the provider’s server.

An Orphaned virtual machine can be created:
* If you delete the virtual machine's configuration file through provider's Server Console.
* If the virtual machine migrating function is under extreme stress while doing a live migration of a running virtual machine's file system from one storage system to another.
* In some cases after migration is executed to balance computing workloads with available resources in a virtualized environment.
* If a host failure occurs, or after the host comes out of maintenance mode.
* If a virtual machine is deleted outside of provider's Server.
* If the provider's Server is restarted while a migration is in progress.
* If too many virtual machines are scheduled to be relocated at the same time.
* If an attempt is made to delete virtual machines when a host local disk (particularly the root partition) has become full.
* If the host is rebooted within 1 hour of moving or powering on virtual machines.
* If the host configuration file contains special characters or incomplete line item entries.
* If all invalid virtual machines are reloaded on a single host at one time.

Resolving an Orphaned Virtual Machine using the Host Console:

● Login to the host and try to find the virtual machine status from the console by getting a list of all the virtual machines currently running on the host.
● Status request for an Orphaned machine will generate a "No such virtual machine".
● If Orphaned virtual machine is not found, unregister and then re-register the virtual machine from the provider's console.

Resolving an Orphaned Virtual Machine through the configuration file:

● From the host console, right click on the orphaned virtual machine and select ‘Remove from Inventory’.
● Select the correct datastore from the provider's summary page.
● Browse the datastore form the configuration file of the VM.
● Locate the configuration file.
● Right click on the virtual machine's configuration file and choose ‘Add to Inventory’.
● Orphaned Virtual Machine should appear online again.


Questions:
1) I could not test any of the above processes on my instance 10.65.15.143.
2) Are these the only two operations done on an orphaned machine?
3) Any other Orphaned customization function/procedure.

Disconnected: A disconnected virtual machine is one that has lost connection to either the provider’s storage, host, or both. A disconnect is usually a result of network issues on the provider side. For instance, if during virtual machine provisioning the storage is not set up or deleted, the virtual machine will still exist on the provider, but will not run on the host as it has lost connection to its provider’s storage.

Questions:
1) I could not test disconnect on my instance 10.65.15.143.
2) How is disconnect dealt with in CFME?
3) Any other Disconnect related CFME customization function/procedure.

I am sorry for the lengthy email. Any insight would be appreciated. Thank again for your help.

Regards,
Shikha Nansi

Comment 5 Lucy Bopf 2016-05-26 02:40:54 UTC
Moving to NEW to be reviewed as the schedule allows.

Comment 6 Andrew Dahms 2018-10-08 23:42:09 UTC
Thank you for raising this bug.

We have evaluated this request, and while we recognize that it is a valid request for the documentation, we do not expect this to be implemented in the product in the foreseeable future. We are therefore closing this out as WONTFIX. 

If you have any concerns about this, please feel free to contact Andrew Dahms.