Migrate an OpenStack Instance from HPC to HPC

Migrate an OpenStack Instance from HPC (Hosted Private Cloud) to HPC

Overview

This guide focuses on migrating a virtual machine (VM) or instance from one OpenStack cloud environment to another. The main challenge involves ensuring that the instance, its associated storage volumes, and network configurations are correctly replicated in the target cloud.
This only applies to Hosted Private Clouds, not EZ Clouds nor Virtual Private Clouds (VPC).

This process involves exporting from the source cloud's Ceph storage and importing to the destination cloud's OpenStack cluster.

Prerequisites

• Ensure Access to Source and Destination OpenStack Clouds:
  • Source and destination clouds must be running compatible versions of OpenStack and Ceph.
  • Source cloud needs access to Ceph via the rbd (RADOS Block Device) command-line tool.
  • Destination cloud needs access to OpenStack CLI.
• Preconfigured virtual environment with OpenStack CLI and pigz installed.

Considerations

• Data Consistency: Ensure the instance on the source cloud is powered off during the rbd export process to prevent data corruption.
• Downtime: This method involves downtime, as the instance will need to be stopped, exported, and recreated in the destination cloud.
• Bandwidth: Transferring large Ceph volumes between clouds may take time and require significant bandwidth.
• Automation: You can automate parts of this process using scripts to streamline the migration, especially if migrating multiple instances.

Steps to Migrate

1. Identify the Ceph RBD Image

   • Find the instance ID:
     openstack server show

      

   • Check which image or volume is attached to the instance:
     
     
     • For an image-backed instance:
       openstack server show -f value -c image
       
       
     • For a volume-backed instance:
       penstack volume show -f value -c os-vol-host-attr:host

        
     • Confirm the volume UUID chosen if it is for the boot drive.
       
       
   • Identify the Ceph RBD image:
     
     rbd ls

     
     
     

2. Export, Compress, and Transfer the Image in One Command

   • Use rbd, pigz, and ssh to export the image from Ceph, compress it, and transfer it directly to the destination cloud:
     rbd -p images export - | pigz -c --fast | ssh @ "pigz -cd > /opt/image.raw"
      

      

   Explanation:

   • rbd -p export -: Exports the RBD image from Ceph.
   • pigz -c --fast: Compresses the image.
   • ssh @ "pigz -cd > /opt/image.raw": Uses ssh to securely transfer the compressed image and decompress it directly on the destination cloud, saving it as image.raw.
     
     

3. Upload the Image to OpenStack on the Destination Cloud

   • Now that the image is decompressed, upload it to the OpenStack Image service on the destination cloud:
     openstack image create --file /opt/image.raw --disk-format raw --container-format bare
     
     
   • Replace with the name you want to assign to the uploaded image.
   • Ensure the disk format (raw in this case) matches your actual image format.
   • Verify the image upload:
     openstack image list
     
     
   • Set appropriate properties on the image to take advantage of advanced features:
     openstack image set --property hw_scsi_model=virtio-scsi --property hw_disk_bus=scsi
     
     

4. Create a New Instance from the Uploaded Image

   • Finally, create a new instance from the uploaded image:
     openstack server create --flavor --image --network
     
     
   • : The flavor to use for the instance.
   • : The name of the newly uploaded image.
   • : The network where the instance will be deployed.
   • : The name of the new instance.
     
     
   • Verify that the new instance is running:
     openstack server list
     
     

5. Re-Attach Volumes (Optional)

   • If the instance had additional volumes attached in the source cloud, repeat the rbd export process for those volumes, upload them to the OpenStack Image service as images, and then recreate or attach them to the new instance.
   • Ensure that the network and flavor configurations in the destination cloud match or are compatible with those in the source cloud.
   • If the instance uses a specific security group, keypair, or volume, make sure those resources are properly configured in the destination cloud before launching the instance.