Planning a Migration to Rackspace OpenStack Flex

This guide walks you through the key considerations, preparations, and common pitfalls when migrating data and workloads from a remote Linux VM on another platform (on-prem, cloud, etc.) to a new OpenStack Flex virtual machine.

1. Planning Your Migration

Understand the Source Environment

Before you move anything, it's critical to assess your source environment. The source environment is the location where the data resides currently - where you will be migrating from. Consider the following:

• Workloads in Use: Files, databases, apps, cron jobs, background services, etc.
• System Configuration: OS versions, installed packages, user accounts, and customization.
• Network Restrictions: Can your source system reach the OpenStack VM via SSH/SCP/SFTP?

Understand the OpenStack Flex Destination Environment

You’ll be working within your project in OpenStack Flex. Since this is a multi-tenant shared environment you won’t be able to access the underlying infrastructure such as the hypervisor, network, or storage backend. What you'll need to focus on is the following:

Key things to know:

• You provision and manage VMs via the self-service interface called Skyline .
• You can:
  • Choose OS images and VM types (from a predefined list)
  • Assign Floating IPs for external access
  • Manage your own SSH keys
  • Use volume based storage
• You cannot:
  • Customize networks beyond project-level isolation
  • Use nested virtualization
  • Use Admin APIs to manage underlying infrastructure or projects not your own

2. Security & Access Considerations

• SSH Key Pair : Most OpenStack environments require you to associate an SSH key pair at VM creation time. This is not a requirement as password authentication can be selected - but is not recommended.
• Firewall Rules (Security Groups ): Ensure inbound ports (e.g., SSH, RDP, application ports) are allowed.
• Floating IPs: Assign a public IP if your destination VM or Load Balancer must be reachable from the internet.

If you can’t connect directly between source and destination (e.g., firewalls block direct SSH), you may need to:

• Use an intermediate staging server
• Push data from source to the OpenStack Flex VM
• Pull data from the OpenStack Flex VM using tools like scp or rsync with NAT-friendly flags

3. What Should Be Migrated?

It's critical to know what should and shouldn't be migrated. You do not want to just blindly copy everything from a VM onto another VM and overwrite the destination. This will likely lead to unintended consequences and problems. Instead, migrate only the essential and required data to the new environment. Below is a list to help you think through data that may need to be moved.

4. Preparing the OpenStack Flex VM

If you haven't already provisioned your OpenStack Flex VM(s) on the destination, be sure to consider these before building out the destination devices:

• Choose the Right Flavor (CPU, RAM, Disk)
• Pick a Compatible OS Image (ideally similar to source)
• Attach any necessary Volumes (for persistent storage)
• Enable Security Group Rules for SSH (22/tcp) or RDP (3389/tcp)

5. Migration Approaches

Because you'll be migrating into the OpenStack Flex ecosystem you may need to rely on file-based migration methods:

Common Data Migration Options:

• rsync over SSH: Good for structured, incremental transfers.
• SCP/SFTP: Simple, but not ideal for very large data sets.
• Compressed Archives (tar, zip): Good for packaging and reducing transfer size.
• Database dumps: Use tools like mysqldump, pg_dump, then transfer and restore.
• Rackspace Backup Agent: This tool was designed for use in our original Rackspace OpenStack Public Cloud - but can be installed on another VM like an OpenStack Flex VM. After configuring the Backup Agent on the Flex VM with your Rackspace Cloud username/API key it will create a listed System and Destination for restores - as well as making OpenStack Flex able to back up data to OSPC's Cloud Files (egress data is billed on OSPC though). You just need to be sure that when you are running the configuration command you set the --flavor to dedicated rather than raxcloudserver.

If source and destination VMs are not routable to each other, consider transferring data through your local workstation or using a cloud storage service (if allowed by your organization).

Snapshot Migration Options:

The OpenStack Flex environment you're migrating to uses KVM hypervisors, which support virtual machine disk images in the following formats:

• QCOW2 (recommended): Offers features like compression, snapshots, and copy-on-write performance. Ideal for most workloads.
• RAW: A simple, unstructured format. Offers slightly better performance in some cases but consumes more space.
• ISO: Primarily used for installation media or live CDs, not for full VM disks.

If you're migrating a complete VM image (rather than just data and workloads), ensure your image is in one of these supported formats. When preparing a custom image to upload to OpenStack:

• Convert your disk image using tools like qemu-img if needed.
• Strip platform-specific drivers or agents that may conflict
• Ensure the image is compatible with KVM

You can upload your image file into your OpenStack Flex project under the Compute > Images > 'Create Image' section of the Skyline UI.

NOTE: Imported Snapshots cannot be fully supported by Rackspace technical support in all cases due to the wide range of potential changes brought along from other platforms.

6. Downtime and Syncing

If migrating live services or active databases you'll want to plan for downtime:

• Schedule a final downtime window for:
  • Stopping services
  • Performing a last sync or data dump
  • Swapping DNS or IP mappings
• Use read-only mode (if supported) to minimize data changes during transfer. This will help ensure that data is not corrupted or partially captured.
• It is critical that you keep your source platform up and running until you've completely validated that everything is working well on the OpenStack Flex destination.

7. Common Issues in Public Cloud Migrations

8. Validation and Post-Migration Steps

After the migration:

• Verify service functionality (apps, daemons, web interfaces)
• Check file ownerships and permissions
• Test application logic and scheduled jobs
• Update DNS records or service endpoints
• Enable backups and monitoring in the new environment

Consider running the new VM alongside the old one briefly as a fallback.

Summary Checklist

Final Advice

• Test the process with a non-critical VM or small workload first.
• Try building out and migrating to a development environment first.
• Do NOT delete resources on your source platform until you've successfully moved and tested on the destination.
• Automate common steps (e.g., user setup, package install) with scripts.