Wie Citrix XenServer das SAN sieht (mit Emulex HBAs) & XenServer XenTop-Utility...

Hi, bei einem meiner Kunden wurde in der letzten Woche eine Storage-Konsolidierung und Erweiterung durchgeführt, von der auch diverse XenServer Storage Repositories betroffen waren. Schnell stellte sich die Frage, welche SRs auf Storage-Seite (ein SAN von IBM) denn jetzt eigentlich gelöscht werden könnten, nachdem wir die Inhalte verschoben hatten. Die im XenCenter angezeigte SCSI-ID hilft hier erstmal nicht wirklich weiter. Ein wenig Licht ins Dunkel bringt der Artikel über XenServer-Multipathing, zeigt er doch auf, wie ich über im XenServer vorhandene HBA-Tools Informationen über das Storage-Netzwerk abfragen kann. Der Ansatz über xe -sr bringt nämlich keinen Erfolg :-(
 Bei dem Kunden sind Emulex FC-HBAs im Einsatz, so dass wir das im XenServer enthaltene HBAnywhere-Tool (hbacmd) benutzen konnten. Aber auch für QLogic-HBAs gibt es ein Tool, den QLogic SanSurfer (scli). Hier erst mal der Link zu dem CTX-Multipathing-Artikel, der einen guten Einstieg in das ganze Thema bietet: Multipathing Overview for XenServer
Allerdings kam ich mit den dort angegebenen Befehlen leider immer noch nicht ans Ziel, was die eindeutige Identifikation von SAN-Ressourcen angeht. Also noch ein wenig die Dokumentation zu HBAnywhere studiert. Mit folgenden Infos / Befehlen bekomt man auf jeden Fall eine Menge Infos über das SAN aus Sicht des XenServers bzw. des HBAs, allerdings nur, wenn ihr Emulex-HBAs im Einsatz habt:

• # /usr/sbin/hbanyware/hbacmd (Zeigt eine Liste aller Befehle an)
• # /usr/sbin/hbanyware/hbacmd listhbas (Zeigt Informationen über die installierten HBAs an. Interessant hierbei ist vor allem die Port WWN, die oftmals für die weiteren Befehle verwendet werden muss)
• # /usr/sbin/hbanyware/hbacmd targetmapping (Zeigt Informationen über die verfügbaren Targets an)

Allerdings reichten diese Informationen den SAN-Admins immer noch nicht aus. Beim Einbinden von Storage Repositories in den XenServer wird einmalig eine Information angezeigt, die das SR auf dem SAN eindeutig identifiziert. Diese Information galt es ausfindig zu machen. Mit dem folgenden Befehl hat es denn geklappt:

• # sginfo –a /dev/disk/by-id/{scsi_id}

Letztlich hat die SCSI-ID also doch geholfen! In der Shell einfach zweimal Tab drücken, dann werden alle SCSI-IDs angezeigt. Fibre-Channel LUNs beginnen übrigens immer mit SCSI-…Die gesuchte Information (die Seriennummer) stand relativ früh am Anfang der Ausgabe.

Für generelle Infos bzgl. der Multipathing-Configuration einfach folgenden Befehl eingeben: # multipath -ll

Wer mit den ganzen Infos nicht weiterkommt, der kann zumindest bei Emulex-HBAs noch ein Extended Logging aktivieren. Wie das geht ist in den folgendem CTX-Artikel beschrieben: How to Configure Extended Logging on an Emulex Fiber Channel Host Bus Adapter

Und wenn ich mich heute schon so intensiv dem XenServer widme, möchte ich noch auf das Tool XenTop und den zugehörigen CTX-Artikel hinweisen. XenTop zeigt detaillierte Echtzeit-Infos über den XenServer und die Prozesse der Dom0 an, ähnlich dem normalen Linux-Tool Top. How to Use the XenServer Xentop Utility

In diesem Sinne wünsche ich allen eine schöne und erfolgreiche Woche...

Joern.

Provisioning Services with VMwareVMXnet3 - Patch available

Hi,

Citrix just released an update for Provisioning Services (all versions starting with 5.1 SP1 are facing the issue) to resolve a problem with VMware VMXnet3, which was introduced with VMware vSphere. VMXnet3 is a Highspeed-Network-Driver and i highly recommend using VMXnet-Drivers with Citrix Provisioning Services.

The Update for the latest PVS-Version (5.6 SP1) can be found here: Hotfix CPVS56SP1E011

As always, backup your vDisks before updating...

Joern

Published Applikations von MetaFrame XP über Web-Interface 5.3 starten...

Hi,

bei einem meiner Kunden migriere ich gerade diverse alte Umgebungen (MetaFrame XP und PS4.0) in eine neue XenApp 5-Infrastruktur. Dazu gehört auch das Update der vorhandenen Web-Interfaces von 5.1 auf 5.3. Bei diesem Update gab es ungeahnte Probleme zu lösen:
Bei dem Kunden greifen die Benutzer entweder direkt über das WebInterface oder per PNAgent-Funktion des Online Plug-Ins auf die veröffentlichten Ressourcen der unterschiedlichen Farmen zu. Die Farmen werden in den WI-Sites der Web-Interfaces zusammengefasst. Beim Test-Update auf 5.3 fiel dann auf, dass veröffentlichte Ressourcen aus PS4.0- und XA5-Umgebungen gestartet werden konnten, die Ressourcen aus der MetaFrame XP-Farm aber nicht...daraufhin hab ich kurz das KnowledgeCenter durchsucht und auch schnell einen Lösungsansatz für das Problem gefunden. In der webinterface.conf soll der folgende Wert geändert / aktiviert werden: RequireLaunchReference=Off.
Die Fehlerbehebung soll zwar eigentlich bei PS4.0-Farmen helfen (siehe auch CTX123003), funktioniert aber auch bei MetaFrame XP :-)
Allerdings lässt sich damit nur die eigentliche Web-Interface-Site zum Funktionieren bewegen, nicht die Services-Site. Aufrufe der MetaFrame XP-Applikationen über die PNAgent-Funltion schlugen weiterhin fehl. Auch die Knowledgebase lieferte keine weiteren Hinweise. Über einen Vergleich von alter und neuer webinterface.conf habe ich dann den Hinweis zur Lösung gefunden. In der PNAgent-Site muss zusätzlich noch der folgende Wert gesetzt / aktiviert werden: OverrideIcaClientname=On. Damit ließen sich dann auch über ein aktuelles Online Plug-In in Verbindung mit dem Web-Interface 5.3 wieder Applikationen aus einer MetaFrame XP-Farm starten. Warum dem so ist, weiß ich allerdings nicht so genau, denke aber, dass es mit der Funktion SessionReliability zusammenhängt, die es in MetaFrame XP ja noch nicht gibt.

J.

PVS 5.6 SP1 - Problem with local WriteCache (again)...

Hi, this post is in English because i think the problem may be interesting for non-german-speaking-people too.

In the past Citrix had some issues with Local WriteCache in Provisioning Services, but it seemed that they had finally solved the problems with 5.1 SP2...there weren't issues with 5.6, but there seem to be issues with 5.6 SP1. In our configuration the 5.6 SP1 Target Device ist not able to create the WriteCache-File on the local attached disk of a VM. The issues is now under investigation from Citrix Engineering so i recommend not to upgrade to PVS5.6 SP1 Target Device. The issues seems to be in the bnistack.sys-Driver of the PVS Target Device. I think it is ok to upgrade the PVS-Servers to 5.6 SP1, but i recommend testing the upgrade first and as always backup your configuration (PVS-Database, ...). Older Target Device Version (5.6 oder 5.1 SP2) seem to work well even if the PVS-Server is already upgraded to the latest Version.

This is the configuration producing the error:

PVS-Server: 
W2K3 SP2, 32-Bit, PVS 5.6 SP1, Hotfixes CPVS56SP1E002, CPVS56SP1E005, CPVS56SP1E008

PVS-Target-Device:
WinXP SP3, 32-Bit, PVS 5.6 SP1, Hotfixes CPVS56SP1E002

If you're facing the same or a similar issue, feel free to leave a comment in the following discussion in the Citrix-Support-Forum: Topic about PVS 5.6 SP1 WriteCache Problem in Citrix-Support-Forum


I will post an Update, as soon if i receive any valuable information.


Joern

Support-Tools für XD5: XDDBDiag und XD Session State Monitoring

Moin Moin, Citrix hat zwei neue, aus meiner Sicht sehr sinnvolle, Support-Tools für XD5 herausgebracht (und eines aktualisiert):

XDDBDiag: Konsistenzcheck der XD5-Datenbank und allgemeine Debug-Informationen

• XDDBDiag - Download 

XenDesktop Session State Monitor Tool: Monitoring aktiver oder inaktiver Sitzungen auf dem Virtual Desktop Agent (VDA)

• XenDesktop Session State Monitor Tool - Download

 CDFControl 2.5: (Live-)Analyse von Citrix Trace-Providern und einfache Auswertung vonXenDesktop-Logfiles in grafischer Oberfläche.

• CDFControl 2.5 -Download

J.

ACHTUNG: Citrix XenServer 5.6 can become unresponsive with Intel Westmere / Nehalem...und XenDesktop-Sizing-Information...

Hallo zusammen,
hier eine wichtige Info von Citrix bzgl. XenServer 5.6 in Verbindung mit Intels Westmere- / Nehalem-Prozessoren: Der XenServer kann ganz plötzlich und ohne erkennbarren Grund seine Arbeit einstellen. Wirkliche Gründe dafür geben auch die Logfiles leider nicht her...der Grund ist laut Citrix in den Intel-Prozessoren zu finden, in denen neue Power-Management-Features (Deep C-States) integriert wurden. Diese machen wohl grundsätzlich Probleme und führen beim XenServer zu den genannten Abstürzen. Deshalb empfiehlt Citrix die Deep C-States im BIOS vorerst zu deaktivieren, bis Intel ein entsprechendes Microcode-Update herausbringt, welches die Fehler beheben soll. Anbei der Link zu dem entsprechenden CTX-Artikel:
Hosts Become Unresponsive with XenServer 5.6 on Nehalem and Westmere CPUs 

Des Weiteren ist vor kurzem mal wieder ein interessantes Whitepaper zu XenDesktop bzw. dem Sizing von Desktop-Virtualisierungs-Infrastrukturen erschienen. Das Whitepaper betrachtet u.A. das Thema Iops. Es wurde von Daniel Feller verfasst, einenm der besten Citrix-Architekten im Desktop-Virtualisierungsumfeld.
Das ganze ist wirklich extrem lesenswert, auch für Leute, die sich für Alternativlösungen im Umfeld der Desktop-Virtualisierung interessieren. Anbei der Link:
XenDesktop Planning Guide - Hosted VM-Based Resource Allocation

Wünsche eine erfolgreiche Woche...

Joern

Aktuelle Infos zum XenServer 5.6...

Hallo zusammen,

nach langer Zeit mal wieder ein Update...diesmal dreht es sich um den XenServer 5.6.

XenServer 5.6: Problem mit CD-ROM-Treiber!

Bei dem neuen Release hat sich ein "böser" Bug eingeschlichen, der zu erheblichen Performance-Problemen führen kann. Folgendes habe ich selber leidlich in einem Projekt erfahren "müssen:

Problem
Die XenServer-Umgebung ist extrem langsam, sämtliche Aktivitäten (egal ob im XenCenter, innerhalb der VMs, oder auf der XenServer-Konsole) sind überdurchschnittlich langsam…das booten einer VM dauert z.B. bis zu 1h. Sämtliche Pool-Operation scheinen aber noch zu funktionieren, im XenCenter werden keine Warnmeldungen angezeigt.

Analyse
Auf den ersten Blick ist alles ok, sämtliche Netzwerkverbindungen und Storage-Verbindungen sind aktiv / online. Die Auswertung der Performance-Statistiken der Hosts im XenCenter zeigt allerdings, dass CPU0 zu 100% ausgelastet ist (alle anderen CPUs sind idle bzw. verhalten sich normal). Durch Eingabe des Befehls „top“ auf der Linux-Konsole eines XenServers erhält man die Übersicht der laufenden Prozesse. Diese zeigt, dass der Prozess cdrommon diese 100% erzeugt.

Weiteres Vorgehen / mögliche Fehlerbehebung
Scheinbar kommt es zu einem Problem beim Zugriff auf das pyhsiklisch eingebaute CD-ROM-Laufwerk des XenServers…ggf. tritt dieses Problem auch nur mit einem spezifischen CD-ROM-Laufwerk auf (TEAC…). Ein Kill auf die Prozess-ID (kill %PID)
von cdrommon beendet den Prozess, danach ist erst mal alles wieder in Ordnung. Ob dies dauerhaft hilft, kann ich momentan nicht sagen. Ob dies Funktionseinschränkungen mit sich bringt, weiß ich ebenfalls nicht. Die Workaround-Empfehlung vom Citrix-Support ist, das CD-ROM im BIOS zu deaktivieren. Zumindest bei HP-Servern (konkret bei einem DL 580 G5) ist dies aber so nicht möglich. Ich habe testweise bei besagtem HP-Server USB ausgeschaltet, da ich vermute, dass das interne CD-ROM über USB angesprochenwird. Der XenServer scheint danach auf den ersten Blick normal zu arbeiten.

Weitere Informationen
Citrix hat aktuell einen Private-Fix im Test, der das Problem scheinbar behebt. Durch den Fix wird ein neuer CD-ROM-Treiber installiert. Um den Fix zu aktivieren, ist ein Reboot des XenServers notwendig.
Des Weiteren scheint das Problem nur auf Systemen aufzutreten, die ein physikalisches CD-ROM haben. Blade-Servern scheint also „erstmal“ keine Gefahr zu drohen. Anbei noch ein paar Links zu entsprechenden Diskussions-Strängen im Citrix Support-Forum.

Thread #1
Thread #2

XenServer 5.6: Operating System Fix-Up

Bei der Portierung von VMs aus einer VMware in eine XenServer-Umgebung gibt es oftmals einige Probleme, die im schlimmsten Fall verhindern, dass die importierte VM erfolgreich startet. Um dies zu verhindern, ermpfiehlt Citrix generell, vor der Portierung alle plattformspezifischen Treiber (VMwareTools) zu deinstallieren. Sollte dies nicht aureichen, bietet Citrix ein Operating System Fix-Up an, das diverse Probleme mit importierten VMs automatisch behebt. Die Funktion ist in dem folgenden CTX-Artikel beschrieben:

XS 5.6: Operating System Fix-Up

Das entsprechende ISO-Image wird mit dem XenCenter 5.6 installiert und kann dann einfach in eine XenServer ISO-Bibliothek importiert und von dort über das DVD-Rom genutzt werden. Entweder man ruft das Operating System Fix-Up direkt mit dem Import der Maschine (über den Assistenten) auf oder stellt im Nachhinein in der Boot-Reihenfolge der VM das DVD-Laufwerk an erste Position und lädt einfach das entsprechende ISO in das DVD-Laufwerk. Der Rest läuft dann von allein. Das Fix-Up beendet sich automatisch, danach kann man probieren, die VM wieder normal von der Festplatte zu starten.

VG,

Jörn

Provisioning Services - Bad Cache Redirection Performance...

Hallo zusammen,

vor einiger Zeit gab es in den Citrix Support-Foren eine interessante Diskussion zum Thema Performance des Write-Cache-Redirects, wenn sich der Write-Cache auf einer lokalen Disk befindet (was aus Performance-Gründen die Standard-Konfiguration sein sollte). Die Diskussion findet sich hier:

Diskussion in Citrix Support-Forum

Die Diskussion enthält einige sehr interessante Erkenntnisse / Informnationen, die so nirgendwo dokumentiert sind. Speziell die Aussagen von Carl Fallis (Citrix) sind interessant:

Here is what happens when using local hard drive caching and booting:
1. PVS checks to see where the location of the pagefile is set:

- If it is set to C: it will modify the registry to set it to D:, E: F: (yes all three)

-This is why I would recommend if you are using local hard drive cache and you can set your page file to the
local driver (say D: in most cases) I would do this in the Vdisk in private image mode.

2. PVS checks the size of the local partitions to determine where to locate the cache file, the process is:

- If the cache file already exists it will be deleted

- If the partition free space is larger than the Vdisk size PVS will stop searching and use this partition for local
cache file.

- If no partition is larger than the Vdisk size the partition with the largest free space will be used (All partitions
will be searched)

- The local partition must have at least 500MB free to be considered for local cache

- If no partition has 500MB free the client will default to server side cache

3. Once a partition is selected the cache file is created

- If the free space of the disk is smaller than the VDisk then the file will be created using
FILE_NO_INTERMEDIATE_BUFFERING which will impact performance since it does not take advantage of
the buffering capability of the disk driver/drives.

- If the free space of the disk is larger than the VDisk then it defaults to creating the file with buffering.

Die Diskussion endet ebenfalls mit einem Eintrag von Carl Fallis, der auf den folgenden Patch verweist: Hotfix CPVS51SP2E003

Durch Installation des Patches ist es möglich, das Buffering-Verhalten manuell zu steuern. Grundsätzlich ist das Buffering zu empfehlen, da es eine bessere Performance bietet.

Aber ACHTUNG: Das Buffering kann ggf. auch Probleme hervorrufen, wie z.B. hängende Systeme. Und mit steigendem Füllgrad der Write-Cache-Disk lässt auch die Performance nach!

Deshalb folgende Tipps:

- Reboot tut gut (in diesem Fall zur Bereinigung der Write-Cache-Disk)!
- Neue Funktionen (auch Buffering) bitte unbedingt vorher testen, wichtig ist hierbei vor allem das Verhalten des provisionierten Systems unter Last!

Jörn