Running SQL Server on an Azure Virtual Machine

A cloud VM still needs a database administrator. Running SQL Server on an Azure virtual machine keeps familiar instance control, but the disks, host limits, and recovery paths are different. Treat the VM as a new platform, not a lifted server with a new address.

Know What You Still Own With SQL Server on an Azure Virtual Machine

SQL Server on an Azure virtual machine is self-managed SQL Server. You remain responsible for engine configuration, patch planning, database backups, restore tests, query tuning, and security. Azure manages the underlying physical host, while the VM guest and its database remain your operating environment. Registration with the SQL IaaS extension can expose useful management features.

I begin by listing who owns each patch and backup. Ambiguity here is more dangerous than an imperfect disk setting. The cloud portal can show a healthy VM while SQL Agent jobs fail or log backups stop. Application health must be measured above the infrastructure status.

Size the Azure Virtual Machine for SQL Server From the Workload

VM size defines vCPU, memory, and limits on disk throughput and IOPS. A database can be storage-bound long before CPU looks busy. Match peak CPU, active memory, log writes, and backup bandwidth to a candidate size. Include growth and failover capacity. Different VM families favor different resource balances.

I test the real query mix, not a synthetic disk benchmark alone. A small VM with fast disks can still be capped by its VM-level storage limit. A larger VM can increase costs without fixing a blocked query. Read the current size limits for the selected Azure family during planning.

Separate Data, Log, and tempdb Needs

Data files need mixed read and write performance. Log files need consistent low-latency sequential writes. tempdb sees spills, version store, and temporary objects. Map each path to appropriate disks and monitor file-level latency. Separate drive letters are useful only when the backing resources or policies differ.

The Azure VM offers several disk choices and temporary local storage on certain sizes. Temporary storage is not durable and must never be the only home for user database files or logs. tempdb can use a suitable temporary path when its recreation and startup behavior are designed correctly.

Set Disk Caching Deliberately

Host caching options affect read and write behavior by disk type and workload. Data disks can benefit from read caching in some designs. Log disks need a write-safe setting and should follow current Azure SQL Server VM guidance. Never copy a caching rule from a different disk generation without checking support.

I compare file-level stalls before and after a cache change. The setting belongs in the deployment record so a rebuilt VM does not silently differ. A fast first read from a cache is nice, but a reliable commit under load is the goal.

Inspect File-Level I/O

This query reports cumulative I/O and stalls for database files. Capture two samples during a known busy interval and compare deltas. It does not expose the full Azure storage path, so pair it with VM and disk metrics. Look at log writes and data reads separately.

A single average since restart can hide a recent storage incident. I keep timestamps with the samples and note backup or snapshot activity in the same window.

SELECT DB_NAME(v.database_id) AS database_name,
       m.type_desc, m.physical_name,
       v.num_of_reads, v.io_stall_read_ms,
       v.num_of_writes, v.io_stall_write_ms
FROM sys.dm_io_virtual_file_stats(NULL, NULL) AS v
JOIN sys.master_files AS m
  ON m.database_id = v.database_id
 AND m.file_id = v.file_id
ORDER BY v.io_stall_write_ms DESC;

Plan Backup to URL

SQL Server can back up databases to Azure Blob Storage through BACKUP TO URL with a correctly scoped credential. That can simplify off-VM storage, but it still needs retention, access control, encryption, and restore testing. VM snapshots and platform backups have different consistency and recovery properties. Know which method owns the transaction log chain.

I test a full restore to a separate environment before calling the backup plan complete. The backup destination must remain available if the VM or region fails. A successful backup message does not prove the application can be restored in time.

Review Growth and Initialization

Pre-size data, log, and tempdb files from observed demand. File growth can interrupt work, and log growth still requires initialization. Confirm instant file initialization for eligible data files through supported diagnostics and security policy. Watch free space at both Windows volume and Azure disk levels.

The query below lists file sizes and growth settings in the current database. It helps identify percentage growth and tiny increments before a busy period. Adjust settings only after understanding the expected workload and disk headroom.

SELECT name, type_desc, physical_name,
       size * 8.0 / 1024 AS allocated_mb,
       growth, is_percent_growth
FROM sys.database_files
ORDER BY file_id;

Measure Host and Guest Together

SQL Server sees schedulers, memory, waits, and file stalls. Azure metrics show VM and disk behavior outside the engine. Compare both views at the same timestamps. A VM can show moderate CPU while its disk throughput cap is reached. A query plan can waste reads even when the disks are performing correctly.

I ask for the Azure resource limits and SQL workload baseline in one review. Otherwise one team sees a healthy VM and another sees slow users. Both statements can be true. The shared timeline turns that disagreement into a diagnosis.

Test Recovery and Failover for SQL Server on an Azure Virtual Machine

Define how the VM, database, and application recover from a guest failure, disk issue, or regional outage. Availability sets, zones, AGs, and backups solve different problems. Check licensing and replica costs. Test the client reconnection path, Agent jobs, and backup continuation after transition.

Running SQL Server on an Azure virtual machine gives control, and control brings responsibilities. Keep the storage design, patch cadence, backups, and monitoring explicit. The VM is a platform choice, not a backup strategy or a performance setting by itself.

A recovery drill should include the VM and the SQL Server layer. Confirm that the operating system boots, storage attaches in the expected order, SQL Server starts, and application connections use the intended name. A backup that exists in Blob Storage is useful only when the team can restore it into a working instance with the required logins and jobs.

I document who owns each setting. Azure manages the physical host, while the team still owns guest patching, SQL Server configuration, backups, security, and performance diagnosis. The line is easy to blur when a dashboard shows a healthy VM. A healthy virtual machine can still hold an unhealthy database. Review SQL waits and file latency alongside host metrics before declaring the platform ready.

Can your team restore the database and reconnect the application on a fresh virtual machine without relying on the original guest?

Related reading on this blog: FIX: Cannot Connect to SQL in Azure Virtual Machine From Laptop and Setting Firewall Settings With Azure SQL Server VMs.

An Azure VM is not managed SQL Server, it is a familiar instance on a different operating platform.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.