Schlagwort: svMotion

Veröffentlicht am

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

Veröffentlicht am

Different Blocksizes are evil!

Geahnt habe ich das schon immer, aber heute durfte ich das selbst miterleben. Storage vMotion von einem Volume (8MB Blocksize) auf ein frisch mit vmfs5 formatiertes Volume (1MB Blocksize). Zwanzig Gigabyte verschieben kann quälend langsam sein. Eine gleichgroße VM zwischen zwei LUNs mit gleicher Blockgröße dauerte nur einen Bruchteil der Zeit!

svMotion mit unterschiedlicher Blocksize
VM Protokoll LUN Source LUN Target Zeit [min]
 20 GB  FC 4Gbit  SAS 15k 8MB  SAS 15k 1MB  23
 20 GB  FC 4GBit  SAS 15k 8MB  SAS 15k 8MB  3

Wie kommt es zu derart frappierenden Unterschieden bei svMotion?

Die Ursache liegt in der Verwendung der unterschiedlichen Datamover, die vSphere5 für svMotion verwendet. Wenn die Storage kein Hardware Offload unterstützt, dann stehen zwei Datamover zur Auswahl:

  • fsdm der Standard Datamover. Liest den Block in den Applikationspuffer (svMotion) und schreibt diesen dann zum Ziel.
  • fs3dm : optimierter Datamover, der mit vSphere4 eingeführt wurde. Er Verschiebt die Daten auf Hypervisor Ebene unter Umgehung des Applikationspuffers.

Sobald Quelle und Ziel unterschiedliche Blockgrößen haben, fällt vSphere zurück auf den Standard Datamover fsdm. Die Blöcke werden gelesen und wegen unterschiedlicher Blockgröße an Quelle und Ziel neu organisiert, bevor sie geschrieben werden.

Ein sehr schöner Artikel hierzu erschien unter dem Titel “Blocksize impact” bei Yellow-Bricks und ein weiterer bei Frank Denneman unter dem Titel “Upgrading VMFS Datastores and SDRS”