Sections in italics are optional.
Cross Project Spec - None
User Story Tracker - None
You have a number of physical hosts and virtual Machines in your infrastructure you would like to manage with OpenStack
- Interrogate the hypervisor to obtain a list of all Virtual Machines running in that host
- For each storage device attached to the host, obtain a list of all volumes associated with each VM
- For each VM, obtain a list of all network interface addresses for each VM
Enterprises with extensive legacy applications environments would like to consolidate management of those environments through OpenStack. Due to the nature of the applications and their value to the business, the onboarding process needs to be non-disruptive and suitable for use at scale.
The Onboarding capability should work with any virtualization technology that provides OpenStack APIs to manage the virtual machine configuration
The ability to onboard legacy environments is widely desired by any business that is currently has a legacy IT environment and is using OpenStack to manage new applications.
Support for onboarding legacy environments in a non-disruptive manner will greatly increase the adoption of OpenStack.
Managing existing Virtual Machines
a. For each physical host in a legacy virtualized server environment, Obtain a list of all resources (Compute, Memory, Block storage and Network) for each Virtual Machine b. Create database entries for each virtual machine in the Virtual Machine OpenStack so that each of the legacy VMs are managed though OpenStack services such as Horizon, Nova, Cinder, Neutron.
1. Onboarding must be non-disruptive to legacy environments such that the applications, virtual machines and physical hosts should not need to be restarted 2. OpenStack needs to at least tolerate Virtual Machine resource configuration changes made by non-OpenStack management tools after the VM has been onboarded into OpenStack. The eventual goal is for full synchronization between all resource management tools
Three phases of synchronization related to onboarding are: Phase 1 - No synchronization - The move to OpenStack management is one way only. No out of band/non-OpenStack management will be accommodated by OpenStack. Example: Nova would delete a VM that was migrated by a control mechanism outside of OpenStack,
Phase 2 - OpenStack toleration. Management actions initiated outside of OpenStack would be tolerated and the OpenStack database would reflect the changes in resources. Example, in the case of a live migration, OpenStack would accept that the VM had been moved to a different physical host
Similar accommodation needed for changes to storage volumes outside of Cinder and networking changes outside of Neutron
Phase 3 - Full synchronization - This would allow multiple management control points to take action against managed resources and have the changes reflected in all resource managers. Most important for VMware environments.
Example: Self service provisioning initiated in OpenStack Horizon would result in the new VMs also showing up in vCenter
None.
None.
Hosts Physical systems that contain a hypervisor allowing for multiple virtual machines to run
VM Virtual Machines, each with their unique operating system, processor, storage and network resources