Skip to main content
IMHCloud Logo
Back to support home

How to Create QA Environments Using OpenStack Snapshots

Deploying code changes directly to production is risky. OpenStack snapshots let you clone a production instance into one or more isolated QA environments in minutes, so you can test safely before any changes go live.

This guide walks through two approaches for accessing a snapshot-based QA environment:

  • Method 1 (Host File): Local testing with no DNS changes required. Best for quick, personal testing.
  • Method 2 (Subdomain): A real subdomain pointing to your QA instance. Best for team review or demonstrating changes to stakeholders.

Prerequisites

  • A running production instance in InMotion Cloud
  • SSH key pair associated with the instance
  • Access to Horizon (Project dashboard)
  • For Method 2: ability to create a DNS A record on your domain

Step 1: Create a Snapshot of Your Production Instance

  1. Navigate to Project > Compute > Instances in Horizon.
  2. Find your production instance in the list.
  3. Click the dropdown arrow at the far right of that row.
  4. Select Create Snapshot.
  5. Enter a descriptive name (e.g., wordpress-production-snapshot).
  6. Click Create Snapshot.

Horizon redirects you to Project > Compute > Images once the snapshot is queued. Wait until the image status shows Active before proceeding.

Note: The snapshot image may show a size of 0 bytes in Glance. This is expected behavior when the instance boots from a Cinder volume. The actual data resides in a Cinder volume snapshot referenced by the image. The image will still launch correctly.

Step 2: Launch a New Instance from the Snapshot

  1. Navigate to Project > Compute > Images.
  2. Find the snapshot you just created.
  3. Click Launch on that row.
  4. Configure the instance:

    Instance Name: QA Environment 1 (or QA Environment 2)
    Source: The snapshot image
    Flavor: Same as production (e.g., gen2.small)
    Network: Same network as production
    Key Pair: Your SSH key pair
    Security Groups: default + custom security group that opens ports 22, 80, and 443
  5. Click Launch Instance.
Common pitfall: When launching from a snapshot, Horizon does not automatically carry over the original instance's security groups. Always manually add the correct security groups. If you skip this step, SSH (port 22) and HTTP (port 80) traffic will be blocked and the instance will appear unreachable.

Once launched, find the new instance under Project > Compute > Instances and note its assigned IP address.

Step 3: Update the QA Instance Configuration

After booting, the new instance is an exact copy of production. Any environment-specific settings (such as site URLs or environment labels) must be updated to reflect the QA context.

SSH into the QA instance from your local machine:

1ssh ubuntu@<QA_IP>

Update your application's environment settings as needed. For example, if running WordPress, update the site URL:

1sudo -u www-data wp option update siteurl 'http://<QA_IP_OR_DOMAIN>' --path=/var/www/html/wordpress
2sudo -u www-data wp option update home 'http://<QA_IP_OR_DOMAIN>' --path=/var/www/html/wordpress

Method 1: Access QA via Hosts File (Local Testing)

The hosts file on your local machine overrides DNS for specific domain names. You can map a domain to your QA instance's IP without making any DNS changes, so the same domain resolves differently on your machine than it does for everyone else.

Windows

  1. Open Notepad as Administrator (search Notepad > right-click > Run as administrator).
  2. Open C:\Windows\System32\drivers\etc\hosts.
  3. Add a line at the bottom:
1<QA1_IP>    wordpress.local
  1. Save the file.
  2. Open your browser and navigate to http://wordpress.local.

Mac / Linux

1sudo nano /etc/hosts

Add:

1<QA1_IP>    wordpress.local

Save and exit (Ctrl+O, Enter, Ctrl+X), then visit http://wordpress.local in your browser.

Your browser now resolves wordpress.local to the QA instance. The domain is available only on your local machine. No one else is affected.

To remove the override, delete or comment out that line from the hosts file.

Method 2: Access QA via Subdomain (Real-World Access)

A dedicated subdomain makes the QA environment accessible to anyone with the URL, not just your local machine. This mirrors how QA environments are used in real customer deployments.

Create the DNS A Record

In your DNS provider's control panel, create an A record:

Type: A
Name: qa
Value: <QA2_IP>
TTL: 300

This makes qa.yourdomain.com resolve to your QA instance's IP.

Allow a few minutes for DNS propagation, then verify:

1dig +short qa.yourdomain.com

The output should return your QA instance's IP address.

Update WordPress to Use the Subdomain

SSH into the QA2 instance and update the site URL:

1sudo -u www-data wp option update siteurl 'http://qa.yourdomain.com' --path=/var/www/html/wordpress
2sudo -u www-data wp option update home 'http://qa.yourdomain.com' --path=/var/www/html/wordpress

Verify the site loads:

1curl -s http://qa.yourdomain.com | grep -i "environment"

Verification

Once both environments are running, verify they are serving correctly with distinct configurations:

1# Production
2curl -s http://<PRODUCTION_IP> | grep "Environment"
3

4# QA1 (hosts file — run from local machine)
5curl -s http://wordpress.local | grep "Environment"
6

7# QA2 (subdomain — accessible from anywhere)
8curl -s http://qa.yourdomain.com | grep "Environment"

Each should return a distinct environment label, confirming the environments are isolated.

Example output from a verified working setup:

1Production: Environment: Production (IP: 173.231.195.144)
2QA1:        Environment: QA1 (IP: 173.231.195.158)
3QA2:        Environment: QA2 (IP: 173.231.195.154)

Troubleshooting

Instance is unreachable after launch (SSH or HTTP timeout)
The most common cause is missing security groups. Go to Project > Compute > Instances, click the dropdown next to the instance, and select Edit Security Groups. Add the security group that allows inbound TCP on ports 22, 80, and 443.

Snapshot image shows 0 bytes in Glance
This is normal for instances that boot from Cinder volumes. The image references a volume snapshot rather than storing raw data in Glance. The snapshot will launch correctly.

http://wordpress.local does not load
Confirm the hosts file entry is saved correctly and that HTTP (port 80) is open in the QA instance's security groups. The hosts file override only affects DNS resolution; the security groups still control whether traffic reaches the instance.

Subdomain resolves to the wrong IP
Run dig +short qa.yourdomain.com to confirm the A record. If DNS has not propagated, wait a few minutes and retry.

WordPress redirects to the old production URL
The siteurl and home options in the WordPress database still point to production. Run the wp option update commands from Step 3 to correct them.

Related Resources