SQL Server Always On on Proxmox VE: architecture and tuning

Availability Group or Failover Cluster Instance?

Always On is an umbrella term. An Availability Group (AG) replicates selected databases between SQL instances. A Failover Cluster Instance (FCI) protects a SQL instance and requires suitable shared or jointly provided storage. The approaches have different requirements. This example uses an AG with two Windows VMs.

• SQL edition and version determine available features. Standard Edition Basic Availability Groups are not equivalent to full Enterprise AGs.
• Separate virtual disks may still sit on the same SAN. Check which shared failure points are actually removed.

Plan hosts, quorum and listener together

Place replicas on separate physical hosts and check placement after maintenance and recovery too. The remaining host must carry the required load. Windows and Proxmox clusters each have their own quorum; Proxmox quorum does not replace WSFC planning.

• Validate WSFC and design an appropriate witness outside the shared failure domain being protected. A witness is not an additional database copy.
• Configure the listener, DNS, IP addresses, firewall and SQL endpoints together. The application should not depend on a fixed VM name.
• Assess synchronous commit for the required local availability. Automatic failover requires, among other things, the appropriate mode, a synchronised target replica and WSFC quorum. Asynchronous replication can lose data during forced failover.

Align Proxmox multiqueue and Windows RSS

If packet processing saturates individual vCPUs, VirtIO multiqueue may help. VM configuration and guest drivers must align. More queues are not a universal accelerator and increase CPU overhead. Test changes during a maintenance window because driver and adapter changes can interrupt connectivity.

Get-NetAdapterRss | Format-List *

• In Proxmox, edit the VirtIO network adapter, open advanced settings and set Multiqueue. The documentation gives the vCPU count as a starting value.
• In Windows Device Manager, open the Red Hat VirtIO Ethernet Adapter's Advanced settings, enable Receive Side Scaling and set Maximum number of RSS Queues appropriately. Check the driver version and available values.
• Example test: four vCPUs, four Proxmox queues and up to four RSS queues supported by the guest driver. Then check the effective state, not just the configured value.

Measure the bottleneck before further tuning

More queues do not automatically accelerate a single TCP stream. Compare CPU distribution, latency and replication backlog before and after the change under the same load.

SELECT
  SYSDATETIMEOFFSET() AS sampled_at,
  adc.database_name,
  ar.replica_server_name,
  drs.synchronization_state_desc,
  drs.is_suspended,
  drs.log_send_queue_size AS log_send_kb,
  drs.redo_queue_size AS redo_kb
FROM sys.dm_hadr_database_replica_states AS drs
JOIN sys.availability_replicas AS ar
  ON ar.replica_id = drs.replica_id
JOIN sys.availability_databases_cluster AS adc
  ON adc.group_database_id = drs.group_database_id
WHERE drs.is_local = 0
ORDER BY adc.database_name, ar.replica_server_name;

Provide reliable memory and storage

The SQL VM needs reliably available resources, not as many vCPUs as possible. Size it against measured load and avoid host memory pressure. When setting SQL Server max server memory, leave sufficient memory inside the VM for Windows and other services.

• Assess data, transaction logs and tempdb by their I/O behaviour. Separate virtual disks alone do not provide separate physical performance.
• Align the CPU model and NUMA design with host hardware and planned migration targets. Change settings only with a reproducible before-and-after test.
• Do not change offloads, jumbo frames and cache modes together on speculation. In particular, write acknowledgements and flush behaviour must remain reliable across the complete storage path.

Validate failover from the application's perspective

Test planned role changes, host failure and replica return separately. What matters is when users can work again and whether their transactions are processed correctly. Define approvals and stop criteria before triggering failures.

• Connect through the listener, check active transactions and measure application reconnection time.
• For conventional, non-contained AGs, provision and synchronise logins, SQL Agent jobs and other instance-level objects separately on the replicas.
• After maintenance, check synchronisation and backlogs. Do not work on the next node until the agreed redundancy is restored.
• Test SQL-aware backups and recovery independently of the AG. Replication does not replace backup.

Complete production approval

Technical feasibility and vendor support are separate questions. Microsoft's standard virtualisation support depends, among other things, on validated configurations. Check the exact platform combination in the SVVP context and the guest-clustering requirements. Support for unvalidated environments may be limited or require reproducing a fault outside virtualisation.

• Document Windows, SQL and VirtIO versions and the support route before production use. This article does not claim SVVP certification for Proxmox.
• Check SQL and Windows licensing, including secondary replicas, test operation and movement between hosts, against the applicable contracts. Passive replicas are not universally licence-free.