Version 20 (modified by zhaomuzh, 8 years ago)

--

Using ImageProxy with ORCA

Overview

ImageProxy allows independent Ecalyptus sites to create VMs with identical images. Images are identified by a URL and a GUID, 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>
		<signiture>FS_IMAGE_HASH</signiture>
		<url>http://url_filesystem_image</url>
	</image>
	<image>
		<type>KERNEL</type>
		<signiture>KERNEL_IMAGE_HASH</signiture>
		<url>http://url_kernel_image</url>
	</image>
	<image>
		<type>RAMDISK</type>
		<signiture>RAMDISK_IMAGE_HASH</signiture>
		<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, 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.

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

Deployment

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.