Für dieses Problem gibt es im Allgemeinen das Feature „Processor compatibility“ in Hyper-V (Im Deutschen als „Prozessorkompatibilitätsmodus“ bezeichnet, in der GUI heisst es dann „Zu einem physischen Computer mit einer anderen Prozessorversion migrieren“ bzw. „Migrate to physical computer with a different processor version“). Dieses Feature kann man natürlich problemlos über die GUI ein- und ausschalten:

Allerdings ergeben sich hier schnell 2 Herausforderungen:

• Das Feature lässt sich nur ändern, während die VM ausgeschaltet ist
• In einem Cluster laufen schnell mal eine 2-stellige Anzahl VMs

Das kann man natürlich wie so vieles sehr elegant per PowerShell lösen, also habe ich dafür ein passendes Skript geschrieben. Dieses kann entweder zum ein- oder ausschalten des Features benutzt werden und iteriert dabei über einen Cluster und behandelt dabei dann alle VMs im Cluster, bei denen das Feature noch nicht korrekt eingestellt ist, in dem die VMs bei Bedarf zuerst gestoppt, das Feature gesetzt und dann falls vorher laufend die VM wieder startet. Am Ende wird dann noch der Gesamtzustand ausgegeben.

Das Skript findet ihr auf meinem GitHub Repo, siehe hier:

scripts/HyperV/EnableOrDisableCPUCompatibilityOnHyperVCluster.ps1 at master · HaikoHertes/scripts (github.com)

Damit kann man nun also entweder bei unterschiedlicher Hardware die CPU-Kompatibilität für alle VMs erhöhen oder, nachdem man z.B. die CPUs überall auf den selben Stand gebracht hat, das Feature wieder deaktivieren.

Aus meiner Sicht ist das – vor allem für die Nutzer, die sich mit Masse auf das Portal abstützen – eine tolle Sache, um Leichen im System zu vermeiden. Was hier noch fehlt (vor allem für kleine Testumgebungen) wäre das Löschen von Backups, virtuellen Netzen und anderen Resourcen, aber es ist ein Anfang!

Ihr findet diese Runbooks wie immer in meinem GitHub Repo, konkret genau hier:

VMs starten und stoppen:

https://github.com/HaikoHertes/scripts/tree/master/Azure/Automation/Snoozing

VMs deallokieren:

https://github.com/HaikoHertes/scripts/tree/master/Azure/Automation/VmDeallocation

Viel Spaß damit!

Weitere Informationen zu Azure Automation und Runbooks:

Azure Quickstart – Create an Azure Automation account | Microsoft Docs
Create an Azure Automation Run As account | Microsoft Docs
Create a standalone Azure Automation account | Microsoft Docs
Create a PowerShell Workflow runbook in Azure Automation | Microsoft Docs

Im ersten Teil zeige ich euch, wie man das Azure Migrate Assessment einrichtet, um Kostenabschätzung, Sizing und co. zu bekommen.

Im zweiten Part zeige ich die Replikation, Testmigration und Migration von VMs.

Und im dritten Part geht es nochmal dediziert um das Assessment auf der Basis von ausschließlich CSV Daten.

Viel Spaß beim Ansehen!

Wie geht man nun an das Thema heran? Zunächst muss man zwei Dinge in Erfahrung bringen:

• Den Namen des Resource-Providers um den es geht
• Die Operationen auf diesem Provider, die man erlauben oder verbieten möchte

Dazu kann man sich in den Microsoft Docs informieren:

• https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/azure-services-resource-providers – hier findet man die Resource Provider zu dein einzelnen Azure Services
• https://docs.microsoft.com/de-de/azure/role-based-access-control/resource-provider-operations – und hier die auf den jeweiligen Resource Providern möglichen Operationen

Für den Fall der Virtual Machine finden wir dazu also:

• Der Resource Provider heisst „Microsoft.Compute„
• Auf diesem sind u.a. folgende Aktionen vorgesehen:
  • Microsoft.Compute/virtualMachines/powerOff/action
    • Powers off the virtual machine. Note that the virtual machine will continue to be billed.
  • Microsoft.Compute/virtualMachines/read
    • Get the properties of a virtual machine
  • Microsoft.Compute/virtualMachines/restart/action
    • Restarts the virtual machine
  • Microsoft.Compute/virtualMachines/start/action
    • Starts the virtual machine

Die Liste der möglichen Aktionen auf einem Resource Provider kann man auch via PowerShell bekommen, z.B.:

Get-AzProviderOperation "Microsoft.Compute/*" | FT Operation, Description -AutoSize

Man muss allerdings berücksichtigen, dass es zum Starten einer VM auch erstmal nötig ist, die VM überhaupt sehen zu dürfen…

Als nächstes muss man die Rollen-Definition im JSON-Format schreiben. Dazu kann man sich auch vorab eine bereits existierende Rollendefinition herunterladen, z.B. mit

Get-AzRoleDefinition -Name "Virtual Machine Contributor" | ConvertTo-Json

Nun passt man sich das JSON so an, dass die gewünschten Aktionen abgedeckt sind. Dabei wird die „ID“ Zeile entfernt und „IsCustom“ auf „true“ gesetzt. Außerdem muss der AssignableScope gesetzt werden. In unserem Fall führt das in etwa zu dieser Definition:

{
  "Name": "Virtual Machine Starter-Stopper",
  "IsCustom": true,
  "Description": "Lets you see, start, restart and stop Virtual Machines.",
  "Actions": [
	"Microsoft.Resources/subscriptions/resourceGroups/read",
    "Microsoft.Compute/virtualMachines/read",
	"Microsoft.Compute/virtualMachines/start/action",
	"Microsoft.Compute/virtualMachines/restart/action",
	"Microsoft.Compute/virtualMachines/powerOff/action",
	"Microsoft.Compute/virtualMachines/deallocate/action"
  ],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
    "/subscriptions/00000000-1234-5678-91234-000000000000"
  ]
}

Diese Definition kann man z.B. mit vi in der Azure Cloud Shell in ein File schreiben. Diese kann man dann wiederum mit

New-AzRoleDefinition -InputFile myRole.json

in eine neue Rolle schreiben lassen.

Nun kann man die Rolle bspw. über das Azure Portal zuweisen:

Und damit kann der Benutzer dann genau die definierten Rechte wahrnehmen – und nicht mehr!

Viel Spaß beim Ausprobieren!