Onboarding Hosts and VMs into OpenStack for Management

Sections in italics are optional.

Problem description

You have a number of physical hosts and virtual Machines in your infrastructure you would like to manage with OpenStack

  • For each host that you wish to manage:
  • 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
  • The Onboarding process must be non-disruptive to the operation of the

    host and the virtual machines running on the host

User Stories

  • As the Enterprise IT manager that is deploying an OpenStack cloud

    alongside my existing infrastructure, I need manage existing virtual machines compute resources with OpenStack without disrupting or changing the virtual machines

  • As the Enterprise IT manager that is deploying an OpenStack cloud

    alongside my existing infrastructure, I need to manage the block storage used by my existing virtual machines into Cinder without disrupting operation of my existing virtual machines

  • As the Enterprise IT manager that is deploying an OpenStack cloud

    alongside my existing infrastructure, I need manage existing virtual machines network resources without disrupting those virtual machines

Usage Scenarios Examples

  1. 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.

Opportunity/Justification

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.

Requirements

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 accomodated 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

Gaps

  • Cinder API to list all volumes

  • Cinder API to add volume to database (current ?manage_existing?

    API requires too much intrinsic knowledge because it only provides the storage primary ID when what we need the WWPNs, Page83 SCSI Identifier, etc that the hypervisor would know

  • Nova API to discover VM and all resources associated with it including

    Memory, Processor, Block Volumes

  • Nova API to add existing VM to OpenStack database

  • Neutron API to add network information to OpenStack database

Glance changes are not required for the initial onboarding for management process

Affected By

None.

External References

None.

Glossary

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