Eucalyptus VPC with MidoNet 5.2

Eucalyptus started to support AWS compatible VPC (Virtual Private Cloud) from v4.2 as a new networking mode VPCMIDO. Eucalyptus still supports the EC2 classic networking in EDGE networking mode. Eucalyptus VPC exposes the same AWS VPC APIs to support the existing application that were built for AWS. Eucalyptus uses MidoNet as a backend for VPC and supports both open source MidoNet and Midokura Enterprise MidoNet (MEM). The current Eucalyptus release v4.3 supports MidoNet v1.9 and has gone through a huge improvements in terms of performance and stability from Eucalyptus v4.2.2.

Eucalyptus v4.4 is under heavy development and supports current stable release of MidoNet v5.2!

A basic deployment of MidoNet (v5.2) for Eucalyptus VPC consists of following components:

  1. MidoNet Cluster – installed on Cloud Controller (CLC)
  2. Gateway Node (MidoNet Gateway)
  3. Network State Database (NSDB) – Zookeeper and Cassandra
  4. MidoNet Agents (Midolman) – Cloud Controller (CLC) and Node Controllers (NC)

Steps to install Eucalyptus 4.4 VPC

Even though Eucalyptus 4.4 is still under development, nightly packages are already available here.

Installation of the MidoNet components are pretty straight forward and are well explained in MidoNet documentation.

  • Repository configuration for opensource MidoNet
  • Network State Database installation
  • Install and configure MidoNet Cluster on CLC
    # install packages
    yum install midonet-cluster python-midonetclient
    # file: /etc/midonet/midonet.conf
    zookeeper_hosts =
  • Run the following command on MidoNet Cluster, configure access to NSDB
    $ cat << EOF | mn-conf set -t default
    zookeeper {
        zookeeper_hosts = ""
    cassandra {
        servers = ""
  • Start midonet-cluster.service
  • Install and configure Midolman on CLC and NCs
    yum install java-1.8.0-openjdk-headless midolman
    # file: /etc/midolman/midolman.conf
    zookeeper_hosts =
  • Set Midolman resource template
    mn-conf template-set -h local -t default
  • Start midolman.service on all the hosts.
  • Install and configure Eucalyptus with VPCMIDO as networking mode. Eucalyptus 4.4 installation is identical to v4.3.

Create MidoNet Resource for VPC

  • Launch MidoNet CLI on MidoNet Cluster
    midonet-cli -A --midonet-url=http://localhost:8080/midonet-api
  • Create a tunnel-zone with type ‘gre’ (Generic Routing Encapsulation)
    midonet> create tunnel-zone name mido-tz type gre
  • Add hosts e.g CLC, NCs to tunnel-zone. If midolman services are running on the hosts with correct configuration, we should see a list hosts with the following command
    midonet> host list
    host host0 name alive true addresses,fe80:0:0:0:0:11ff:fe00:1101,fe80:0:0:0:0:11ff:fe00:1102,,fe80:0:0:0:eeb1:d7ff:fe7f:53bc,,0:0:0:0:0:0:0:1,,fe80:0:0:0:eeb1:d7ff:fe7f:53bc,fe80:0:0:0:eeb1:d7ff:fe7f:53bc flooding-proxy-weight 1 container-weight 1 container-limit no-limit enforce-container-limit false
    host host1 name alive true addresses fe80:0:0:0:ea9a:8fff:fe74:12ca,fe80:0:0:0:0:11ff:fe00:1102,,fe80:0:0:0:ea9a:8fff:fe74:12ca,,0:0:0:0:0:0:0:1,fe80:0:0:0:ea9a:8fff:fe74:12cb,,fe80:0:0:0:ea9a:8fff:fe74:12ca,,fe80:0:0:0:0:11ff:fe00:1101, flooding-proxy-weight 1 container-weight 1 container-limit no-limit enforce-container-limit false
    host host2 name alive true addresses,0:0:0:0:0:0:0:1,fe80:0:0:0:0:11ff:fe00:1102,fe80:0:0:0:ea39:35ff:fec5:7098,,fe80:0:0:0:ea39:35ff:fec5:7098,fe80:0:0:0:0:11ff:fe00:1101,,,fe80:0:0:0:ea39:35ff:fec5:7098 flooding-proxy-weight 1 container-weight 1 container-limit no-limit enforce-container-limit false
    # Add the hosts to tunnel zone
    midonet> tunnel-zone list
    tzone tzone0 name mido-tz type gre
    midonet> tunnel-zone tzone0 add member host host0 address
    zone tzone0 host host0 address
    midonet> tunnel-zone tzone0 add member host host1 address
    zone tzone0 host host1 address
    midonet> tunnel-zone tzone0 add member host host2 address
    zone tzone0 host host2 address
  • Set up local ASN for router
    # list router
    midonet> router list
    router router0 name eucart state up asn 0
    midonet> router router0 set asn 65996
  • Set BGP Peer (may change in future EUCA-12890)
    midonet> router router0 add bgp-peer asn 65000 address
  • Set BGP Network
    midonet> router router0 add bgp-network net


Install an image using and following command and start running instances with VPC!

python <(curl -sL
python <(curl -sL

Eucalyptus 3.3.0 in a nutshell

Eucalyptus 3.3.0, the most exciting Eucalyptus release so far is knocking on the door or perhaps it has been already released when you are reading this post.

Eucalyptus 3.3.0 has couple of most desired Amazon Web Services (AWS) features by the cloud users:

1. Elastic Load Balancing (ELB)

Needless to say, this is an AWS ELB compatible feature which is being introduced in Eucalyptus 3.3.0.

Creating a basic loadbalancer:

eulb-create-lb -z PARTI00 -l 'lb-port=80, protocol=HTTP, instance-port=80' MyElb
# output

# output
# LOAD_BALANCER	MyElb	2013-06-10T06:57:52.07Z

Register instances with Eucalyptus Elastic Load Balancer,

eulb-register-instances-with-lb MyElb --instances i-25D3415E,i-16463E17
# output
# INSTANCE i-25D3415E
# INSTANCE i-16463E17

eulb-describe-instance-health MyElb
# output
# INSTANCE	i-25D3415E	InService
# INSTANCE	i-16463E17	InService

Few other ELB operations,

# deregister instances from ELB
eulb-deregister-instances-from-lb MyElb --instances i-16463E17

# delete ELB
eulb-delete-lb MyElb

2. CloudWatch

CloudWatch is another AWS-compatible feature which is shipping with Eucalyptus 3.3.0. It enables cloud users to view, collect and analyze metrics of their could resources. It also lets cloud users to configure alarm actions based on the data from the metrics.

Enable instance monitoring,

# on existing instance
euca-monitor-instances i-25D3415E

# during instance run
euca-run-instances -k batman1key emi-90E83973 --monitor

# disable monitoring
euca-unmonitor-instances i-DB5842DC


# returns all the available metrics

# returns list of metrics with particular metric name
euwatch-list-metrics --metric-name CPUUtilization

# returns list of metrics with particular namespace
euwatch-list-metrics --namespace AWS/EC2

# returns list of metrics with particular dimensions
euwatch-list-metrics --dimensions "InstanceId=i-25D3415E"

# returns time-series data for one or more statistics of a given MetricName
euwatch-get-stats CPUUtilization \
> --start-time 2013-06-10T07:09:00.043Z \
> --end-time 2013-06-10T08:46:54.043Z \
> --period 3600 \
> --statistics "Average,Minimum,Maximum" \
> --namespace "AWS/EC2" \
> --dimensions "InstanceId=i-25D3415E"

3. Auto Scaling

Eucalyptus Auto Scaling is consists of three fundamental principles,

  1. Launch Configurations
  2. Auto Scaling Groups
  3. Auto Scaling Policies

Create a launch configuration,

euscale-create-launch-config MyLC \
> --image-id emi-90E83973 \
> --instance-type m1.small

Create auto scaling group,

euscale-create-auto-scaling-group MyASGroup \
> --launch-configuration MyLC \
> --availability-zones PARTI00 \
> --min-size 1 --max-size 3

# describe auto scaling groups

Create scale out policy,

euscale-put-scaling-policy MyScaleoutPolicy \
> --auto-scaling-group MyASGroup \
> --adjustment=30 \
> --type PercentChangeInCapacity

# output
# arn:aws:autoscaling::576514848852:scalingPolicy:c2a8f9dc-1c75-49d5-b54d-8ef87fe29e9a:autoScalingGroupName/MyASGroup:policyName/MyScaleoutPolicy

Creating scale in policy,

euscale-put-scaling-policy MyScaleInPolicy \
> --auto-scaling-group MyASGroup \
> --adjustment=-2  --type ChangeInCapacity

# output
# arn:aws:autoscaling::576514848852:scalingPolicy:a4148c27-81da-4eff-9140-cba3ba9381cb:autoScalingGroupName/MyASGroup:policyName/MyScaleInPolicy

CloudWatch Alarm

Eucalyptus CloudWatch alarm currently helps cloud users to take decisions on the resources (e.g instances, EBS volumes, Auto Scaling instances, ELBs) automatically based on the rules defined by the users based on the metrics. Eucalyptus CloudWatch alarm currently works with Auto Scaling policies.

Create alarm for scale out capacity and scale in capacity,

# create scale out alarm
euwatch-put-metric-alarm AddCapacity \
> --metric-name CPUUtilization \
> --namespace "AWS/EC2" \
> --statistic Average \
> --period 120 --threshold 80 \
> --comparison-operator GreaterThanOrEqualToThreshold \
> --dimensions "AutoScalingGroupName=MyASGroup" \
> --evaluation-periods 2 \
> --alarm-actions arn:aws:autoscaling::576514848852:scalingPolicy:c2a8f9dc-1c75-49d5-b54d-8ef87fe29e9a:autoScalingGroupName/MyASGroup:policyName/MyScaleoutPolicy

# create scale in alarm
euwatch-put-metric-alarm RemoveCapacity \
> --metric-name CPUUtilization \
> --namespace "AWS/EC2" \
> --statistic Average \
> --period 120 --threshold 40 \
> --comparison-operator LessThanOrEqualToThreshold \
> --dimensions "AutoScalingGroupName=MyASGroup" \
> --evaluation-periods 2 \
> --alarm-actions arn:aws:autoscaling::576514848852:scalingPolicy:a4148c27-81da-4eff-9140-cba3ba9381cb:autoScalingGroupName/MyASGroup:policyName/MyScaleInPolicy

# delete alarm

Set the alarm state to OK/ALARM for testing,

euwatch-set-alarm-state --state-value OK \
> --state-reason "testing" AddCapacity

euwatch-set-alarm-state --state-value OK \
> --state-reason "testing" RemoveCapacity


# output
# AddCapacity	OK	arn:aws:autoscaling::576514848852:scalingPolicy:c2a8f9dc-1c75-49d5-b54d-8ef87fe29e9a:autoScalingGroupName/MyASGroup:policyName/MyScaleoutPolicy	AWS/EC2	CPUUtilization	120	Average	2	GreaterThanOrEqualToThreshold	80.0
# RemoveCapacity	OK	arn:aws:autoscaling::576514848852:scalingPolicy:a4148c27-81da-4eff-9140-cba3ba9381cb:autoScalingGroupName/MyASGroup:policyName/MyScaleInPolicy	AWS/EC2	CPUUtilization	120	Average	2	LessThanOrEqualToThreshold	40.0

4. Resource Tagging

Resource tagging was another missing AWS feature which was not there until 3.2.2. This is a very important feature and also used by many 3rd party tools and application.

euca-create-tags vol-65803EB8 --tag "testtag"
# TAG volume vol-65803EB8 testtag

# VOLUME vol-65803EB8 2 PARTI00 available 2013-06-10T12:29:41.082Z standard
# TAG volume vol-65803EB8 testtag

5. More instance type

INSTANCETYPE	Name         CPUs  Memory (MB)  Disk (GB)
INSTANCETYPE	m1.small        1          256          5
INSTANCETYPE	t1.micro        1          256          5
INSTANCETYPE	m1.medium       1          512         10
INSTANCETYPE	c1.medium       2          512         10
INSTANCETYPE	m1.large        2          512         10
INSTANCETYPE	m1.xlarge       2         1024         10
INSTANCETYPE	c1.xlarge       2         2048         10
INSTANCETYPE	m2.xlarge       2         2048         10
INSTANCETYPE	m3.xlarge       4         2048         15
INSTANCETYPE	m2.2xlarge      2         4096         30
INSTANCETYPE	m3.2xlarge      4         4096         30
INSTANCETYPE	cc1.4xlarge     8         3072         60
INSTANCETYPE	m2.4xlarge      8         4096         60
INSTANCETYPE	hi1.4xlarge     8         6144        120
INSTANCETYPE	cc2.8xlarge    16         6144        120
INSTANCETYPE	cg1.4xlarge    16        12288        200
INSTANCETYPE	cr1.8xlarge    16        16384        240
INSTANCETYPE	hs1.8xlarge    48       119808      24000

Well, if you used Eucalyptus before, I think, the improvement is very much visible 🙂

6. Maintenance Mode:

Eucalyptus 3.3.0 also comes with the feature which many cloud administrator might be waiting for such a long time, which is Maintenance Mode.

In other words, migrating a single instance to another Node Controller or evacuating a certain Node Controller are now supported by Eucalyptus.

# evacuate a Node Controller
euca-migrate-instances --source

# migrate specific instance to another destination
euca-migrate-instances -i i-38A74228 --dest

For more information check the Eucalyptus 3.3.0 roadmap. Architectural overview for 3.3.x release can be found on githubHere is a list of new stories that are going to take place in the 3.3.0 release.

More AWS Compatibility

Eucalyptus 3.3.x is the most AWS compatible release ever. It has more API compatibility than Eucalyptus ever had. Here is couple of our ongoing work on the different AWS SDKs and open source libraries.

  1. AWS SDK for Java
  2. AWS SDK for Ruby
  3. AWS SDK for PHP
  4. AWS toolkit for Eclipse
  5. jcloud on Eucalyptus – This is comparatively newest among all, we are tracking this as a story on jira, EUCA-5671.

Eucalyptus 3.3.0 has few very important improvements on Boot-from-EBS instances,

1. Root block device is /dev/sda and not /dev/sda1
2. Allow multiple EBS block device mappings
3. No more default ephemeral disk at /dev/sdb
4. Metadata service changes

Euca2ools 3.0 is huge in Eucalyptus 3.3.x. It has been completely ported to requestbuilder. Euca2ools 3 is slim and beautiful and it works!

One interesting fact about Euca2ools from the developers,

% git diff –shortstat 2.1.3.. — bin euca2ools
432 files changed, 14973 insertions(+), 15097 deletions(-)

euca2ools 3 adds three entirely new services and tons of new
functionality to the previous version, but it still manages to weigh
in at less code than it had before.

Read more about euca2ools 3, “What’s new in Euca2ools 3” Part 1 and Part 2.

With all these new features, Eucalyptus 3.3.0 has many bug fixes as well. There are many others documented/undocumented fixes are coming in 3.3.0. Some administrator tool are also on the way to see the light very soon.

If you are interested in trying from source code, you are more that welcome to checkout Eucalyptus from the public github repository.

Some places to give you feedback:

Bug report: