festplatte.ch

Der fehlerhafte Patch und die daraus folgenden Probleme mit VMTools und VCB sind mit dem aktuellen ESX3.5 U4 release behoben worden.

Erstellte Desktops/Server in VM Workstation oder einem GSX Server können nicht direkt in einem ESX 3.5 angehängt werden. Aufgrund unterschiedlichem Diskfileformat verweigert der ESX 3.5 Server das Attachen eines solchen Diskfiles.

Die Konvertierung kann über die Konsole per mit dem vmkfstools erfolgen. Dazu das vmdk File ins Storage kopieren und danach vmkfstools -i “Quelldatei” “Zieldatei” ausführen. Danach kann das konvertierte File an einer vorbereiteten VM angehängt werden. Nun muss via VirtualCenter die Hardware noch auf die aktuelle Virtual Machine Version upgedatet werden.

Komfortabler geht die Konvertierung mittels VMware vCenter Converter welcher kostenlos bei VMware heruntergeladen werden kann.
Mit diesem Tool kann ein lokaler Workstation Server direkt in die Infrastructure importiert werden. In einem Wizard lassen sich sämtliche Einstellungen, Filenamen etc konfigurieren. Die VM wird vollumfänglich konfiguriert und importiert.

vCenter Converter Manual

Handelt es sich um einen laufender Server auf einer Workstation kann der Import auch direkt mittes VM Consolidation über das vCenter erfolgen.

At the beginning of this month VMware released the Update 4 for its management tier vCenter.
Yesterday the company also pushed the big update for the hypervisor itself.

The new Update 4 (build 153875) is available for both ESX 3.5 and ESXi and includes:

• support for Intel Xeon 5500 series CPUs (codename Nehalem)
• support for Novell SUSE Enterprise Linux 11 (both Server and Desktop, both 32bit and 64bit),
• Ubuntu 8.10 (both Server and Desktop, both 32bit and 64bit), Windows PE 2.0 as guest OSes
• support for new SATA Controllers (from PMC, Intel, CERC and HP)
• support for new NICs (from HP, NetXtreme and Intel, including the just announced ones with VT-c)
• support for new storage arrays (from Sun)
• support for new management agents (from Dell and HP)
• an enhanced VMXNET driver for Windows XP and 2003 (which will require the re-installation of VMware Tools)

-> More release notes

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.

Download

Screenshots:

StorageVMotion

StorageVMotion2

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 show hosttopology;
Enter
SMcli.exe show hosttopology;
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