Migrate from Azure virtual machines to Quake AI compute

This guide covers migrating compute workloads from Azure VMs to Quake AI (OpenStack Nova). Azure supports VHD disk export via SAS URL, which can be converted to QCOW2 and uploaded to Glance. For most workloads, rebuild and rsync is still faster and simpler. Image export is practical for custom Azure images that are difficult to rebuild.

Service mapping#

Prerequisites#

• A Quake AI account with application credentials
• The OpenStack CLI installed and configured
• SSH access to your Azure VMs
• An SSH key pair imported to Quake AI (openstack keypair create --public-key)
• For image export: az CLI installed, azcopy for large downloads, and qemu-img for VHD→QCOW2 conversion

Image portability#

Azure managed disks can be exported as VHD files via a time-limited SAS URL. The VM must be stopped and deallocated for a consistent disk state.

# Stop and deallocate the VM (a single command does both)
az vm deallocate --resource-group MY_RESOURCE_GROUP --name MY_VM

# Generate a SAS URL for the OS disk (36000 seconds = 10 hours)
az disk grant-access --resource-group MY_RESOURCE_GROUP \
  --name MY_OS_DISK \
  --duration-in-seconds 36000 --access-level Read

# Download using AzCopy (faster than browser download)
azcopy copy "GENERATED_SAS_URL" ./my-vm.vhd

# Convert VHD to QCOW2
qemu-img convert -f vpc -O qcow2 my-vm.vhd my-vm.qcow2

# Upload to Glance
openstack image create "my-azure-image" \
  --disk-format qcow2 --container-format bare \
  --file my-vm.qcow2

When to use image export: For custom Azure images with significant baked-in software or proprietary configuration. The stop-export-convert-upload pipeline is reliable but slow. For standard OS images, use Quake AI public images and rebuild.

Flavor mapping#

Azure VM series map to Quake AI flavor families by their RAM-to-vCPU ratio. D-series (general purpose, 4:1) maps to m2a, E-series (memory optimized, 8:1) maps to r2a, and F-series (compute optimized, 2:1) maps to c2a. B-series (burstable) maps to s1a for small workloads like Standard_B2s, but larger B-series VMs with a 4:1 ratio like Standard_B4ms map to m2a. Match by ratio: a 4:1 B-series VM targets m2a rather than s1a.

Azure's naming convention is less direct than other providers. The family ratios follow common conventions and map to Quake AI flavor families.

Migration approach#

Option 1: Containerized workloads (recommended)#

If your Azure VMs run containers (or you use AKS), migrate container images and redeploy.

1. Push images from Azure Container Registry to a portable registry:

docker pull MY_REGISTRY.azurecr.io/MY_APP:latest
docker tag MY_REGISTRY.azurecr.io/MY_APP:latest \
  registry.example.com/MY_APP:latest
docker push registry.example.com/MY_APP:latest

1. Provision a Nova instance on Quake AI:

openstack server create \
  --image "Ubuntu-22.04" \
  --flavor m2a.xlarge \
  --network MY_NETWORK \
  --key-name MY_KEY \
  --security-group MY_SECURITY_GROUP \
  MY_INSTANCE_NAME

1. Install Docker and deploy:

ssh ubuntu@FLOATING_IP
sudo apt update && sudo apt install -y docker.io
sudo docker pull registry.example.com/MY_APP:latest
sudo docker run -d -p 80:8080 registry.example.com/MY_APP:latest

Option 2: Rebuild and rsync (non-containerized)#

1. Provision a Nova instance with the same base OS:

openstack server create \
  --image "Ubuntu-22.04" \
  --flavor m2a.xlarge \
  --network MY_NETWORK \
  --key-name MY_KEY \
  --security-group MY_SECURITY_GROUP \
  MY_INSTANCE_NAME

1. Assign a floating IP:

openstack floating ip create PublicStatic
openstack server add floating ip MY_INSTANCE_NAME FLOATING_IP

1. Install your application stack. Reuse cloud-init configs, ARM templates as reference, or configuration management playbooks.

2. Transfer application data:

rsync -avz --progress -e "ssh -i ~/.ssh/MY_KEY" \
  MY_USER@AZURE_PUBLIC_IP:/path/to/app/data \
  ubuntu@FLOATING_IP:/path/to/app/data

1. Migrate databases:

pg_dump -h AZURE_PUBLIC_IP -U MY_USER MY_DATABASE | \
  psql -h FLOATING_IP -U MY_USER MY_DATABASE

Key pair and security setup#

Import your SSH key#

openstack keypair create --public-key ~/.ssh/id_ed25519.pub my-key

Translate NSGs to security groups#

Azure NSGs support both allow and deny rules with priority ordering, and can bind to subnets or individual NICs. Neutron security groups are allow-only, additive, and bind per port (per instance). If your security posture relies on deny rules, subnet-level NSGs, or priority ordering, rethink the logic for a per-instance additive model.

openstack security group create web-tier
openstack security group rule create web-tier \
  --protocol tcp --dst-port 22 --remote-ip 0.0.0.0/0
openstack security group rule create web-tier \
  --protocol tcp --dst-port 80 --remote-ip 0.0.0.0/0
openstack security group rule create web-tier \
  --protocol tcp --dst-port 443 --remote-ip 0.0.0.0/0

Validation checklist#

After migrating each workload, verify:

• Application responds correctly on the Quake AI instance
• All expected ports are accessible through the security group
• Data integrity: compare file checksums or row counts between source and destination
• Database connectivity from the application to any migrated databases
• DNS records updated to point to the new Quake AI floating IP
• Monitoring in place (self-managed Prometheus + Grafana to replace Azure Monitor)
• cloud-init or configuration management runs cleanly on the new instance
• SSL/TLS certificates installed and renewed

Provider-specific gotchas#

See also#

• Migrating from Azure to Quake AI: full cross-service migration hub
• Coming from Azure: concept translation reference
• Create an instance: full instance provisioning workflow
• Compute migration guides: all provider guides