FAQs

No. Eucalyptus supports Amazon's interface syntactically and it implements the same functionality (with a few exceptions), but internally it is almost certainly different. Eucalyptus was originally designed to be extensible and easy to install and maintain, particularly in a research environment, where system administrator time is the most expensive commodity. While we can't be certain, Amazon's main design goal almost has to be scalability. Put another way, if we were to design a commercial software venue for cloud services where scalability in terms of the number of users is paramount and we could mandate how all clusters within the cloud were initially configured (instead of an open-source software tool for community distribution) we would have designed Eucalyptus differently.

The intention is to be able to support multiple cloud computing interfaces using the same "back end" infrastructure. Amazon seemed to be the best documented of the available choices at the time we began development and also the most commercially successful so we chose to implement it first. The interface module, however, can be replaced without changing the rest of the system (we hope).

At present, yes, although it originated as a university research project in the Computer Science Department, at the University of California Santa Barbara. The original authors of Eucalyptus who were researchers in the MAYHEM research group at UCSB have co-founded Eucalyptus Systems Inc. as an open-source commercial effort to maintain the software. Eucalyptus Systems offers commercial professional services and product development as a way of supporting the open-source core system. The intention is to continue to release feature enhancements and bug fixes to the open-source community through Eucalyptus Systems.

No. In a commercial cloud, clients pay for their use with a credit card. Eucalyptus is designed to work in an environment where machines are available to a user community that accesses them via logins. Because user accountability usually must be ensured by the system administrators in such an environment, we have developed a "cloud administrator" interface for Eucalyptus that is more analogous to common practice in a setting without fees.

Cloud users must register with the cloud administrator using a Web-based sign-up page. The cloud administrator receives an email message requesting approval whenever a potential user requests access. The message contains links for approving or denying the request. The decision of the administrator is communicated to the requester via email. In the case of approval, the user will be able to obtain from a password-protected Web page the cryptographic certificates necessary for using Eucalyptus.

Eucalyptus targets Linux systems that use Xen (versions 3.*) for virtualization. We provide binary RPMs for i386 and x86_64 RPM-based systems, Debian packaging, packaging for Ubuntu in both binary and source form and also offer a source package as well for installation on other common Linux distributions.

Eucalyptus v1.5 has been packaged for inclusion in the 9.04 Jaunty Jackalope release of Ubuntu in the Universe archive. This particular packaging effort is distinct from the other distribution packages we provide for Eucalyptus in that for Ubuntu 9.04 all of the dependencies upon which Eucalyptus depends are included in the distribution and these dependencies build from source. The other Eucalyptus packages (CentOS, openSUSE, Debian, etc.) do not include source builds for all dependencies and hence are considered binary packages.

Because Eucalyptus uses a combination of technologies, this packaging effort was quite manpower intensive, requiring a considerable commitment from the Ubuntu maintainers and developers who work for Canonical -- the commercial entity that supports Ubuntu. We are thrilled to be working so closely with Ubuntu and Canonical to make Eucalyptus available and we look forward to engaging the open-source community at large in expanding this effort.

No. Support for KVM is an addition to Eucalyptus. We will continue to support both Xen and KVM going forward.

The SLAs (Service Level Agreements) implemented by the cloud controller are bare-bones simple. Our intention is for Eucalyptus sites and development teams to come up with their own (we have a few in mind we'd like to try) but in the current release, the simple SLAs supplied enforce no restrictions on occupancy duration. This type of SLA is comparable to the Amazon SLA with the exception that Amazon's will "time out" when charges to the registered credit card are no longer postable.

We have implemented no such time out analogy at present, so if users or the cloud administrator do not terminate running instances, eventually Eucalyptus will run out of VM slots to allocate. In this case, user requests fail and the EC2 tools report no instances available when the command "ec2-describe-availability-zones" is invoked.

Amazon implements "availability zones" to allow users some degree of control over instance placement. Specifically, EC2 users can choose to host images in different availability zones if they wish to try and ensure independent failure probabilities. Amazon, presumably, takes steps to insulate instances in separate availability zones from correlated failure (e.g., a single power outage that takes out a data center).

Under Eucalyptus, the abstraction is slightly different. Each availability zone corresponds to a separate cluster within the Eucalyptus cloud. The advantage is that the networking within a single availability zone can be made much faster (i.e., it uses the cluster's private network in native mode). For allocations that span clusters, the technology Eucalyptus uses to implement a private network for each allocation imposes a substantial performance penalty.

Thus the two are similar in that cloud allocations to separate availability zones do reduce the chance of correlated failure. They are different, however, in that under Eucalyptus, each availability zone is restricted to a single "machine" (e.g., cluster) where at Amazon, the zones are much broader.

For the moment, we are restricting external development contributions for Eucalyptus internals to bug fixes. It is just too complicated to try and keep the code base stable with external developers when we are in this early phase of development. But we will gladly accept patches that fix bugs. To help us in this way, please visit our Contributors page for details on how to get your fixes to us. After we have completed a full implementation of Eucalyptus version 1.X (slated for the end of August of 2009) we will begin to incorporate potential contributions to the core. At this point we plan to go to a release schedule that is far less aggressive than the one we have been using.

However there are other ways to contribute to Eucalyptus that we certainly wish to encourage before we open the core. In particular, any tools you'd like to develop that use Eucalyptus without modifying its internals it are welcome. We will create a page with a short description of your project and add a link to it.

Our plan is to attempt to finish the baseline AWS interface (EC2/S3/EBS) by summer of 2009. To get there, we plan a series of major and minor releases. While this plan continues to evolve, as of early May, our roadmap is as follows. Version 1.5 (v1.5) was released with Ubuntu on 4/23/09. We released a minor release that improves a few things we discovered since 1.5 froze, as v1.5.1 on May 8, 2009. We plan at least one more minor release to the 1.5 series (v1.5.2) which will consist mainly of bug fixes. Our hope is to have this minor release available in mid June. If this release turns out to be the last 1.5 series minor release, we will try for another major release (v1.6) for the end of August and (hopefully) this will be the last feature release for version 1.X.

Our release nomenclature, at present, is as follows. Minor releases fix bugs but make no significant changes to the supported feature set or to the internal data structures. Major releases are feature releases and often involve a major refactoring of one or more internal Eucalyptus subsystems.

We recommend that you first check the Troubleshooting page.

If none of that seems to apply to you, feel free to post a question in the Discussion Forum, explaining your problem in as much detail as possible.

• For example, if you're having difficulty running instances, then relevant excerpts from logs produced by the Cloud Controller (cloud-debug.log), the Cluster Controller (cc.log), and a Node Controller (nc.log) from the $EUCALYPTUS/var/log/eucalyptus directory are usually helpful.
• If you're having difficulties with the networking, please, be sure to submit to consult the Networking page and describe your network configuration as much as possible.

As of v1.4, Eucalyptus images are synonymous with images used by Xen, which are disk partitions. If you can use an image/kernel/ramdisk combination with Xen, then you should be able to get it to work with Eucalyptus. (In fact, we recommend testing the image/kernel/ramdisk combination before going through the bundle/upload process.)

The convention used on EC2, which Eucalyptus follows, is that the VM can expect three SCSI disks in the following arrangement:

• sda1: root partition (that is where the EMI is attached)
• sda2: "ephemeral" partition (for additional storage)
• sda3: swap partition

You can either change your root partition to follow that layout (this is the recommended approach) or you can modify the Eucalyptus script that determines VM parameters such as disk layout (gen_libvirt_xml). With that in place, any Xen image should work.

If there is an AMI that you'd like to try in Eucalyptus, you need to be able to download and unbundle it. Next you need to find the kernel/ramdisk combination that will work with that image as one cannot download kernels from EC2. Again, we recommend getting this to work with Xen outside Eucalyptus first.

See the following forum threads for more information:

• Amazon machine images
• Making EMI from AWS instance

You can but some features will not be available.

• Only SYSTEM and STATIC network modes will work (with all the limitations of the 2 modes).
• EBS interface support will not be available.

There is no need to synchronize the keys with the node (since there is only one NC and it's local).

Very likely, you are running Euca2ools against the version of Eucalyptus downloaded from the Ubuntu Jaunty repositories. This version is Eucalyptus v1.5.0. Euca2ools require at least v1.5.2. Please refer to Eucalyptus on Ubuntu Jaunty community wiki for instructions on using Eucalyptus downloaded from Ubuntu Jaunty. Or alternatively, you can upgrade to Eucalyptus v1.5.2.