SCVMM: Entfernen eines NVGRE Gateways erzwingen
Gerade wenn man in einem POC viel mit dem Microsoft Gateway im System Center Virtual Machine Manager (SCVMM) experimentiert, dann kann man in eine Situation geraten, in dem das Gateway nicht mehr konfigurierbar ist. Ein Entfernen funktioniert ebenfalls nicht mehr, da angelegte VM Networks davon abhängig sind. Die VM Networks lassen sich nicht mehr löschen, da dafür eine Aktualisierung des Gateways notwendig ist.
In diesem Bild sieht man ein Network “Tenant Test”, dass von einem Gateway abhängig ist:
Versucht man dieses zu löschen, dann bekommt man eine Fehlermeldung. Der Abhängigkeitsbericht zeigt folgendes:
SC 2012 SP1 Update Rollup 3 verfügbar
Vor zwei Tagen hat Microsoft das Update Rollup 3 für die System Center Familie verfügbar gemacht (alle Produkte außer ConfigMgr). Die Updates sind wie bei den letzten Rollups üblich auch in Windows Update auffindbar.
Hier der direkte Link zu der Beschreibung:
http://support.microsoft.com/kb/2836751/en-us
Beachtet bitte auch die Installationshinweise am Ende des Knowledge Base Artikels, da z.B. bei OpsMgr immer ein paar manuelle Schritte nötig sind bzw. bei SCVMM, der noch auf UR1 ist, das UR1 zuerst deinstalliert werden muss!
Abkürzungen für System Center Produkte
Ich verwende regelmäßig die Abkürzung SCCM für System Center Configuration Manager. In den MVP Foren wird man dafür regelmäßig gerügt. Ursache hierfür ist, dass Microsoft für seine Produkte nur offizielle Abkürzungen benutzt, die nicht von einer anderen Firma als Trademark eingetragen wurden.
Der Eintrag SCCM ist ein eingetragenes Trademark. Zu finden ist dies z.B. in der entsprechenden Datenbank der USA:
Hyper-V 3.0
Im Rahmen einer Vortragsserie haben ein Kollege und ich die Neuerungen in Windows Server 2012 vorgestellt. In diesem Post möchte ich diese nochmal zusammenfassen und einige Details erklären:
In folgenden Bereichen sehe ich Neuerungen:
Limits
- 64vCPUs per Guest
- 4TB per Host
- 320 logical CPUs pro Host
- 1TB pro VM
- 64 Cluster Nodes
- 4000 VMs pro Cluster
Memory
SCVMM 2012: Neuerungen
Im letzten Teil dieser Serie schauen wir uns den System Center 2012 Virtual Machine Manager (SCVMM) an. Hier gibt es wieder einige ganze Reihe von Verbesserungen. Die Verbesserungen teilen sich in zwei Hauptgebiete auf: Dienste und Cloud-Unterstützung und auf der anderen Seite Fabric Management.
Dienste und Cloud-Unterstützung:
-
Service Livecycle Management:
-
Dienste in SCVMM werden als Template definiert und darüber auch aktualisiert.
-
mit SCVMM 2012 können Serveranwendungen jetzt auch über Server App-V abstrahiert werden
Hyper-V: Extra Rechte auf Hyper-V für Nicht-Adminuser einrichten
Grundsätzlich darf auf einen Hyper-V Server nur ein Administrator zugreifen (Mitglied der lokalen Administratorengruppe). Setzt man den System Center Virtual Machine Manager (SCVMM) ein, so ermöglicht dieser einem u.a. ein rollenbasiertes Management. Dabei erfindet er das Rad nicht neu, sondern setzt ein Feature des Hyper-Vs ein, dass in meinen Augen zwar gut dokumentiert aber relativ unbekannt ist.
Dazu verwendet Hyper-V das rollenbasierte Accessmanagement (RBAC) und die dafür verfügbare GUI AzMan. Die Konfigurationsinformationen werden in einer XML Datei unter ProgramData\Microsoft\Windows\Hyper-V\InitialStorage.xml abgelegt. Achtung: Verwendet man den VMM Agent, so wird der Ort der XML Datei auf ProgramData\microsoft\Virtual Machine Manager\HyperVAuthStore.xml geändert!
Ich beschreibe hier die Vorgehensweise, wie man einer zusätzlichen benutzergruppe das Recht einräumen kann auf die Konsole der Virtuellen Maschinen zugreifen zu können:
Zuerst startet man die AzMan Konsole:
SCVMM: Remove an Alias or Konflikt mit Hyper-V Powershell
Wer die Powershell Module von SCVMM und die Community Module zu Hyper-V gleichzeitig benutzen will, bekommt bei einigen Funktionen einen Konflikt.
Eigentlich sind alle Funktionen vom SCVMM eindeutig mit einem SC bezeichnet. So heißt die Funktion, um das Objekt einer Virtuellen Maschine zu erhalten get-SCVirtualMachine. Wahrscheinlich aus historischen Gründen gibt es aber eine Alias namens “get-VM” auf diese Funktion.
Die CodePlex Hyper-V Funktionen haben keinen gesonderten Namensraum. Hier heißt die Funktion für die Virtuelle Maschine einfach get-VM. Dies wäre nicht so schlimm, wenn die Funktion nicht auch intern fleißig genutzt wird. Möchte man die CodePlex Funktionen nutzen, um Differenzielle Disks zu erstellen (etwas was der SCVMM auch in 2012 nicht anbietet), so funktioniert dies nicht mehr, wenn beide Module geladen sind.
SCVMM: mit Powershell Teil 2
In diesem Blogpost werde ich die Arbeit mit den neuen Custom Properties im SCVMM 2012 vorstellen.
In Vergangenheit gab es eine Reihe von vordefinierten Custom Properties (1-10). Mit SCVMM 2012 gibt es beliebige Erweiterungsfelder, die als Objekt abgebildet sind und an Virtuellen Maschinen, Hosts, Clouds und anderen Objekten hängen können.
Diese Objekte kann man in Powershell mittels get-SCCustomProperty abrufen. Diese Objekte beinhalten aber noch keine Werte, sondern stellen nur die Schlüssel dar. Die eigentlich eingestellten Werte hängen in einer Hashtable an den zu erweiternden Objekten, also z.B. an der jeweiligen Virtuellen Maschine in der Hashtable Eigenschaft CustomProperty. Möchte man den Wert der selbsterstellten Eigenschaft “Kostenstelle” abfragen, so kann man dies über
SCVMM: mit Powershell Teil 1
Ich habe gerade das Glück etwas mehr mit Powershell und System Center Virtual Machine Manager 2012 (SCVMM, RC) zu arbeiten. Daher werde ich hier wieder ein paar Codesnippsel posten, um bestimmte Funktionen zu automatisieren:
die erste Funktion soll eine neue Cloud für Hyper-V erzeugen . Zusätzlich wird ein neue Rolle für diese Cloud angelegt, die nur VMs verwalten darf.
#creates a new cloud and a corresponding usergroup
function createCloud([string]$name,[string]$hostgroupname)
{
#retrieving first GUID for creating the new cloud
$job= ([System.Guid]::NewGuid().toString())
#define Cloud limitations (here: no limit)
Set-SCCloudCapacity -JobGroup $job -UseCustomQuotaCountMaximum $true -UseMemoryMBMaximum $true -UseCPUCountMaximum $true -UseStorageGBMaximum $true -UseVMCountMaximum $true
#setting the used network (here: the network has the same name as the cloud)
$resources = @()
$resources += Get-SCLogicalNetwork -Name $Name
#defining that the cloud can be used on hyper-v server
$addCapabilityProfiles = @()
$addCapabilityProfiles += Get-SCCapabilityProfile -Name "Hyper-V"
#adding the settings to the cloud with the defined GUID
Set-SCCloud -JobGroup $job -RunAsynchronously -AddCloudResource $resources -AddCapabilityProfile $addCapabilityProfiles
#adding the cloud to the hostgroup
$hostGroups = @()
$hostGroups += Get-SCVMHostGroup -Name $hostgroupname
#creating the cloud and the rest from the first job :-)
New-SCCloud -JobGroup $Job -VMHostGroup $hostGroups -Name $Name -RunAsynchronously
#creating the usergroup
#GUID for the second job
$job= ([System.Guid]::NewGuid().toString())
#the roleis for the newly created cloud
$scopeToAdd = @()
$scopeToAdd += Get-SCCloud -name $name
#the user of this role can start, stop and shutdown virtual machines in the cloud and start a remote control
Set-SCUserRole -JobGroup $job -AddScope $scopeToAdd -Permission @("RemoteConnect", "Shutdown", "Start", "Stop") -ShowPROTips $false
$cloud = Get-SCCloud -Name $name
#add all settings to the role
Set-SCUserRoleQuota -Cloud $cloud -JobGroup $job -QuotaPerUser -UseCPUCountMaximum -UseMemoryMBMaximum -UseStorageGBMaximum -UseCustomQuotaCountMaximum -UseVMCountMaximum
#create the role with the job guid
New-SCUserRole -Name $name -UserRoleProfile "SelfServiceUser" -Description "" -JobGroup $job
}
Die Funktion kann einfach per
SCVMM/Hyper-V: Löschen von VMs
Kann mir einer das mal erklären? Löscht man in Hyper-V eine VM, die Snapshots hat, dann werden erst alle Snapshots gelöscht, also in das Hauptfile zurückgeschrieben und dann die entsprechende Disk. Was für einen Sinn macht das?
Besonders extrem wird es, wenn man ein Storage Migration mit SCVMM (System Center Virtual Machine Manager 2012) macht. Dabei wird eine neue VM angelegt, die Disks kopiert und dann die alte VM mit den Disks gelöscht. Was dann bei einer VM mit Snapshots passiert kann man sich denken: