Dez 04
“Best Practies” Übersicht von bekannteren Storageherstellern im Zusammenhang mit VMware vSphere
http://www.ivobeerens.nl/2011/11/11/storage-best-practices-from-different-vendors-on-vmware-vsphere/
Mrz 27
Plugins für einfaches Storage VMotion, direkt über das Virtual Center. Vereinfacht den bisherige Storage VMotion ablauf immens.
Details:
Version 1.0
No longer protects against migrating VMs that have thin-provisioned disks.
No longer counts RDM files against datastore size, fixing the bug that plagued the last version.
SVMotion operations against templates are not supported since VMware does not support them.
Added tool tips that explain why a relocation cannot take place
All SVMotion events write out a log, enabling better understanding of what went wrong in case of an error.
Aside from the library that loads the plug-in, all of VMware’s internal code has been replaced with the VI Toolkit for .NET.
The project is now supported by almost 20 unit tests, helping to ensure fewer bugs and greater stability.
The unit tests can be expanded to include testing for a system-resource supported number of servers since they use mock testing designed to work with the VI Toolkit for .NET.
The project is now built using NAnt, which allows nightly builds of the source, creates distributions, and builds the MSI installer.
Screenshots:
StorageVMotion
StorageVMotion2
Mrz 20
Sporadisch bei SAN Controller Reboots entstanden auf den VMs Disk Controller Errors. Im Eventlog mit der ID 11 ersichtlich. Einen Reboot, Bluescreen oder ähnliches entstand jeweils nicht, der Server lief soweit normal weiter.
The driver detected a controller error on \Device\Harddisk0
Vergleicht man die Zeit der Reboots mit den ESX Kernel Logs sind folgende Meldungen ersichtlich:
Mar 14 04:48:06 ehf15 vmkernel: 15:18:41:26.613 cpu0:1098)VSCSIFs: 439: fd 9437 status Busy
Mar 14 04:48:06 ehf15 vmkernel: 15:18:41:26.613 cpu0:1098)VSCSIFs: 439: fd 87260 status Busy
Mar 14 04:48:06 ehf15 vmkernel: 15:18:41:26.613 cpu0:1098)VSCSIFs: 439: fd 9437 status Busy
Mar 14 04:48:06 ehf15 vmkernel: 15:18:41:26.613 cpu0:1098)VSCSIFs: 439: fd 87260 status Busy
Grundlegend ist das Verhalten und die entsprechend auftretende Fehlermeldung richtig. Der SAN Controller sendet ein Busy aufgrund entsprechender Beschäftigung (ReSync von Onlinemirroring).
ESX seitig wird ein Busy akzeptiert und somit kein Failover auf den zweiten Controller gestartet. Will ein virtueller Server nun auf das Disksystem zugreiffen, steht die Ressource nicht zur Verfügung und der Disk Fehler entsteht.
Dies ist natürlich eine äussert gefährliche Sache für die virtuellen Maschinen. Gemäss dem Fiber Channel SAN Configuration Guide von VMware müssen die Busymeldungen SAN seitig geändert werden. VMware interpretiert Busy als “normal” und unternimmt kein Failover. Wird dies geändert auf “not ready” initialisert der Host ein Failover und wechselt auf den anderen Controller.
How To:
To configure the storage processors to return Not Ready sense data
1) Determine the index for the LNXCL host type by using the following commands in
a shell window:
Press Enter after each command.
SMcli.exe
Enter
SMcli.exe
Enter
The following commands assume that 13 is the index corresponding to LNXCL in
the NVSRAM host type definitions. If your storage processors have LNXCL at a
different index, substitute that index for 13 in the following commands.
2) Execute these commands for SPA to have it return Not Ready sense data.
Press Enter only after you enter all commands.
SMcli.exe
set controller [a] HostNVSRAMBYTE [13,0x12]=0x01;
set controller [a] HostNVSRAMBYTE [13,0x13]=0x00;
reset Controller [a];
Enter
3) Execute these commands for SPB to have it return Not Ready sense data.
Press Enter only after you enter all commands.
SMcli.exe
set controller [b] HostNVSRAMBYTE [13,0x12]=0x01;
set controller [b] HostNVSRAMBYTE [13,0x13]=0x00;
reset Controller [b];
Enter
Jan 20
128-seitige Anleitung mit allen Details rund im die Anbindung von ESX Hosts mit einem SAN Storage System
