Eine Diskussion, die immer wieder geführt werden muss, ist die Entscheidung ob für spezielle Anwendungen ein Raw Device Mapping (RDM) anstatt vDisk Containern (vmdk) eingesetzt werden soll. Die Debatte bekommt nun neue Argumente zugunsten der VMDK. Tatsächlich sieht ein neuer Benchmark im vSphere-Blog beide Alternativen auf Augenhöhe, jedoch gewinnt der vmdk Container wegen seiner höheren Flexibilität.
blogged somewhere in time…
Es ist gut, wenn man alle Dokumentationen auf einen Blick hat und diese nicht mühsam mit der Suchmaschine finden muss. 
Dieser Artikel beschreibt prinzipiell die Schritte, die zu beachten sind wenn man eine Eternus DX 60/80/90 (S1 und S2) mit ESXi Hosts verbinden will. Sie ist eine Zusammenfassung des Server-Connection-Guide-iSCSI von Fujitsu. Weiterlesen
VMware vSphere 5.1 bringt eine Reihe neuer Details und Verbesserungen mit. Unter App-Connect sind die wichtigsten zusammengefasst.
Wer es etwas genauer wissen möchte, kann die VMware Whitepaper zum Thema studieren. Eine Liste der wichtigsten PDF-Dateien wurde freundlicherweise auf Yellow-Bricks zusammengestellt.
Bei der Kontrolle der Leistungsdaten eines ESXi Servers (vSphere-Client – Performance – Realtime) fiel mir ein unglaublich hoher Wert für CPU-Ready auf. Laut Graph war dort ein Wert von fast 23 Sekunden. Wie kann das sein?
Bevor man die Werte deutet, sollte man zunächst einige Bergriffe definieren.
Angabe in Prozent (%RDY) oder in Millisekunden (ms). CPU-Ready bezeichnet die Zeit, die eine VM warten muß bis ihrer vCPU eine physische CPU zugeteilt wird.
VM bereit – Host nicht.
Hat eine VM mehr als eine vCPU, so müssen diese zeitgleich physischen CPU Kernen des Host Systems zugeordnet werden. Das bedeutet im Klartext, eine VM mit einer vCPU muß warten bis ein Kern frei ist. Eine VM mit 4 vCPU muß entsprechend warten bis 4 Kerne gleichzeitig frei sind. Letzteres ist wesentlich weniger wahrscheinlich. Und damit sind wir auch beim dritten Schlagwort: Co-Stop.
Zeit, die eine VM bereit ist, jedoch aufgrund von Wartezeiten durch Co-Scheduling nicht einem physischen Kern zugeteilt werden kann. Im Prinzip das selbe wie CPU-Ready, jedoch für VMs mit Virtual Symetric Multiprocessing (vSMP). Während hohe CPU-Ready Werte auf ein Hostsystem unter Druck schließen lassen, kann man dies bei hohen Co-STOP Werten nicht unbedingt folgern. Es bedeutet nur, daß der Host nicht die geforderte Anzahl physischer Kerne gleichzeitig bereitstellen kann. Weiterlesen
Ein interessanter Artikel zum Thema VMFS-Locking erschien kürzlich im VMware vSphere Blog unter dem Titel “VMFS locking uncovered“. Er erklärt prinzipielle Sperrmechanismen bei VMFS3 und VMFS5 wie etwa SCSI-Reservierung, Heartbeats, ATS (Atomic Test & Set) oder Optimistic-Locking.
Gastsysteme für Virtuelle Desktop Infrastrukturen (VDI) haben z.T. deutlich andere Anforderungen als Installation auf klassischer PC Hardware. Viele Dienste und Funktionen, die am PC nützlich sind, können sich z.T. sehr negativ auf VDI Umgebungen auswirken.
Vmware hat daher einen Leitfaden für Windows7 Gastsysteme bereitgestellt, der auch Skripte zur Anpassung enthält.
http://www.vmware.com/files/pdf/VMware-View-OptimizationGuideWindows7-EN.pdf
Die Anpassung kann entweder durch ein Batch File (commands.bat) oder mittels Microsoft Deployment Toolkit (MDT) erfolgen. Weiterlesen
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.
Bei der Einrichtung eines Synchronspiegels zwischen zwei Eternus DX90 wird an einer Stelle nach der Tablesize gefragt. 
Als Vorgabe steht dort 32MB “for day to day operation” – also für den alltäglichen Gebrauch. Damit fiel neulich ein Spiegelversuch auf die Nase. Erst die Erhöhung auf 64MB brachte die zweite Spiegelgruppe ins Rennen. Die dritte scheiterte wieder und ließ sich erst nach einer weiteren Erhöhung auf 128MB (Maximum) aktivieren.
Die Frage ist nun, wie berechnet man die notwendige Tablesize?
Auszug aus Fujitsu Eternus DX90 Web GUI User Guide
| S1 | EC/REC table size |
| M | Bitmap ratio setting (Resolution) |
| C1 | EC/REC copy capacity [GB] |
| N1 | Number of EC/REC sessions |
S1 [MB] = ((2 * C1 / M) + N1) * 8 [KB] / 1024 (counting fractions as one)
Beispiel mit 3 Copygruppen:
Gesamtvolumen C1 = 1 + 3*1,5 + 3*1,3 TB = 9,4 TB (=9625 GB)
Damit ergibt sich für für die Tablesize (mit Resolution =2):
S1 = ((2*9625/2)+7)*8[kB]/1024 = 75MB
Damit ist auch klar, warum die dritte Spiegelgruppe bei 64MB Tablesize nicht mitkam.
Fujitsu Eternus Web GUI User Guide