Some users have run into problems while installing Rocks or Eucalyptus

• Solution: We are working on making Eucalyptus installation more robust and easier to diagnose. Please, consult Rocks support resources for help with Rocks installation.

• Instances with identical IDs may appear in different reservations
  • Solution: Will be fixed in v1.2.

• VDE creates many temporary subdirectories and files
  • Solution: Delete the files manually. Will be fixed in v1.2.

• Eucalyptus loses track of instances that are terminated before they fully booted.
  • Solution: Restart the node controller on the compute nodes with runaway instances. The problem will be fixed in v1.2.

• Parsing of large config files (with many nodes) fails.
  • Solution: Will be fixed in v1.2.

• Startup of large instances takes long
  • Solution: The problem is alleviated in v1.2 with introduction of disk image caching

• Some instances may appear to be stuck indefinitely in a non-running state, such as "pending" or "terminated".
  • Solution: Execute (as administrator or as the owner of the instance) ec2-terminate-instance on it.

• Rarely, eucalyptus processes may be left running even after the init script has finished stopping the system (eucalyptus stop).
  • Solution: Search for eucalyptus processes (any process with the string 'euca' contained in the command line) and kill them manually (e.g., pkill -9 -f euca).

• Eucalyptus log-files can grow large (we estimate several hundred megabytes per week).
  • Solution: Stop eucalyptus, remove or back up the log files (/opt/eucalyptus-1.1/var/log/eucalyptus/*), and restart eucalyptus.

• Rarely, a 'vdekey' is created that causes the vde_cryptcab listener process to fail, which will prevent private network instance connectivity from functioning properly.
  • Solution: Stop eucalyptus (on all front-end and node systems), regenerate the vdekey on the front-end using the command (ssh-keygen -t rsa1 -b 768 -f /opt/eucalyptus-1.1/var/eucalyptus/keys/vdekey -N ""), restart eucalyptus on the front-end, and finally restart eucalyptus on the nodes.

• Deploying Eucalyptus on a single machine does not work.
  • Solution: Select a different port for NC and CC. Will be fixed in v1.2.

• ec2 command-line tools fail with "Server: An error was discovered processing the <wsse:Security> header. (WSSecurityEngine: Invalid timestamp The security semantics of message have expired)"
  • Solution: Ensure that the clocks on the client and server machines are synchronized. This is not a Eucalyptus bug, but a consequence of the security policy enforced by the ec2 command-line tools.