SQL Server in VMs: Wann ist SA nötig?

Die direkte Antwort: Wer eine einzelne virtuelle Betriebssystemumgebung (OSE) nach virtuellen Cores lizenziert, benötigt eine Subscription oder aktive Software Assurance. Für eine fest platzierte Standard-Instanz im Server/CAL-Modell knüpfen die hier verwendeten Product Terms den virtuellen Betrieb selbst nicht an SA. Mobilität, Failover und Clientzugriff haben zusätzliche Bedingungen. OSE bezeichnet eine Betriebssystemumgebung, etwa das OS innerhalb einer VM. Grundlage sind SQL Server 2025, Commercial Licensing und die Product Terms für das Microsoft Customer Agreement, geprüft am 12. Oktober 2026. Für andere Versionen, OEM-Produkte oder Programme gelten die jeweiligen Verträge.

Warum zwei Antworten plausibel wirken

In einer Diskussion zur SQL-VM-Lizenzierung erhielt ein Administrator widersprüchliche Auskünfte von zwei Anbietern. Das Thema wurde im Thread diskutiert und eine Aussage später korrigiert. Eine Microsoft-Q&A-Frage vom Mai 2026 beschreibt zwei VMs und hundert Clients. Die akzeptierte Antwort betont Mobilität, reicht allein aber nicht für eine vollständige Bestellung.

Eine Auskunft kann virtuelle Cores betreffen, eine andere eine Serverlizenz mit CALs. Zusätzlich nimmt jemand möglicherweise einen Cluster an, obwohl ein fester Host gemeint ist. Schreiben Sie vor dem Preisvergleich auf: Welches Modell kaufen wir, welchem physischen Server werden die Rechte zugewiesen und wo kann die Last laufen? Eine vCPU-Zahl ersetzt diese Beschreibung nicht.

Erst das Modell, dann die Rechnung

Microsofts Lizenzübersicht unterscheidet Per Core und Server/CAL. Standard bietet beide Modelle; Enterprise wird üblicherweise nach Cores lizenziert. Eine SQL CAL gewährt Zugriff und ist kein Installationsschlüssel. Die Verbindungszahl im SQL Management Studio ist deshalb keine Lizenzinventur.

Die Tabelle prüft einen Entwurf; sie listet keine austauschbaren Produkte auf. Das Angebot muss SKU, Version, Modell und Umfang von SA oder Subscription nennen. Ohne Modell zeigt der Preis nicht, ob der Betrieb abgedeckt ist.

Das Minimum gilt für jede VM

Nach den aktuellen SQL Server Product Terms ist das individuelle virtuelle Per-Core-Modell nur mit Subscription oder aktiver SA verfügbar. Maßgeblich sind virtuelle Cores, mindestens vier Lizenzen je OSE. Wird ein virtueller Core mehreren Hardware-Threads zugeordnet, kann die erforderliche Zahl steigen. Erfassen Sie physische Prozessoren, virtuelle Cores und Verkaufspakete getrennt.

Hypothetisches Beispiel, kein Angebot: Zwei getrennte VMs haben zwei und sechs vCPUs. Bei üblicher Zuordnung benötigt die erste vier, die zweite sechs Core-Lizenzen: insgesamt zehn. Die Rechnung 2 + 6 = 8 übersieht das Minimum pro VM. Auch eine Vier-Core-Berechtigung deckt nicht beide VMs, nur weil die kleinere zeitweise kaum arbeitet.

Der SQL-2025-Leitfaden nennt Zweierpakete für Core-SKUs. Zehn Core-Lizenzen entsprechen hier fünf Paketen. Kontrollieren Sie die Einheit im Angebot: „5 Stück“ können zehn Core-Lizenzen oder ein ganz anderes Produkt bedeuten. Die Einheit gehört direkt neben die Menge.

Leiten Sie Standard-VM-Rechte nicht daraus ab, dass alle physischen Kerne des Hosts lizenziert sind. Der aktuelle Leitfaden unterscheidet die physischen Per-Core-Rechte von Standard und Enterprise. Mit der Zählmethode kann sich auch die zulässige Bereitstellung ändern.

Server/CAL erlaubt eine VM, nicht unbegrenzt Instanzen

Die hier verwendeten SQL-2025-Product-Terms gestatten je Serverlizenz eine laufende Instanz in einer physischen oder virtuellen OSE. Erfassen Sie die Instanzen und den physischen Host, dem die Lizenz zugewiesen wird. Eine Formulierung aus einem älteren SQL-Leitfaden belegt keine SQL-2025-Rechte.

Hypothetisches Beispiel: Zwei feste VMs enthalten jeweils eine laufende SQL-Standard-Instanz. Das ERP nutzen hundert bekannte Mitarbeiter mit gültiger SQL User CAL der passenden Version. Die Grundinventur besteht aus zwei Serverlizenzen und hundert User CALs. Verdoppeln Sie die CALs nicht automatisch wegen der zwei Server: Eine zugewiesene CAL gestattet Zugriff auf die entsprechenden lizenzierten Server des Kunden. Weitere Nutzer, Geräte oder automatisierte Zugriffe können das Ergebnis verändern.

Damit sind weder Mobilität noch Standby-Instanzen oder neue Versionen bestätigt. Das Beispiel beschreibt den Grundbetrieb. Wartung und Ausfall gehören als eigene Szenarien ins Angebot.

Ein ERP-Konto ersetzt keine Nutzer-CALs

Microsofts Multiplexing-Leitfaden behandelt indirekten Zugriff. Mitarbeiter, die SQL-Daten über ein ERP oder eine Web-App lesen oder schreiben, werden durch ein gemeinsames Datenbankkonto nicht zu einem einzigen lizenzierten Nutzer. Verfolgen Sie die Daten bis zu den tatsächlichen Empfängern.

Erfassen Sie beispielsweise Vertrieb → ERP → Anwendungsserver → SQL; Analyst → automatisch aktualisierter Bericht → SQL; Integrationsgerät → API → SQL. Zählen Sie die nach dem gewählten Modell erforderlichen Nutzer oder Geräte, nicht die SQL-Logins. Bei Automatisierung müssen Quelle und Nutznießer der Daten feststehen.

Microsoft unterscheidet bestimmte manuelle Weitergaben von automatisierter Bereitstellung. Eine Dateiendung beantwortet das nicht: Eine persönlich versandte statische Excel-Datei ohne Verbindung ist ein anderer Weg als ein automatisch aus SQL aktualisierter Bericht. Zeichnen Sie unklare Integrationen vor der Auswahl von Server/CAL auf. Vollständige Per-Core-Abdeckung ersetzt SQL CALs; Windows-Server- und Anwendungsrechte bleiben gesondert.

Der Hostwechsel ist eine zweite Entscheidung

Lizenzen werden einem physischen Server zugewiesen. Der SQL-2025-Leitfaden nennt grundsätzlich mindestens neunzig Tage zwischen Neuzuweisungen. Geeignete SA- oder Subscription-Rechte erlauben häufige Wechsel innerhalb einer Serverfarm. Automatischen Lastausgleich abzuschalten genügt nicht, wenn Administratoren bei jeder Wartung manuell migrieren.

Im Server/CAL-Modell umfasst die aktuelle Mobilitätsbedingung auch Subscription oder aktive SA für die zugreifenden CALs. Prüfen Sie Server- und Clientrechte zusammen. „Hat der SQL-Server SA?“ ist eine unvollständige Frage.

Ein Wechsel ohne SA ist umgekehrt nicht in jeder Konfiguration automatisch unzulässig. Der Zielhost kann bereits eigenständig ausreichend lizenziert sein oder eine andere anwendbare Vertragsregel greifen. Entscheidend ist das gesamte Modell. Fragen Sie den Partner: „Wie ist diese Instanz auf jedem möglichen Host abgedeckt, und welches Recht verwenden wir beim Wechsel?“

Was der Bestellunterlage nicht fehlen darf

1. Topologie. Physische Hosts, VMs, laufende Instanzen, vCPUs und Wechselmöglichkeiten; auch separat bereitgestellte SQL-Komponenten.
2. Zugriffswege. Direkte Nutzer, Geräte, ERP, Berichte und Integrationen. Bei Server/CAL die Zuweisungen und CAL-Versionen dokumentieren.
3. Ausfallbetrieb. Primär- und Standby-Standorte, tatsächliche Tätigkeit des Standbys und verwendetes Failover-Recht. Ein Reportingserver ist nicht ohne Prüfung passiv.
4. Lizenzbelege. SKU, Programm, Kaufdatum, Umfang und Laufzeit von SA oder Subscription sowie Mengeneinheiten.
5. Vergleichbare Varianten. Server/CAL- und Per-Core-Angebote auf dieselbe Topologie, Nutzergruppe und Verfügbarkeit beziehen.

So kann ein zweiter Administrator die Entscheidung prüfen, ohne das vorige Gespräch zu kennen. Der Partner muss nicht raten, was „ein SQL-Server“ bedeutet. Ordnen Sie Belege und regelmäßige Topologieprüfungen Ihrer übergreifenden Microsoft-Lizenzverwaltung zu.