# Migrate from Azure Virtual Machines to Quake AI Compute Source: https://docs.quake.ai/docs/compute/migration/migrate-from-azure-vms Markdown: https://docs.quake.ai/docs/compute/migration/migrate-from-azure-vms.md --- # 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](/docs/tools/generate-app-credentials) - The [OpenStack CLI](/docs/tools/install-openstack-client) 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. ```bash # 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 ``` The VM must be stopped/deallocated during export: plan for downtime. Large VHDs (1 TB+) can take 4+ hours to download even with AzCopy. Windows images may have licensing constraints that prevent running on non-Azure clouds. **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 VM Size | vCPUs | RAM (GiB) | Quake AI Flavor | vCPUs | RAM (GiB) | Notes | |---|---|---|---|---|---|---| | Standard_B2s | 2 | 4 | s1a.medium | 2 | 4 | Burstable → shared | | Standard_B4ms | 4 | 16 | m2a.xlarge | 4 | 16 | Exact ratio match | | Standard_D2s_v6 | 2 | 8 | m2a.large | 2 | 8 | Exact ratio match | | Standard_D4s_v6 | 4 | 16 | m2a.xlarge | 4 | 16 | Exact ratio match | | Standard_D8s_v6 | 8 | 32 | m2a.2xlarge | 8 | 32 | Exact ratio match | | Standard_D16s_v6 | 16 | 64 | m2a.4xlarge | 16 | 64 | Exact ratio match | | Standard_D32s_v6 | 32 | 128 | m2a.8xlarge | 32 | 128 | Exact ratio match | | Standard_D64s_v6 | 64 | 256 | m2a.16xlarge | 64 | 256 | Exact ratio match | | Standard_E2s_v6 | 2 | 16 | r2a.large | 2 | 16 | Exact ratio match | | Standard_E8s_v6 | 8 | 64 | r2a.2xlarge | 8 | 64 | Exact ratio match | | Standard_E16s_v6 | 16 | 128 | r2a.4xlarge | 16 | 128 | Exact ratio match | | Standard_F2s_v2 | 2 | 4 | c2a.large | 2 | 4 | Exact ratio match | | Standard_F8s_v2 | 8 | 16 | c2a.2xlarge | 8 | 16 | Exact ratio match | 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: ```bash 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 ``` 2. Provision a Nova instance on Quake AI: ```bash 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 ``` 3. Install Docker and deploy: ```bash 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: ```bash 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 ``` 2. Assign a floating IP: ```bash openstack floating ip create PublicStatic openstack server add floating ip MY_INSTANCE_NAME FLOATING_IP ``` 3. Install your application stack. Reuse cloud-init configs, ARM templates as reference, or configuration management playbooks. 4. Transfer application data: ```bash 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 ``` 5. Migrate databases: ```bash pg_dump -h AZURE_PUBLIC_IP -U MY_USER MY_DATABASE | \ psql -h FLOATING_IP -U MY_USER MY_DATABASE ``` Azure bills egress per GB, with a monthly free allowance before metered rates apply. Azure offers egress waivers for customers migrating away under cloud-switching provisions: contact Azure support to request one. For current rates and the free allowance, see the [Azure bandwidth pricing page](https://azure.microsoft.com/en-us/pricing/details/bandwidth/). ## Key pair and security setup ### Import your SSH key ```bash 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. ```bash 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 ``` Azure's dual NSG layer (subnet-level + NIC-level) collapses to a single port-binding model on Quake AI. See the [network migration guide](/docs/network/migration/migrate-from-azure-vnet) for full NSG translation patterns. ## 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 | Topic | Detail | |---|---| | Archive tier rehydration | Standard priority rehydration takes up to 15 hours; high priority can complete in under one hour at a higher cost. An early-deletion fee applies if objects leave the Archive tier before 180 days. Plan for this if migrating Azure Blob Storage alongside compute. | | Windows Server licensing | BYOL from Software Assurance is required. Cloud-only Windows licenses are provider-locked. Microsoft licensing terms restrict some cloud-to-cloud VM transfers. | | VHD download time | Large managed disks (1 TB+) can take 4+ hours to download even with AzCopy. Schedule accordingly. | | NSG deny rules | Azure NSGs support allow+deny with priority. Rethink deny-based security posture for Neutron's allow-only model. | | Entra ID (Azure AD) | No Quake AI equivalent. Application authentication must switch to [OpenStack application credentials](/docs/tools/generate-app-credentials) or an external IdP. | | Managed Identities | Azure VMs can use system-assigned or user-assigned Managed Identities to authenticate to Azure services without stored credentials. No Quake AI equivalent. Switch to [OpenStack application credentials](/docs/tools/generate-app-credentials) or external secrets management. | | AKS workloads | AKS → self-managed K8s is the most complex migration. See the [Kubernetes migration guide](/docs/kubernetes/migration/migrate-from-aks). | ## See also - [Migrating from Azure to Quake AI](/resources/migration/from-azure): full cross-service migration hub - [Coming from Azure](/resources/migration/coming-from-azure): concept translation reference - [Create an instance](/docs/compute/how-to/create-instance): full instance provisioning workflow - [Compute migration guides](/docs/compute/migration): all provider guides