Jump to: navigation, search

VMware-vSphere-support

Revision as of 13:27, 20 December 2010 by EwanMellor (talk)

This blueprint is in draft. Nothing here is committed.


  • Launchpad Nova blueprint: NovaSpec:hypervisor-vmware-vsphere-support
  • Created: 19 December 2010
  • Last updated: 20 December 2010
  • Contributors: Ewan Mellor, Ravi Gururaj

Summary

This blueprint proposes adding support to Nova for the use of VMware vSphere as a compute provider.

Requirements

R1. Support VMware vSphere 4.1 as a compute provider within Nova. Deployment architecture is restricted to ESXi (i.e. ESX is not supported). VM storage is restricted to VMFS volumes on local drives. vCenter is not strictly required by the current design, but it will always be present in the environment anyway, due to license restrictions.

R2. Integrate with Glance, so that VM images can be streamed from there for boot on ESXi.

Non-requirements

NR1. Shared storage support is excluded.

NR2. Live migration support is excluded.

NR3. Clustering support is excluded.

NR4. Nova is not required to handle any automatic installation or configuration of the underlying hypervisor. The user will be responsible for configuring vSphere appropriately.

NR5. Nova is not required to interrogate vCenter to find compute hosts. The user will be responsible for configuring Nova with the details for each compute host.

NR6. Nova is not required to cope gracefully when compute nodes are concurrently managed by automatic vCenter operations or other third parties. Nova may assume that it "owns" the compute node entirely.

NR7. Nova is not required to cope gracefully when compute nodes are subject to VMware Update Manager dynamic updates.

Assumptions

A1. The OpenStack project will not ship any VMware products or SDKs. Users will need to get the appropriate SDKs from VMware. (Shipping the SDK is restricted by license, even if we wanted to.)

A2. Users will require licenses for VMware vSphere Essentials (or greater) for all "clouds" with up to three compute hosts, and VMware vSphere Standard (or greater) for all sensible clouds. See Licensing below.

Rationale

Regarding R1's restriction to ESXi: On http://www.vmware.com/products/vsphere/esxi-and-esx/overview.html, VMware state "vSphere 4.1 and its subsequent update and patch releases are the last releases to include both ESX and ESXi hypervisor architectures. Future major releases of VMware vSphere will include only the VMware ESXi architecture. For this reason, VMware recommends that deployments of vSphere 4.x utilize the ESXi hypervisor architecture." Following this, we restrict to ESXi to reduce the QA burden, as there is no known need to support ESX.

Regarding R1's restriction to vSphere 4.1: this is to reduce the QA burden, as there is no known need to support older versions.

NRs 1, 2, 3, 6, and 7 have been added to avoid increasing the QA burden.

NRs 4 and 5 have been added to avoid increasing the development burden.

Design

The requirement to support ESXi implies that nothing can be installed inside the console domain. Instead, we will install nova-compute inside a virtual machine, one per compute node. nova-compute will be given the credentials to the local ESXi (or the controlling vCenter), and with these credentials it will perform all necessary actions through the VMware vSphere API over SOAP (see VMware vSphere API Reference Documentation and VMware APIs and SDK Documentation).

Disk streaming from Glance will also be handled within this VM. The VM will ask for a new virtual disk to be created, and attached to itself for writing. Once the streaming is finished, that disk will be detached and made available for the new customer VM.

The connection from Nova to vCenter/ESXi will be through a nova.virt module, parallel with nova.virt.libvirt_conn and nova.virt.xenapi_conn (i.e. not through libvirt).

Unit testing will be of similar style to that used by XenAPI, with a mock vCenter stubbed in at the RPC layer (i.e. below nova.virt.vmware_conn).

Future

Development Resources

Citrix has committed a development team to implement the functionality specified here. Prototyping is underway, and will be pushed to Launchpad soon.

No commitment has been made with regard to any "Future" features.

Licensing

Why we can't use vSphere Hypervisor

From http://www.vmware.com/download/eula/esx_esxi_eula.html:

"3. GRANT AND USE RIGHTS FOR SOFTWARE

"3.3 Restrictions. You may not (i) sell, lease, license, sublicense, distribute or otherwise transfer in whole or in part the Software or the Software License Key to another party; (ii) provide, disclose, divulge or make available to, or permit use of the Software in whole or in part by, any third party (except Designated Administrative Access) without VMware’s prior written consent; (iii) modify or create derivative works based upon the Software; or (iv) create, develop, license, install, use, or deploy any third party software or services to circumvent, enable, modify or provide access, permissions or rights which violate the technical restrictions of the Software, any additional licensing terms provided by VMware via product documentation, notification, and/or policy change posted at www.vmware.com, and the terms of this EULA."

Also, from http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1023990:

"vCLI, PowerCLI, and vSphere SDK for Perl are limited to read-only access for the free vSphere Hypervisor edition. To enable full functionality of vCLI on a VMware ESXi host, the host must be licensed with vSphere Essentials, vSphere Essential Plus, vSphere Standard, vSphere Advanced, vSphere Enterprise, or vSphere Enterprise Plus."

We understand this to mean that vSphere Hypervisor (previously known as "Free ESXi") may not be managed programmatically in a read-write manner, since VMware's own tools make that restriction. See also http://www.veeam.com/blog/veeam-and-free-esxi.html and http://www.virtualizationpractice.com/blog/?p=274.

Why we can't use vSphere Essentials or Essentials Plus for more than three compute nodes

From http://www.vmware.com/download/eula/esx_esxi_eula.html:

"9. SOFTWARE PRODUCT SPECIFIC TERMS AND CONDITIONS

"9.1 ESX/ESXi

"c) VMware vSphere Essentials and VMware vSphere Essentials Plus

"If you have licensed VMware vSphere Essentials or VMware vSphere Essentials Plus, the following additional license terms apply:

"VMware licenses VMware vSphere Essentials or VMware vSphere Essentials Plus editions (collectively "Editions") to you solely for managing up to three (3) server hosts and your use of these Editions is limited to servers with up to two processors. For these Editions, the server hosts must be managed by the VMware vCenter Server that is provided with these Editions, and that same VMware vCenter Server cannot be used to manage other server hosts not included with these Editions."

We understand this to mean that it is forbidden to use Essentials or Essentials Plus for any installation larger than three hosts.

Release Note

Nova may now use VMware vSphere as a compute provider.

Discussion

Question: Does anyone want support for older versions or architectures of vSphere? To reduce the QA burden, we're currently restricted to vSphere 4.1 and ESXi only.

Question: What on Earth do we do about networking?