Virtuozity

VMware has implemented some new features in the VMFS file system in vSphere 4 and these updates bring some good news for you: In the past you had to consider the block size very carefully when formatting a VMFS volume, because in VI3 configuration and log files were stored within the VMFS for the first time. This meant that every file allocated at least the chosen block size, no matter how large or small it really was. VMFS in vSphere 4 introduced the ability to store smaller files in so-called 64KB "sub-blocks" to save disk space.

So choosing a small block size will not give you an advantage anymore, it will only limit you in the future in case you want to grow your VMFS! Yes, that's another difference, you are not limited to extents in vSphere 4, now you able to really grow your VMFS, which makes it even more flexible. Unfortunately the VMFS wizard will still ask you to format your volume with 1MB block size by default. I would recommend to choose the largest available block size here to be as flexible as possible, because changing it later is not possible.

By the way, it is definitely false information that the chosen block size will impact your storage performance, but: Another highly acclaimed feature by VMware is thin provisioning. As you already figured out yourself, you should be pretty careful using it in your production environment, although there are cases in which it will be very useful. In my opinion thin provisioning also makes sense with larger VMFS block sizes, because increasing the VMDK file in tiny 1MB chunks doesn't look like best practice to me.

Link: http://www.vmreference.com/vi3-card/

Forbes Guthrie created a great overview of VMware specs and figures. He calls his project the "vmreference card". Very useful if you are preparing for a VMware exam, but also for your EEE (Everyday ESX Experience).

I have been working on a VM as a desktop replacement for over a year now and I am quite satisfied with the experience. This is not a full-blown VDI, it's more like my personal virtual client, which I find very convenient compared to classic desktop computers.

Anyway, today I got a new monitor with a screen resolution of 1920x1200 pixels and I realized there is a limitation to the screen resolution of VMs. Here is how you can get beyond the standards, but you have to add a few lines to the relevant VMX file:

svga.maxWidth = "1920"
svga.maxHeight = "1200"
svga.vramSize = "9216000"

Width and height are pretty obvious but you also have to increase the RAM of your virtual video adapter, otherwise it cannot display the desired resolution. Here is how you get the value for this entry:

Width (pixels) * Height (pixels) * ColorDepths (bits) / 8

In case your Windows does not show you the right results in your desktop configuration, you can do it manually by editing the registry. Use regedit and go to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Hardware Profiles\Current\System\CurrentControlSet\Control\VIDEO\{FEDC7ADF-34C8-4BAF-B872-48C92671D7D5}\0000

The adapter string might be different, but there should not be too many adapters on a VM here anyway. Now modify the following entries to suite your needs:

DefaultSettings.XResolution
DefaultSettings.YResolution
DefaultSettings.BitsPerPel

This might require a reboot to work. The new resolution will also be usable on the VMware console. Please be aware that not all RDP clients are the same, e.g. I learned that my favorite tool from visionApp has a built-in limitation of 1600 pixels width. The original Microsoft RDP client had no problems showing the larger resolution.

VMs haben virtuelle Festplatten im VMFS-Dateisystem, nämlich ihre zugehörigen VMDK-Dateien. Da diese Dateien alle Informationen einer Festplatte enthalten, entsprechen sie vom Aufbau her einer physikalischen Disk, d.h. auch VMDK-Dateien haben einen blockweisen Aufbau (sogenanntes Virtual Block Device).

Das Performance-Problem kommt dann ins Spiel, wenn man bedenkt, dass die VMDK-Datei nichts weiter ist als eine Kapselung, denn das VMFS-Dateisystem hat wiederum Blöcke auf der LUN. Wenn diese Blöcke (VM vs. Physik) jedoch nicht exakt übereinander liegen, entsteht folgender Effekt: Jeder virtuelle Block den die VM benötigt, erzeugt doppelten Aufwand im SAN, da sich der virtuelle Block ja über zwei physische Blöcke im VMFS erstreckt, die beide vom Storage bedient werden müssen.

Die Lösung dafür heißt "Storage Alignment", was nichts anderes bedeutet, als dass man diese Blöcke exakt übereinander platziert. Dummerweise ist dies bei Windows nicht standardmäßig so, was mit der Partitionierung zu tun hat. Im sogenannten "Partiton Starting Offset" wird die Anzahl der Bytes als Versatz zum Partitionsanfang festgehalten. Dieser Wert liegt normalerweise bei 32.256 Bytes und genau da liegt das Problem: Um ein Storage Alignment zu erreichen muss dieser Wert durch 4096 teilbar sein, ansonsten liegen die Blöcke nicht übereinander! Der empfohlene Wert für bisherige Windows-Systeme liegt bei 32.768 Bytes. Windows Server 2008 und Vista arbeiten anders und haben einen Standardwert von 1.048.576 Bytes eingestellt, der bereits optimal ist.

Daher empfiehlt es sich, diesen Wert bereits in seinem "Golden Master" einzustellen. Wenn Sie den Partition Offset abfragen wollen, können Sie dies entweder manuell über die "System Information" (msinfo32) unter Windows tun oder automatisiert über WMI. Hier ein einfaches Beispiel zur Abfrage über die PowerShell:

$computer = "Server1,Server2,Server3"
$namespace = "root\CIMV2"
$properties = "__SERVER,Caption,StartingOffset"
Get-WmiObject -class Win32_DiskPartition -computername $computer -namespace $namespace -property $properties


Leider können Sie den Offset nicht im Nachhinein korrigieren, stattdessen muss eine neue Fesplatte erstellt werden. Dieser Aufwand lohnt sich nur bei Systemen mit hoher I/O-Last, da diese Optimierung bei VMs mit geringem I/O keine messbaren Auswirkungen hat. Für ihr Golden Master lohnt sich der Aufwand aber auf jeden Fall. Gehen Sie dazu bitte folgendermaßen vor:

1. Booten Sie die leere VM mit Windows PE oder Bart PE.
2. Starten Sie das Programm "diskpart" über die Konsole.
3. Wählen Sie die zu bearbeitende Disk aus.
4. Geben Sie Folgendes ein: create partition primary align=32
5. Rebooten Sie die VM und installieren Sie das Betriebssystem.

Entgegen der häufigen Annahme, dass Storage Alignment nur für blockbasierten Storage (SAN, iSCSI) relevant ist, sehe ich keinen technischen Grund, warum dies für netzwerkbasierten Speicher (NFS) anders sein sollte. Die Zugriffsmethode spielt letztendlich keine Rolle, denn auch bei NFS-Storage liegen die VMDK-Dateien auf irgendeinem Dateisystem, dem wiederum physische Blöcke zugrunde liegen.

Link: http://www.run-virtual.com/?page_id=160

Grundsätzlich empfehle ich jedem, die ESX-Konfiguration innerhalb eines Clusters einheitlich zu halten. Dazu gehören vor allem die präsentierten LUNs sowie die Einstellungen der vSwitches. Natürlich sind Sonderlösungen immer denkbar, vor allem im Testumfeld, im Sinne einer stabilen Betriebsplattform würde ich jedoch in produktiven Umgebungen von abweichenden Konfigurationen absehen. Der Hauptgrund dafür ist, dass VMotion-Migrationen höchstwahrscheinlich scheitern werden, da das System die Voraussetzungen zwischen den verschiedenen Hosts vor der Migration prüft. Steht die LUN oder die entsprechende Portgroup nicht zur Verfügung, kann die Migration nicht durchgeführt werden, da die VM gar nicht betrieben werden könnte.

Lange Rede kurzer Sinn: Konfigurieren Sie Ihre Portgroups am Besten per Skript (esxcfg-vmswitch) auf der Konsole um Vertippen oder sonstige menschliche Fehler auszuschließen. Für alle, die nicht gerne auf diese Weise arbeiten empfiehlt sich der "ITQ Infrastructure Client" von Flores Eken. Mit ihm können Sie auf komfortable Weise schnell neue Portgroups für eine Vielzahl von ESX-Servern einrichten und wieder löschen. Außerdem lassen sich Portgroup-Informationen schnell zum Vergleich exportieren.

Ein weiterer Vorteil des Programms ist, dass sich beliebige Shell-Befehle für die ausgewählten Hosts ausführen lassen. Für weitere Bequemlichkeit sorgen direkte Links in die beliebten Tools "Putty" und "WinSCP". Alles in allem ein sehr empfehlenswertes Werkzeug vor allem für Shell-Einsteiger.