Using ImageProxy with ORCA

Overview

ImageProxy allows independent cloud sites to create VMs with identical images. Images are identified by a URL and a signature, SHA-1 hash of the image (use sha1sum GNU utility to generate a hash of a file). A metadata file containing information about the different types of images needs to be created.

Sample metadata file. Node element names and keywords representing image type are case sensitive.
<images>
	<image>
		<type>FILESYSTEM</type>
		<signature>FS_IMAGE_HASH</signature>
		<url>http://url_filesystem_image</url>
	</image>
	<image>
		<type>KERNEL</type>
		<signature>KERNEL_IMAGE_HASH</signature>
		<url>http://url_kernel_image</url>
	</image>
	<image>
		<type>RAMDISK</type>
		<signature>RAMDISK_IMAGE_HASH</signature>
		<url>http://url_ramdisk_image</url>
	</image>
</images>

The metadata file itself also needs to be hosted. Provided with the URL for the metadata file and its signature (SHA1 hash), ImageProxy associated with a Eucalyptus site can download and install the required images and provide ORCA with site-specific image ids (AMI/EMI, AKI/EKI, ARI/ERI) that can be used to create guest VMs on that site. Even though image ids will be different for each site, VMs will be runnning the same user-supplied image.

The documentation for the latest metafile format is maintained on the ImageProxy wiki.

ORCA Integration (Camano 3.0+)

Resource Specification

URL for the image metadata file can be passed to ORCA as part of Reservation instance of the NDL-OWL request as follows:

    <request:Reservation rdf:about="#id-mp-request-2">
        <request:startingTime
            >2010-11-02T13:00:00Z</request:startingTime>
        <request:endingTime
            >2010-11-03T13:00:00Z</request:endingTime>
        <compute:hasVMImage rdf:resource="#DukeVMImageTest"/>
        <collections:element rdf:resource="&Request2;tblink-l4"/>
        <collections:element rdf:resource="&Request2;tblink-l5"/>
        <collections:element rdf:resource="&Request2;tblink-l6"/>
        <request:inDomain rdf:resource="&DukeVMSite2;Domain"/>
        <layer:atLayer rdf:resource="&ethernet;EthernetNetworkElement"/>
    </request:Reservation>

    <compute:VMImage rdf:about="#DukeVMImageTest">
        <topology:hasGUID rdf:datatype="&xsd;string">1234567890</topology:hasGUID>
        <topology:hasURL>http://geni-orca.renci.org/image/duke</topology:hasURL>
    </compute:VMImage>

Handler Integration

The interface to ImageProxy SOAP service is implemented as an OrcaAntTask named ImgProxyRegisterTask in the orca.handlers.ec2.tasks.imgproxy package (under handlers/ec2). The task is integrated into the standard EC2 handler used with Eucalyptus/NEuca. ImageProxy-specific settings can be passed to orca via ec2.site.properties file. The relevant properties are:

# Image Proxy (use it or not true/false)
ec2.img.proxy.use=true
# SOAP URL of the image proxy
ec2.img.proxy.url=http://geni-test.renci.org:11080/axis2/services/IMAGEPROXY
# SOAP timeout (in sec; adjust only if you know what you're doing)
ec2.img.proxy.timeout=3600

The handler expects config.image.url property to be passed to it by the AM. ImageProxy should use the same credentials as ORCA when manipulating images in a Eucalyptus site (credentials for ImageProxy are installed separately, see ImageProxy installation procedure).

For more information see the sections about NEuca handler and NEuca handler testing.

Installation and Deployment

See instructions on ImageProxy website for installation steps. Be sure to pick the appropriate release.

Recommended deployment in a standalone Axis2 server on the same host as the Euca authority actor (Eucalyptus head node). ImageProxy relies on having euca-xxx-xxx executables available on the system it runs on. Also, choose the location of IMAGEPROXY_HOME wisely, as it cashes large image files and can easily overwhelm as small filesystem.