Browse Prior Art Database

CMS: Business Process App, Detects Resource/Guest OS State, Prior to Moving onto Next Activity

IP.com Disclosure Number: IPCOM000244799D
Publication Date: 2016-Jan-15
Document File: 4 page(s) / 76K

Publishing Venue

The IP.com Prior Art Database

Abstract

When a VM goes into a deploy flow, the cloud provider type (vCenter, OpenStack, System Center) commonly asserts the VM state has been started and is ready to resume injection of managed services agents and registering to backend servers. On numerous occasions, the existing tool owns detection fails to accurately predict when a fully returned state and is ready to resume.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 01 of 4

CMS: Business Process App, Detects Resource/Guest OS State, Prior to Moving onto Next Activity

Synchronization Points for Virtual Machine Deployment Orchestration

Introduction


While Virtual Machine Hypervisors give the ability to create, modify, and destroy Virtual Machines, it requires the requester to know the state of the Virtual Machine. Some Hypervisor tasks will return when they have completed, but that doesn't mean that the Virtual Machine is in the desired state for a subsequent operation. Others just indicate that the request has been submitted. So it's up to the user or the software interacting with the Hypervisor to insure that the Virtual Machine is in the desired state. This invention will consider different Hypervisor operations and what information is used to provide the synchronization.

Deployment Orchestration


This could be an open ended sequence, i.e. contain a non-definite number of steps after the actual virtual machine deployment. For this document, virtual machine deployment includes any customization the hypervisor performs as part of deployment. When this step is done, the virtual machine has a running OS installed and any needed devices, such as network adapters, are configured. Also the virtual machine is powered up so that any customization could complete. It is the assumption that some of the remaining steps will need to communicate with the OS possibly to install software or do configuration changes that were not included in the customization provided by the hypervisor.

To proceed to any of those steps the software must determine if the virtual machine is in the correct state. That would mean the virtual machine is powered on, connected to the network and is able to respond to remote requests, but also that there are no pending restarts. The invention needs to provide an indication as to when the virtual machine is in such a state and do it in such a manner that it is sure that its in the final state and not some intermediate state. For example, when a server is deployed and customized, it may reboot several times, so the invention needs to provide the indication at the end of that sequence, without any real details about the sequence. The invention doesn't want any dependence on the number of reboots that happen before it's at that final state, since that might change later. The data that the invention monitors is currently specific to VMware vSph...