Planning a Migration to OpenStack Flex
Migrating your data and workload to the Rackspace OpenStack Flex platform
Guide to Migrating Data & Workloads to a New VM in an 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
- Install kernel modules or use nested virtualization
- Use admin APIs or shared storage (e.g., NFS across tenants)
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 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.
Component | What to consider |
---|---|
Application files | Are they portable? Do they need specific directory paths or users? |
Databases | Dump and transfer, or export via tools. Match DB engine versions. |
User accounts | May need to recreate users with the same UID/GID if permissions matter |
Cron jobs | These are not migrated automatically—recreate manually |
Services/Daemons | Ensure dependencies and config files are installed on new system |
Scripts/Automation | Confirm any scripts that reference IPs, paths, or platform-specific features are updated |
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.
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
Issue | Risk |
---|---|
UID/GID Mismatches | Files may become inaccessible if permissions break |
Firewalls/SGs block traffic | SSH or RDP won't work until you allow ports |
Wrong SSH key setup | Lock yourself out of VM if you forget to upload keys |
Missing software packages | App may break if dependencies aren't reinstalled |
OS image differences | Some system paths or behaviors may differ from source |
Private IP conflicts | Don’t assume your new VM has the same IPs as the old one |
Timezone differences | Can affect cron jobs and logs |
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
Task | Description | Status |
---|---|---|
Document source services | List what's running and what's needed | ☐ |
Provision OpenStack VM | Use correct image, flavor, and SSH key | ☐ |
Configure access & security groups | Open necessary ports, assign floating IP | ☐ |
Transfer data | Use rsync, SCP, or archive + restore | ☐ |
Install dependencies | Rebuild software stack, user accounts | ☐ |
Verify & test services | Application-level testing and logs | ☐ |
Final switch | Update DNS, shutdown old VM (if needed) | ☐ |
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.
Updated about 7 hours ago