SCVMM and SQL Server Sizing Guide

Overview

The following details outlines the compute requirements for System Center Virtual Machine Manager (SCVMM) and its associated SQL Server database, based on current best practices and Microsoft's guidance for System Center 2022. These specs can vary depending on your environment size, so I’ll break it down into minimum, recommended, and scalable (large environments).

SCVMM Server Compute Requirements

Minimum Requirements (Lab / Small environments)

· CPU: Dual-core, 2.0 GHz (64-bit)

· RAM: 4 GB minimum

· Disk: 20 GB for installation (not including library or logs)

Recommended Production Requirements

· CPU: Quad-core, 2.5+ GHz (64-bit)

· RAM: 8–16 GB

· Disk:

o 40+ GB for OS and SCVMM binaries

o Separate disk or volume for SCVMM library share

o Fast storage (SSD preferred) for responsiveness

Large / Enterprise Environments

· CPU: 8+ cores

· RAM: 32+ GB (especially with high host count or large VMM fabric)

· Disk:

o OS: SSD

o Library: Dedicated volume with fast IOPS

o Logging: Consider dedicated volume if using diagnostics or high audit activity

SQL Server for SCVMM

SCVMM supports SQL Server 2019 and 2022 (Standard or Enterprise). SQL Server should be on a separate box in production for scalability and HA purposes.

Minimum Requirements

· CPU: Quad-core

· RAM: 8 GB

· Disk: 40 GB (with fast storage for data + tempdb)

Recommended for Medium Environments

· CPU: 8 cores

· RAM: 16–32 GB

· Disk:

o OS: SSD

o Data: SSD or high-performance RAID

o Logs: Separate volume from data

o TempDB: Separate volume if performance is a concern

Large Environments / HA

· SQL Always On Availability Groups or Failover Clustering

· CPU: 16+ cores

· RAM: 64 GB+

· High-performance SAN or SSD storage with separation of:

o OS

o Data files

o Log files

o TempDB

Other Considerations

· Network: 1 Gbps minimum; 10 Gbps strongly recommended for production environments

· Windows OS:

o SCVMM: Windows Server 2022 or 2019 (latest supported build)

o SQL Server: Same

· Domain: Both SCVMM and SQL must be domain-joined

· Service Accounts: Use separate, least-privileged accounts for SCVMM and SQL services

· SCVMM Scale-Out:

o SCVMM supports scaling out via multiple consoles and PowerShell clients, but there is only one VMM server per VMM database.

Tiered Sizing Recommendations

Tier	Hosts	VMs	SCVMM Specs	SQL Server Specs
Small	< 10	< 250	4 vCPU / 8 GB RAM 100 GB disk (OS + logs)	4 vCPU / 16 GB RAM 100 GB disk (data + logs)
Medium	10–50	250–1,500	8 vCPU / 16 GB RAM 150–200 GB disk + separate VMM Library disk	8 vCPU / 32 GB RAM Dedicated disks: - 100 GB OS - 200 GB DB - 100 GB logs - 50 GB TempDB
Large	50–200	1,500–5,000	12–16 vCPU / 32–64 GB RAM SSD storage with 300+ GB usable	16 vCPU / 64+ GB RAM SSD or SAN storage with separation: - OS - Data - Logs - TempDB
Enterprise	200+	>5,000	Clustered or Highly Available SCVMM Centralized SCVMM Library (DFS or SAN)	SQL Always On / Cluster Multi-tiered disk architecture Up to 128 GB RAM, 24+ cores

Scalability tested up to:

· 1,000 hosts

· 25,000 VMs

Notes by Component

SCVMM

· More RAM improves performance when managing large host groups or doing frequent PowerShell jobs.

· VMM Library performance is critical when doing template deployments — consider moving it to high-speed network storage (SMB 3.0 or SAN-backed).

· SCVMM performance also depends on network I/O, especially when deploying or migrating VMs.

SQL Server

· SQL workload grows significantly with:

o Large fabric definitions (many hosts, logical networks, etc.)

o Frequent job scheduling (e.g., deployments, compliance scans)

o High audit settings enabled

· You can place TempDB on SSD for performance — SCVMM uses it heavily.

Future-Ready Best Practices

1. Separate SCVMM and SQL roles — never co-host them in production.

2. Enable SQL Maintenance Plans for SCVMM DB (index rebuilds, statistics updates).

3. Monitor SQL latency and deadlocks — SCVMM performance often bottlenecks there.

4. Use SCVMM high availability only if absolutely needed — it's single-active and can be complex to maintain.

5. Consider System Center Operations Manager (SCOM) to monitor SCVMM at scale.

6. If using SCVMM with Azure Stack HCI, lean on Azure Arc and hybrid tooling.

SQL Always On for SCVMM – Planning Guide

1. SQL Version: Use SQL Server 2019 or 2022 Enterprise Edition.
2. Deployment Type: Always On Availability Group with synchronous replication and automatic failover.
3. Cluster Configuration:
    - Minimum 2 nodes
    - Windows Server Failover Clustering (WSFC) enabled
    - Shared domain, same Active Directory site for low latency
4. Listener:
    - Create an Always On Availability Group Listener
    - Use this listener name when installing SCVMM (for automatic failover support)
5. Storage:
    - Separate volumes for Data (.mdf), Logs (.ldf), and TempDB
    - SSD/NVMe or SAN-backed storage with redundancy
6. Backups & Maintenance:
    - Use full, differential, and transaction log backups
    - Run index maintenance and statistics updates regularly
7. VMM-Specific Note:
    - SCVMM does not support database failover clustering instances (FCI), only Always On AGs.
    - If using AG, SCVMM must connect via the listener DNS name, not the individual SQL instance.
8. Test Failover:
    - Validate SCVMM continues operating normally post-failover.
    - Review SCVMM logs in Event Viewer and SQL Server logs for any issues.