IaaS Virtualization Provider Plugins

(template version 1.92)

1. Introduction

1.1. Project/Component Working Name:

IaaS Management Service Virtualization Provider Plugins

1.2. Name(s) and e-mail address of Document Author(s)/Supplier:

Joe Di Pol: jfdipol@java.net

1.3. Date of This Document:

04/22/2011

2. Project Summary

2.1. Project Description:

Virtualization plugin providers for the IaaS Management Service (IMS).

2.2. Risks and Assumptions:

1. Unknows: due to newness of this area there may be things we don't know that we don't know.
2. Immaturity of programmatic interfaces to some virtualization providers may uncover shortcomings and instabilities.

3. Problem Summary

3.1. Problem Area:

The GlassFish IaaS Management Service (IMS) must speak to a variety of virtualization providers. IMS support an SPI so that plugins may be written for specific providers. See the IaaS Management Service specification for more information on this API.

This one-pagers covers the plugins that we intend to implement for GlassFish 3.2. Specifically it covers the plugins for:

1. libvirt/KVM (may be covered in IMS spec)
2. Oracle VM using OVM Manager
3. Oracle VirtualBox

3.2. Justification:

These plugins are required for the IaaS support in GlassFish 3.2.

4. Technical Description:

4.1. Details:

A Java plugin will be written for each provider that implements the interfaces of the IMS SPI. The general capabilities required of the SPI include (but are not limited to):

1. Creating a VM from a VM template
2. Starting a VM
3. Stopping a VM
4. Getting status information from a VM (running state)
5. Getting metrics information from a VM (such as CPU and memory usage)
6. Setting and Getting IP addresses for VMs

A set of IMS related asadmin commands will be used to configure the plugins for use in IMS. These commands are described in the IMS specification . This document will describe any provider specific difference from the base commands described in the IMS specification.

How the SPI is implemented may vary significantly by providers.

4.1.1 libvirt/KVM

TBD

4.1.2 Oracle VM 2.2 (OVM)

The OVM 2.2 product consists of the OVM Server, a Xen based virtualization server, and OVM Manager, a management console which manages collections of OVM Servers.

OVM Manager provides a WUI admin console as well as a web services API that exposes all of the capabilities available via the console. An optional CLI is also available for OVM Manager that sits on top of the web services API.

OVM Servers are assigned to pools in OVM Manager. OVM Manager communicates with the OVM Servers using the OVM Agent that runs in dom0 of each OVM Server.

The GlassFish OVM plugin uses the OVM Manager Web Services interface and therfore requires the use of the OVM Manager. The goal is to use the OVM Manager WS interface exclusively, but due to limitations in that interface the plugin may need to access dom0 of a server pool master directly. At this time there are no plans to use the OVM Manager CLI.

The basic VM lifecycle operations will be implemented using the OVM Manager WS API. Specifically: importing of a template, creation of a VM from a template, destruction of a VM, starting and stopping of a VM, and getting VM status.

A limited number of operations may require either SSH access to dom0 of the server pool master or direct filesystem access to the VM repository. These operations are:

• Importing of a template. While the OVM Manager WS API supports importing of a remote template, the implementation is inefficient – it essentially does a wget of an OVM template directory and copies over the uncompressed template. As an optimization we may choose to copyover a zipped form of the template directly to the server pool master's repository, unzip it, then use OVM manager to import it directly from the server pool master (a supported operation).
• Passing of parameters to a VM at boot time. One of the main challenges of implementing an IMS plugin is passing parameters to a VM at boot time. OVM provides no convenient support for this. It appears as though we will need to do this either using xenstore (a simple persistent store shared between dom0 and a guest) or via a small supplemental disk image that is created by the plugin and mount and read by the guest.

OVM Templates

OVM templates will be constructed using the Oracle JeOS toolkit and will include:

Why have three separate virtual disk images?

1. By having the application image separate from the OS it makes it easy to update a template without touching the OS image – you just drop in a new Application.img.
2. Separating the application mitigates licensing concerns since it separates application binaries from Linux (GPL) binaries (I don't fully understand this, but it is recommended in the Creating Pre-Built VMs white paper ).
3. Keeping the Bootparams.img separate reduces the risk of mounting a VM filesystem in dom0 and causing filesystem corruption if the virtual disk is in use by the guest. The guest can immediately unmount this filesystem after boot, so the virtual disk will only be in use during OS bootup.

OVM Virtual Machine Lifecycle

The following table describes the current thinking for how the major lifecycle operations will be implemented.

4.1.3 VirtualBox

TBD

4.2. Bug/RFE Number(s):

GLASSFISH-16379 Oracle VM 2.2 plugin for IMS
GLASSFISH-16380 VirtualBox 4 plugin for IMS
GLASSFISH-16381 libvirt/KVM plugin for IMS
GLASSFISH-16382 Oracle VM templates for IMS

4.3. In Scope:

TBD

4.4. Out of Scope:

TBD

4.5. Interfaces:

4.5.1 Public Interfaces

CLI

The base IMS asadmin commands are described in the IMS specification . The plugins will not add any new asadmin commands, but may have plugin specific options and parameters that are described here.

libvirt/KVM CLI

TBD

Oracle VM 2.2 CLI

TBD

VirtualBox 4 CLI

TBD

4.5.2 Private Interfaces

domain.xml?

4.5.3 Deprecated/Removed Interfaces:

N/A

4.6. Doc Impact:

The doc impact is mainly by the base IMS support. The impact for the IMS feature as a whole will be significant and include:

1. New man pages for new asadmin commands
2. New sections in admin guide/reference

4.7. Admin/Config Impact:

New CLI's will be needed as described in section 4.5.1

Corresponding enhancements will need to be made to the admin console.

4.8. HA Impact:

N/A

4.9. I18N/L10N Impact:

Moderate, as needed for new admin commands.

4.10. Packaging, Delivery & Upgrade:

4.10.1. Packaging

TBD. These providers will likely be contained in the same package that contains the base IaaS Management Service.

4.10.2. Delivery

N/A

4.10.3. Upgrade and Migration:

Should be covered in IMS spec.

4.11. Security Impact:

At this time the assumption is that we can leverage current security related interfaces.

4.12. Compatibility Impact

N/A

4.13. Dependencies:

4.13.1 Internal Dependencies

4.13.2 External Dependencies

4.13.2.1 libvirt/KVM External Dependencies

TBD

4.13.2.2 Oracle VM 2.2 External Dependencies

4.13.2.3 Virtual Box 4 External Dependencies

TBD

4.14. Testing Impact:

How will the new feature(s) introduced by this project be tested?
Do tests exist from prior releases (e.g. v2) that can be reused?
Will new tests need to be written? Can they be automated?

5. Reference Documents:

• 3.2 Virtualization (IMS) Specification
• Creating a GlassFish OVM Template (internal)
• OVM Manager 2.2 Web Services Javadoc

6. Schedule:

6.1. Projected Availability:

Indicate which milestones from the current schedule the project
will be:

• Initially integrated (may not be feature complete)
• Feature complete (ready for handoff to QA)
• At production quality level

OVM Plugin.png (image/png)
OVM Plugin.png (image/png)
OVM Plugin.png (image/png)
OVM Plugin.png (image/png)
OVM Plugin.png (image/png)
OVM Plugin.png (image/png)