Beiträge

Veröffentlicht am

ZeroClient: Neuer Lizenz Server

Fujitsu veröffentlicht einen neuen Lizenzserver für ZeroClient-Controller (ex. Panomanager), der seit Version 5.x obligatorisch ist.

Offensichtlich kamen keine neuen Funktionen hinzu, sondern es wurden nur einige Bugs beseitigt. Zitat aus dem beigefügten PDF durch Fujitsu:

Bugfixes:

  • Support for IE9
  • Activation request containing Unicode characters was rejected by ZCLS
  • Sync with ZeroClientController failed if only one ZeroClient device connected.
  • If both ZCLS and ZCC had no devices in their databases: ZCLS initial status page showed continuous spinner and a status page refresh showed an error. Now instead a warning is shown in both cases.
Veröffentlicht am

VM Phantom LUN

Die Detailinformationen zu einer VM liefern eine Übersicht über alle mit dieser VM assoziierten Ressourcen wie z.B. Netzwerk, Datenspeicher etc.

Phantom Jagd

Mir ist aufgefallen, dass einige VMs nach einem Upgrade auf vSphere5 zwei LUNs unter Resources anzeigen.

Die VM hat aber nur ein einzelnes VMDK File und dieses liegt gemeinsam mit den Konfigurationsdaten auf einer LUN. Ein DVD-ROM ISO ist auch nicht eingebunden, wie man im Bild unten sehen kann. Woher kommt also die Phantom LUN? „VM Phantom LUN“ weiterlesen

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”