Neue PowerCLI-Cmdlets für vSphere, vSAN und VVOLs in vSphere 6.5

Mit vSphere 6.5 kommt auch die neue PowerCLI-Version 6.5. VMware-Admins erhalten damit neue Cmdlets für vSphere, vSAN und VVOLs.

VMware PowerCLI ist seit Kurzem offiziell in Version 6.5 R1 verfügbar. Nach unserer Preview der auf der VMworld für die Version 6.5 angekündigten Neuerungen stellt dieser Artikel die jetzt verfügbaren neuen Cmdlets und Features vor.

Laut VMware und PowerCLI-Produkt-Manager Alan Renouf basieren sämtliche neuen Features auf konkretem User-Feedback. Wie bereits im ersten Teil dieser Reihe erläutert, bringt PowerCLI in Version 6.5 neben den Kern-Modulen auch jene für ImageBuilder, AutoDeploy, HorizonView, VROps, UpdateManager und einige mehr gleich mit, was man durch Eingabe von

Get-PowerCLIVersion

leicht verifizieren kann.

Abbildung 1: Verifizierung der PowerCLI-Version 6.5 R1.

Core-vSphere-Module der PowerCLI 6.5 R1

An erster Stelle gibt es eine Vielzahl an Updates bei den Kern-Modulen für vSphere. Das betrifft nicht nur neue Cmdlets, die Entwickler haben nämlich auch deren Stabilität und Performance verbessert. Die interessantesten neuen Cmdlets unter den Core-Modulen sind jene rund um das Erstellen und Verwalten virtueller Maschinen.

Weitere Artikel zur PowerCLI:

Kostenloses E-Handbook zum PowerCLI-Scripting.

Die wichtigsten Befehle der PowerCLI 6.0.

PowerCLI mit Ubuntu Linux nutzen.

So unterstützt das Cmdlet Move-VM jetzt auch vMotion zwischen  vCentern, allgemein bekannt als Cross vCenter vMotion. Das Durchführen von Cross vCenter vMotion via PowerCLI erlaubt sogar ein Verschieben der virtuellen Maschinen zwischen separaten SSO-Domains (Single Sign-On). Über die grafische Benutzeroberfläche mit zwei vCentern im Enhanced Linked Mode (ELM) funktioniert vMotion nur innerhalb der gleichen SSO-Domain. Zur Erinnerung: Seit Version 6 unterscheidet und kennt VMware vSphere folgende vMotion-Spielarten:

  • vMotion
  • Cross vSwitch vMotion
  • Cross vCenter vMotion (gleiche SSO)
  • Long Distance vMotion (ge-routetes vMotion via Layer 3)
  • vMotion mit Microsoft-Cluster bei Verwendung von Physical-RDMs

Prinzipiell ist vMotion schon länger routbar, in allen Spielarten. Offiziell unterstützt wird dies von VMware aber erst mit vSphere 6.

Bei Long Distance vMotion kommen weitere Anforderungen hinsichtlich der Latenz/Bandbreite der WAN-Verbindung hinzu. Das Verschieben einer VM zwischen zwei vCentern via PowerCLI kann dann folgendermaßen erfolgen:

Connect-VIServer 'VC1' -Username <username> -Password <pass>
Connect-VIServer 'VC2' -Username <username> -Password <pass>
$vm = Get-VM 'myVM' -Location 'myVMhostOnVC1'
$destination = Get-VMHost 'MyVMhostOnVc2'
$networkAdapter = Get-NetworkAdapter -VM $vm
$destinationPortGroup = Get-VDPortgroup -VDSwitch 'myVDSwitchOnVC2' -Name 'myPortGroup'$destinationDatastore = Get-Datastore 'MyDatastoreOnVc2'
$vm | Move-VM -Destination $destination -NetworkAdapter $networkAdapter -PortGroup $destinationPortGroup -Datastore $destinationDatastore

Ferner unterstützt das neue New-VM-Cmdlet jetzt das Konfigurieren von VMs mit einer spezifischen Zahl an CPU-Cores. Zudem haben die Entwickler auch das Cmdlet Open-VMConsoleWindow aktualisiert. Es erlaubt jetzt den Zugriff auf die jeweils letzte Version der VMware Remote Console (VMRC), zum Beispiel mit Open-VMConsoleWindow –FullScreen –VM <VM-Name>.

Auch viele weitere Core-Module haben Updates erfahren, im Wesentlichen um den Zugriff auf die neu vSphere-6.5-API zu ermöglichen.

vSAN-Cmdlets der PowerCLI 6.5

Ein weiterer Schwerpunkt der PowerCLI 6.5 liegt in der Optimierung der Storage-Module, für die viele interessante Neuerungen integriert wurden. So gibt es zum Beispiel einen ganzen Sack voll neuer vSAN-Cmdlets, welche die PowerCLI etwa um die die Fähigkeit erweitern, die vSAN-Cluster-Konfiguration zu verwalten, einschließlich vSAN Fault-Domains, Update der HCL-Datenbank und der Möglichkeit, verschiedene vSAN-Tests anzustoßen. Somit lässt sich ab sofort der gesamte Prozess der Erstellung eines vSAN-Clusters via PowerCLI mit den folgenden vSAN-Cmdlets automatisieren:

  • Get-VsanClusterConfiguration,
  • Get-VsanDisk,
  • Get-VsanDiskGroup,
  • Get-VsanFaultDomain,
  • Get-VsanResyncingComponent,
  • Get-VsanSpaceUsage,
  • New-VsanDisk,
  • New-VsanDiskGroup,
  • New-VsanFaultDomain,
  • Remove-VsanDisk,
  • Remove-VsanDiskGroup,
  • Remove-VsanFaultDomain,
  • Set-VsanClusterConfiguration,
  • Set-VsanFaultDomain,
  • Test-VsanClusterHealth,
  • Test-VsanNetworkPerformance,
  • Test-VsanStoragePerformance,
  • Test-VsanVMCreation,
  • Update-VsanHclDatabase.

So ruft zum Beispiel das Kommando Get-VsanClusterConfiguarion -Cluster "MeinVSANCluster" die komplette Konfiguration des vSAN-Clusters "MeinVSANCluster" ab.

PowerCLI-Cmdlets für VMware VVOLs

Neben den vSAN-Cmdlets haben die PowerCLI-Entwickler auch einige interessante neue Cmdlets für den Umgang mit VVOL-Datastores (VMware Virtual Volumes) implementiert, zum Beispiel im Zusammenhang mit VVOL-Replikationen. Administratoren können nun Replication Groups empfangen und synchronisieren. Ebenso ist es möglich, Replication Failover Preparations abzurufen oder zu starten und sogar das Replication Failover selbst.

Solange VMware die Unterstützung für VVOL-Replication-Tasks nämlich noch nicht in seine Automatisierungslösungen integriert hat, können VVOL-Nutzer die neuen Cmdlets gut in eigene Skripte integrieren. Allerdings gibt es bisher kein Cmdlet, um ein Test-Failover anzustoßen, das zum Beispiel nur die replizierten VVOLs von der Target-Site klont und vSphere quasi zum Testen präsentiert.

Folgende Cmdlets sind jetzt aber fest implementiert:

  • Get-SpbmFaultDomain: ruft Fault Domains auf Basis des Namens oder der ID ab. Die Fault-Domain-ID ist jeweils global eindeutig.
  • Get-SpbmReplicationGroup: ruft die Replication Groups ab. Jede Replication Group kann vom Typ Source oder Target sein.
  • Get-SpbmReplicationPair: ruft die Beziehungen von Replication Groups jeweils als Paar von Source und Target Replication Group ab.
  • Start-SpbmReplicationFailover: leitet ein Failover von Geräten in die spezifizierte Replication Group ein. Das Cmdlet sollte auf der Replication-Target-Site aufgerufen werden. Nach Abschluss der Operation kann das betreffende Gerät über seinen VM-Dateien-Pfad registriert werden.
  • Start-SpbmReplicationPrepareFailover: bereitet die spezifizierte Replication Group für ein Failover vor.
  • Start-SpbmReplicationReverse: initiiert eine Reverse Replication, indem es die aktuelle Replication Group als Source markiert und deren Peer Replication Group als Target. Die Geräte in der Replication Group werden dann auf die Target-Seite repliziert, welche vor dem Failover die Source war.
  • Sync-SpbmReplicationGroup: synchronisiert Daten zwischen Source und Replikat für die Specified Replication Group. Dabei werden die Replika der Geräte in der Replikation aktualisiert und es wird ein neues Point in Time Replicate erstellt.  Auch diese Funktion sollte auf der Replication-Target-Seite aufgerufen werden.

Folgen Sie SearchDataCenter.de auch auf Twitter, Google+, Xing und Facebook!

Artikel wurde zuletzt im Januar 2017 aktualisiert

Erfahren Sie mehr über VMware

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchNetworking.de

SearchEnterpriseSoftware.de

Close