Corporate Home Open Source Home
Syndicate content
Eucalyptus

Upgrading to Eucalyptus (1.4)

These are instructions for those who would like to upgrade to Eucalyptus 1.4 from earlier source-based or RPM-based installations of Eucalyptus. Both upgrade paths involve making a backup of the key state from the old installation. The last section of this document explains how to roll back to the previous installation using the backup.

1. Clean up Eucalyptus running state

  • Terminate all Eucalyptus instances
    ec2-terminate-instances ...      # (as admin)
    
  • Shut down Eucalyptus on all nodes.
    /etc/init.d/eucalyptus stop
    
  • Check for errant Eucalyptus processes on all nodes and kill them
    ps aux | grep euca
    kill -9 ...
    
    

2. Install Eucalyptus 1.4

Both source- and RPM-based installations can be upgraded:

  • Option A: Source-based installation upgrade:
    • Move away the old installation on the head-node and all compute nodes. E.g.:
      export EUCALYPTUS_OLD=/opt/eucalyptus-1.3
      mv /opt/eucalyptus $EUCALYPTUS_OLD
      
    • Follow the steps in the Source Code Installation section of the Administrator's Guide and, afterwards, return here.
    • Copy back the old database and keys (we assume that $EUCALYPTUS points to the new location, such as /opt/eucalyptus):
      cp $EUCALYPTUS_OLD/var/eucalyptus/db/eucalyptus.* $EUCALYPTUS/var/eucalyptus/db/
      rm $EUCALYPTUS/var/eucalyptus/db/*.lck
      cp $EUCALYPTUS_OLD/etc/eucalyptus/cloud.d/*.bks $EUCALYPTUS/etc/eucalyptus/cloud.d/
      
  • Option B: RPM-based installation upgrade:
    • Follow the steps in the RPM-based Installation section of the Administrator's Guide and, afterwards, return here.

3. Update the configuration

  • Edit eucalyptus.conf file on head node. Do not start with the old one, rather, copy over matching parts to new one. (If you updated an RPM-based install, the new configuration is in eucalyptus.conf.rpmnew while eucalyptus.conf contains your old one.) Specifically, copy over the values of the following variables:
    • *_PORT
    • NODES
    • INSTANCE_PATH
  • Note that the following parameters were renamed:
    • VNET_PUB_INTERFACE renamed to VNET_INTERFACE
    • VNET_DHCPDEAMON renamed to VNET_DHCPDAEMON
  • Due to dramatic changes in the virtual network implementation, there is, unfortunately, no simple way to convert the old network configuration to 1.4. We suggest that to set the remaining VNET_* variables appropriately you read the Network Configuration section of the Administrator's Guide and, afterwards, return here.
  • On each compute node, go over the config file, comparing it with the old one, same as with the head-node file. (Naturally, you are free to create a new config file for compute-nodes and rsync it with all the nodes.)
  • Start NCs, the CC, and the CLC. On all node do
    $EUCALYPTUS/etc/init.d/eucalyptus start
    
  • In a Web browser, load https://headnode:8443/ and log in as admin with your old password. User accounts should still be there, but not the images. In the new 'Configuration' tab:
    • Click 'Add Cluster' and fill out the fields (You can use host/port/name values from <cluster host="" port="" name="...."> in $EUCALYPTUS/etc/eucalyptus/cloud.d/eucalyptus.xml.)
    • Verify that the Walrus path is set to a reasonable path (this is where all images, kernels, ramdisks, and generic buckets will be stored).
  • Synchronize node keys
    $EUCALYPTUS/usr/sbin/euca_sync_key -c $EUCALYPTUS/etc/eucalyptus/eucalyptus.conf
    
  • Verify that the nodes are back up (if not, see the Troubleshooting section.)
    ec2-describe-availability-zones verbose
    

4. Re-import old images

Storage of disk images, kernels, and ramdisks has changed in 1.4 due to the introduction of Walrus, an S3-compatible bucket-based storage service. Instead of using euca add_image, these files are now added using standard EC2/S3 tools. To upgrade, the files will have to be re-added (and, hence, their EMIs will change!).

Note that if you made any changes to config.xml files of your images, you will have to re-integrate these changes into the Perl script named $EUCALYPTUS/usr/share/eucalyptus/gen_libvirt_xml which now generates the equivalent XML document for all images on-the-fly. Be sure to sync that script to all your nodes.)

cd (the registered images directory)
  • For each image in the registered images directory, add the kernel, the ramdisk (if any), and the root file system image. See Image Management section for more information.
cd (an image dir)
gunzip *
ec2-bundle-image -i (kernel image name) --kernel true -d .
Please peicfy a value for the arch [x86_64]: ENTER
...
ec2-upload-bundle -b (unique bucket) -m (kernel image name).manifest.xml
ec2-register (unique bucket)/(kernel image name).manifest.xml
IMAGE   eki-.......
  • If the image has a ramdisk, then:
    ec2-bundle-image -i (ramdisk image name) --ramdisk true -d .
    Please peicfy a value for the arch [x86_64]: ENTER
    ...
    ec2-upload-bundle -b (unique bucket 2) -m (ramdisk image name).manifest.xml
    ec2-register (unique bucket 2)/(ramdisk image name).manifest.xml
    IMAGE   eri-.......
    
ec2-bundle-image -i (disk image name) --kernel (eki-......) [--ramdisk (eri-......)] -d .
Please peicfy a value for the arch [x86_64]: ENTER
...
ec2-upload-bundle -b (unique bucket 3) -m (disk image name).manifest.xml
ec2-register (unique bucket 3)/(disk image name).manifest.xml
IMAGE   emi-......
  • Check that it is there:
    ec2-describe-images
    
  • repeat for other images

5. Clean up old disk state

Once you are confident that the new installation is working, delete the old state on disk.

rm -rf $EUCALYPTUS_OLD 
rm -rf (the template path)
rm -rf (the registration path)
rm /etc/defaults/eucalyptus    # (this is no longer used)

If you upgraded using RPM packages, delete on all nodes the backup of old state that was created during the upgrade:

rm /root/eucalyptus-pre1.4-rollback.tar

6. Rolling back to an earlier installation

  • Stop Eucalyptus 1.4 processes, if any, on all nodes
  • Option A: Rolling back source-based 1.4 upgrade:
    • Remove any files added during the failed upgrade. For example:
      rm -rf $EUCALYPTUS
      
    • Move back the old installation on all nodes:
      mv $EUCALYPTUS_OLD $EUCALYPTUS
      
  • Option B: Rolling back RPM-based 1.4 upgrade:
    • Remove the failed RPMs on all affected nodes (depending on the failure, you might have to use the --nopreun option)
      rpm -e eucalyptus-cloud eucalyptus-cc euca-httpd euca-axis2c euca-libvirt eucalyptus
      
    • Download and install the 1.3 RPMs on all nodes as discussed in the Administrator's Guide (it may be unnecessary to install euca-vde as it does not get removed during the upgrade). For example, on the front-end you can use:
      rpm -ivh eucalyptus-1.3-1.i386.rpm euca-httpd-1.0-1.i386.rpm eucalyptus-cloud-1.3-1.i386.rpm eucalyptus-cc-1.3-1.i386.rpm
      
    • Copy the old state saved during the upgrade process on all nodes:
      cd $EUCALYPTUS
      tar xvf /root/eucalyptus-pre1.4-rollback.tar
      
  • Start Eucalyptus, as before