Version 56 (modified by ibaldin, 8 years ago)


Using NEuca with Orca


This page contains notes about how NEuca is to be used in Orca. A canonical deployment puts the container with Euca site authority on the Euca head node so the site handler can ping instances as they come up (it is not possible from elsewhere). Camano 3.0+ has an option to turn off ping testing and relaxes this constraint.

NEuca Site Authority

To use NEuca, you need a NEuca-enabled Eucalyptus cluster and an Orca site authority actor configured to interact with NEuca. Authority configuration files differ between releases. Here is the Bella2.2 authority configuration for a standalone NEuca site with an EX3200 switch for a backplane.

THe rest of this section explains various parts of this file and additional configuration files needed.

Eucalyptus Keys

The path to ec2.keys in the config file is important. It must point to the location which has the eucalyptus keys and eucarc. In the example config file, the ec2 keys are stored in /opt/orca/ec2. To get the keys for your eucalyptus account, you have to log in to your Eucalyptus portal with the euca username, say, 'orca'. Go to Credentials tab and then click on 'Download Credentials' under 'Credentials ZIP-file'. Unzip the contents of this zip file (which will have a name like euca2-<euca username> in the ec2.keys directory.

Associate a private key to your euca account, which can be used to log in to any instances brought up. This key can be generated by issuing the following command after sourcing eucarc.

$ euca-add-keypair keyName

Store the output of this command in a file with name as keyName and put it in the ec2.keys directory.

Bella 2.2 instructions

Edit eucarc in that directory as follows. Comment out the first line by inserting '#' at the beginning of the line. Add the following lines to eucarc. The AMI_NAME must correspond to the emi-id of a neuca-enabled image. Replace XXXXXX with the correct id . The EC2_SSH_KEY property must point to the keyName file. EC2_USE_PUBLIC_ADDRESSING should be set to true (boolean, not string) if you want Eucalyptus to use a pool of available public IP addresses, false otherwise. If not set, defaults to 'false'. EC2_PING_RETRIES defines how many times to try to ping the instance after it is in 'running' state before tearing it down and exiting with an error. If unset, defaults to 60 (with 1 second sleep interval at each step).

export AMI_NAME=emi-XXXXXX
export EC2_SSH_KEY=keyName
export EC2_PING_RETRIES=60

Camano 3.0+ instructions

Edit eucarc as follows: comment out the first line by inserting '#' at the beginning of the line. All shell variables from Bella-2.2 in the above section (AMI_NAME, EC2_SSH_KEY etc.) have moved to file. See below.

Notes on deploying NEuca Authority

If you are deploying the NEuca authority in the same machine where Eucalyptus head node resides, a different port number has to be used by the tomcat. This is because the default port used by our tomcat (Port 8080) is already in use by Eucalyptus. To change the default port from 8080 to another unused port number, say 11080, the following needs to be changed. All changes are with respect to the webapp/ directory. In package/webapp/conf/server.xml , change "<Connector port="8080" maxHttpHeaderSize..." to "<Connector port="11080" maxHttpHeaderSize..." . In ant/, change "target.port=8080" to "target.port=11080" . Change any relevant soapaxis2 url in actor_configs/config.xml for OTHER actors talking to the NEuca actors. Edit one more tomcat file - If your tomcat installation is at /opt/orca/tomcat, edit /opt/orca/tomcat/conf/server.xml by changing "<Connector port="8080" maxHttpHeaderSiz.." to "<Connector port="11080" maxHttpHeaderSiz.."

NOTE: Starting with Bella 2.2 ORCA uses port 11080 by default in Tomcat.

NEuca Handler

The NEuca handler supports creating VMs using the NEuca extension. The current version of the handler supports the following:

  • multiple network interfaces (Bella)
  • ip addresses per network interface (Bella)
  • an instance configuration script (Bella)
  • installation of user SSH public key (Bella)
  • configuration of Shorewall DNAT port-forwarding proxy (Camano)
  • configuration of ImageProxy (Camano)

The support for these features is controlled by one or more properties, which are described below. Static site-dependent properties can be passed to the handler either via file (see below), while dynamic properties are passed by ORCA at run-time.

Network Interface Configuration (dynamically configured from site NDL and request NDL)

NEuca allows reservation requests to control any network interface other than eth0, which is reserved internally. Each network interface must at least be associated with a VLAN tag, and can optionally specify an IP address and a subnet mask (in / notation, e.g,

To specify configuration for eth1, the following properties must be passed to the site authority:

unit.eth1.hosteth=eth0  // eth0 is assumed to be the interface on the physical host to which VM needs to attach its eth1. This is dependent on the deployment

If the VM should contain one more interface, then it can be specified by passing:


Instead of specifying interface-specific VLAN tag, the handler also supports specifying a VLAN tag using the unit.vlan.tag property. In this case the machine can have only one network interface (eth1):


When both unit.vlan.tag and unit.eth1.vlan.tag are specified, the latter takes precedence.

Instead of attaching VM interfaces to VLANs on physical hosts, it is also possible to attach them to plain host interfaces. In this case only one option is available:


The handler also accepts IP address of the VM interface in by specifying the propert(ies):


Instance Configuration Script (can be dynamic or static)

To pass an instance configuration script pass the contents (not the location) of the script in the unit.instance.config property:

unit.instance.config=echo "hello world"

Guest SSH Public Key

By default all NEuca VMs are created to authorize SSH connections using the site authority's private key. To enable the guest to connect as root using its own key, pass the guest's SSH public key in config.ssh.key:


Static properties/

See sample for Bella 2.2 and sample for Camano 3.0+ files for more details.

Eucanet handler

Usually a NEuca cluster has an ORCA-controlled switch that ethX (ethX != eth0) of all worker nodes are connected to. In order to perform things like site embedding (embedding a topology in a single NEuca site), you must configure another resource pool for VLANs (eg. unc-net-site or renci-net-site) and use the appropriate handler that will configure VLANs on the switch as needed. Usually the pool is operated by the same authority actor as NEuca. The handler definition should look something like this (also above in the larger example):

 <!-- For Bella 2.2 you have to specify a site-specific handler (e.g. 
 For Camano 3.0+  a unified handler can be used -->
<handler path="providers/euca-sites/">
           <!-- name of the site that helps locate appropriate property definitions (Camano 3.0+) -->
            <property name="" value="renci" />
            <!-- credentials for logging into the switch  (Bella 2.2) -->
            <property name="eucanet.credentials" value="/opt/orca/config/" />


The file named as eucanet.credentials property above needs to exist and needs to define at least the following properties:

router.user=Username of the user authorized on the switch
router.password=Password of the user authorized on the switch
sitename.euca.router=FQDN or IP of the router used for Euca dataplane

Accessing VMs Created by NEuca

Each VM created by NEuca is represented as an Unit object in the ConcreteSet? of the VM reservation. The unit.manage.ip property can be used to access the management ip of the VM. If the guest specified an SSH key, then it can use it to connect to the machine at address unit.manage.ip.