PowerCLI: Easy Migration Script

Einen Datastore leeren kann eine sehr mühsame Arbeit sein. Man kann zwar mehrere VMs gleichzeitig auswählen, aber diese müssen im selben Ressourcepool sein damit man sie gemeinsam verschieben kann. Das ganze wird zum Klickdrama. Viel schöner wäre es, wenn man diesen Vorgang mittels PowerCLI automatisieren könnte. Zu meiner Freude fand ich genau so ein Skript. Es basiert auf einer Programmierung von ict-freak.nl und wurde von Richard Yaw erweitert. Die Programmierung basiert auf der PowerCLI und wurde mit einer einfachen GUI ausgestattet.

Download

Easy Migration Tool v2.1 by Richard Yaw

Folgende vMotion Operationen können durchgeführt werden:

  • Host to Host
  • VM to Host
  • Datastore to Datastore
  • VM to Datastore

Bei der Datastore to Datastore Migration kommt als erfreulicher Nebeneffekt hinzu, daß die VMs nacheinander migriert werden und somit das Plattensubsystem nicht unnötig belasten.

Man startet das Skript über die PowerCLI. Es öffnet sich die GUI und man muß nur den vCenter Hostnamen eingeben, den Cluster auswählen und den vMotion Modus festlegen (vgl. oben).

Die Version ist schon etwas älter, funktioniert aber auch unter vSphere 5.1 noch zuverlässig.

So kann man auch größere Datastores über Nacht oder über das Wochenende leeren lassen. 🙂

Links

vSphere5: Multi NIC vMotion

Betrachtet man vSphere Cluster im produktiven Einsatz, so fällt auf daß immer noch sehr wenige davon mit 10 GB Uplinks ausgestattet sind. Und das meist aus gutem Grund, denn die Hardware ist sehr teuer und auch die Infrastruktur zwischen den ESX-Knoten (Switches, Router, etc.) muß 10 Gbit unterstützen. In der Regel kann man mit mehreren 1Gbit Uplinks sehr gut auskommen und es bedarf schon einiger Mühe einen 1 Gbit NIC zu sättigen. Einzig bei vMotion kann es gelegentlich zu Engpässen kommen, weswegen von mir in der Vergangenheit der Management Traffic vom VM-Network logisch getrennt wurde und die Adapter nur wechselseitig als Standby zur Verfügung standen.

Eine wirklich tolle Eigenschaft von vSphere5 ist mir aber bis vor kurzem entgangen: Multi-NIC vMotion. Hierbei wird der Datenverkehr über mehrere physische NICs geleitet. Es bedarf mindestens zweier NICs mit je einer VM-Kernel Portgruppe und ähnelt dem Verfahren zum Aufbau einer iSCSI-Portgruppe. Nur daß sich hier beide vmk Portgruppen im selben IP Subnetz befinden. Diese Funktion ist nicht nur bei mehreren gleichzeitigen vMotion Transaktionen nützlich, sonder auch schon bei einer einzelnen.

Manuelle Einrichtung

Wir brauchen dazu entweder zwei vSwitches mit je einem vmnic und je einer vmkernel Portgruppe, oder wir verwenden einen vSwitch mit zwei vmnics und zwei Portgruppen. Letztere Variante gefällt mir persönlich besser.

  • Einen vSwitch erstellen und diesem zwei NICs zuordnen (Bsp: vmnic1, vmnic2)
  • zwei vmkernel Portgruppen erstellen (Bsp: vMotion1, vMotion2), mit IP Adressen aus dem gleichen Subnetz.
  • Switch failover-order umgehen.
  • vMotion1 mit vmnic1 (active), vmnic2 (standby)
  • vMotion2 mit vmnic2 (active), vmnic1 (standby)

Achtung Bug!: Derzeit existiert noch ein Problem in vSphere5, wenn zwei Kernelports auf dem selben Virtual Standard Switch vorhanden sind. Das Problem wurde ausführlich im Blogartikel von VMtoday beschrieben und ist ab vSphere5 U1 behoben.

Skriptgesteuerte Einrichtung

Bei mehreren Hosts ist eine Automatisierung wichtig. Die manuelle Einrichtung ist nicht nur mühsam, sondern auch fehleranfällig. Im Diskussionsbereich des Artikels zum Thema Multiple-NIC-vMotion auf Yellow-Bricks werden Skripte in unterschiedlichen Skriptsprachen gelistet. Darunter auch vSphereCLI und PowerCLI.

Links

Frankdenneman.nl: Multi-NIC vMotion support in vSphere5
VMtoday: vSphere 5 Networking Bug #2 Affects Management Network Connectivity
Yellow-Bricks: Multiple-NIC vMotion in vSphere 5
VMware Pubs [PDF]: Networking-Guide

Skriptfehler PowerCLI

Bei der Ausführung von Powershell oder PowerCLI Skripten kann es zu einem Problem mit der Signierung kommen. Zur Laufzeit erhält man eine Meldung wie unten dargestellt.

Die Datei <name> kann nicht geladen werden. Die Datei <name> ist nicht digital signiert. Das Skript wird auf dem System nicht ausgeführt. Weitere Informationen erhalten Sie mit “Get-Help about_signing”.

bzw. für englische Ausgabe:

The file <name> cannot be loaded. The file <name> is not digitally signed. The script will not execute on the system. Please see “Get-Help about_signing” for more details.

Die kontrolle der Sicherheitseinstellungen von Powershell ergab, daß sie bereits auf “RemoteSigned” gestellt wurden.

PS C:\Users> get-executionpolicy
RemoteSigned
PS C:\Users>

Was Ist also die Ursache? Das PowerCLI Skript (ein Teil von vCheck) hatte ich kurz zuvor geladen und lokal entpackt. Öffnet man die Eigenschaften des der ps1-Datei so sieht man schnell die Ursache.

Aktiviert man den Button “Zulassen”, so ist das Skript für künftige Ausführung genehmigt und der Fehler tritt nicht mehr auf.

vCheck v6

Alan Renouf hat eine neue Version des bewährten vCheck veröffentlicht. Das Script prüft ein Vielzahl an Parametern am ESX-Cluster ab und stellt diese bei Überschreitung der Grenzwerte in einem Report dar. Die aktuelle Version 6 kommt mit vielen Neuerungen. Neben neuer Optik kommt u.a. eine verbesserte Lesbarkeit in Outlook und eine modulare Organisation der Abfragen in Plugins. Diese können sehr leicht erweitert oder entfernt werden.