Ein Kommentar zu dem Artikel PXE Install für VMware ESXi brachte die Frage auf, ob es denn auch möglich sei, eine unattended PXE Installation für ESXi durchzuführen.

Auf den ersten Blick scheint das von VMware so nicht vorgesehen zu sein. Dankenswerterweise jedoch ist die komplette Installationsroutine in Python geschrieben und somit einfach zu manipulieren.

In unserer pxelinux Konfiguration übergeben wir dem Kernel bereits zusätzliche Argumente

APPEND esx4iu1/vmkboot.gz --- esx4iu1/vmkernel.gz --- esx4iu1/sys.vgz --- esx4iu1/cim.vgz --- esx4iu1/ienviron.tgz --- esx4iu1/image.tgz --- esx4iu1/install.tgz

Interessant in unserem Fall sind ienviron.tgz und install.tgz.  ienviron.tgz ist der generische Python Installer, install.tgz sind die – für eine ESXi notwendigen – Installationsschritte. Der Lösungsansatz ist nun, die Tastatureingabe für jeden Installationsschritt einfach fest in die Installationsdatei einzutragen und somit die Interaktion zu umgehen.

Achtung! Das ist keine offizielle Herangehensweise und ich übernehme keine Verantwortung für eventuelle Schäden!

# cd /tftpboot/esx4iu1
# cp ienviron.tgz ienviron.tgz.orig
# mkdir tmp ; cd tmp ; tar xzf ../ienviron.tgz
# vi usr/lib/vmware/installer/Core/TUI/Display.py

In der Datei Display.py müssen wir die Funktion Run suchen. Diese ist dafür zuständig, den einzelnen Dialogen (Welcome, EULA, usw.) die Benutzereingabe zu übergeben. Hier tauschen wir einfach die “eingegebenen” Tasten durch “Enter” und “F11″ aus. Achtung: In Python ist die Einrückung wichtig, Tabs mag der Interpreter gar nicht.

def Run(self):
  while not self.currentDialog.terminate:
  self.Draw()
  # keys = self.ui.get_input()
  keys = [ 'enter', 'f11' ]
  for k in keys:
    # pass keystrokes to the current widget
    k = self.currentDialog.keypress(self.size, k)

Anschließend packen wir die von uns geänderten Sourcen wieder zu einem Tarball.

# tar czf ../ienviron.tgz *

Das wars auch schon, der Installer wird nun nicht mehr nachfragen und durch die einzelnen Dialoge springen.

Ich bin mir sicher, dass es hier noch wesentlich elegantere Möglichkeiten gibt, hat man die Zeit, könnte man das ganze Installationsframework patchen, um eventuell eine Konfiguration ala ks.cfg einzulesen.

Viel Spaß beim Nachbauen!

Bereits mit der Einführung von vSphere und VDR war es absehbar, aber seit Ende Februar ist es offiziell: VMware Consolidated Backup (VCB) wird es in zukünftigen vSphere Feature Releases nicht mehr geben. Bestehende Installationen können es weiterhin nutzen und gemäß VMware Support Life Cycle wird es auch weiterhin supported sein. Es wird aber weder mit neuen vSphere Feature Releases zusammenarbeiten, noch kann man erwarten, dass es sich fundamental verbessern wird.

“With the release of the next vSphere platform, we will continue to provide the binaries for VCB, but they will not be compatible with the next platform release. We will continue to provide support for VCB on the current vSphere platform per the VMware support policy.”

Ist das schlimm? Ganz im Gegenteil! Mit der vStorage API for Data Protection (VADP), darauf aufsetzenden Produkten (3rd-Party oder VDR) und speziell vSphere-Umgebungen warten Features auf den Backup-Admin, die VCB schnell vergessen machen.

vStorage API for Data Protection – was genau ist das eigentlich?

Dank viel Marketing-Buzzwords ist es anfänglich alles andere als einfach zu verstehen, was konkret hinter der vStorage API for Data Protection steht. Dabei ist es gar nicht so kompliziert! VADP ist …

• ein Marketing-Begriff von VMware.
• Besteht aus: vSphere SDK und Virtual Disk Development Kit (VDDK)
• Ermöglicht Entwicklern also Zugriff auf vCenter/ESX/ESXi Management-Funktionen und auf VMFS Dateisysteme / VDMK-Dateien
• Ein Mitglied der “vStorage API”-Familie
  (for Data Protection, for Multipathing, for Array Integration, for Site Recovery Manager)

Konkret bedeutet dies, dass Backup-Software-Hersteller wie Veeam, Vizioncore, PHD Virtual und Co. mit Hilfe der VADP ohne VCB direkt an die Funktionalitäten und VM-Daten zu Sicherungszwecken kommen. Keine halbherzige Integration über das mitunter umständlich zwischengeschaltete VCB, keine komplette Kopie von Sicherungsdaten über den VCB Proxy. Direkter Zugriff auf Snapshots über SAN, LAN oder via von VCB bekanntem Hot-Add-Modus. Alles rein mit der 3rd-Party-Backup-Lösung.

Was ist daran nun neu oder besser?

VCB war bisher de-facto ein zwischengeschaltetes Element zwischen vStorage API und der Backup-Lösung, womit es ein Subset der API-Möglichkeiten nutzbar machte. Mit dem kompletten Schwenk auf die vStorage API fällt dieses Integrationselement nun weg. Backup-Hersteller bekommen vollen Zugriff auf Features, System-Administratoren müssen eine Komponente weniger managen, und Finger-Pointing zwischen Herstellern beim Troubleshooten von Problemen wird reduziert.

Und es kommt noch besser: Im Zusammenspiel mit vSphere 4 Features wie Changed Block Tracking (CBT) lassen sich Backup-Zeiten radikal verkürzen. Dazu demnächst mehr. Derweil gibts für alle diejenigen, die das Thema VCB vs. VADP sowie dessen Historie interessiert und die ca. 50 Minuten mitbringen im VMTN Podcast #71 einige interessante Hintergrundinfos von VMware.

Wer unterstützt VADP?

Neben der VMware-eigenen Lösung VDR, haben die spezialisierten VMware-Backup-Lösungsanbieter wie Veeam, Vizioncore, PHD Virtual & Co VADP Support bereits in ihre Lösung integriert und auch die meisten großen, klassischen Backup-Hersteller sind schon auf den Zug aufgesprungen. Das bedeutet jedoch nicht notwendigerweise, dass alle von VADP bereitgestellten Features – wie z.B. direkte Sicherung/Rücksicherung vom/zum SAN – von diesen Lösungen auch tatsächlich genutzt werden. Ein Vergleich lohnt sich also.

Bei der Arbeit mit dem VMware Perl SDK oder darauf basierenden Skripten wird schnell ersichtlich, dass die Laufzeit selbst für eigentlich simple Aufgaben enorm lange ist. Warum dem so ist, warum das für Monitoring-Zwecke unschön ist und wie man dem oft erlebten Phänomen etwas entgegenwirken kann, wollen wir hier kurz beleuchten. Primär interessant für Skript-Schreiber, als Hintergrundwissen aber auch für Skript-Benutzer, die sich schön öfter über die Laufzeit ihrer Perl Skripte gewundert haben.

Resourcen-intensiv und l a n g s a m

Gutes Beispiel für das Problem ist das in Perl geschriebene check_esx3.pl von OP5, was von Haus aus nicht nur lange läuft, sondern die ausführende Maschine auch merklich unter Last setzt. Ebenso das hier kürzlich vorgestellte check_snapshots.pl. Ein dstat Mitschnitt auf dem Monitoring-Host zeigt beim Skript-Aufruf eine über Sekunden gesättigte CPU und nicht unerheblichen Speicherverbrauch (>100MB!). Merke: Das alles, nur um eine Liste von verwaisten Snapshots zusammenzustellen. Der interessante Abschnitt reicht von 17:07:01 bis 17:07:08.

-----time----- ----total-cpu-usage---- ------memory-usage----- -net/total-
  date/time   |usr sys idl wai hiq siq| used  buff  cach  free| recv  send
25-02 17:06:58|  0   0 100   0   0   0|  95M   55M  207M  142M| 546B  840B
25-02 17:06:59|  0   0  99   0   0   1|  95M   55M  207M  142M| 564B  204B
25-02 17:07:00|  7   1  92   0   0   0| 102M   55M  207M  135M| 758B  456B
25-02 17:07:01| 90   9   1   0   0   0| 154M   55M  207M   83M|2259B 1045B
25-02 17:07:02| 50   4  46   0   0   0| 174M   55M  207M   63M| 419k   18k
25-02 17:07:03| 76   9  14   0   0   1| 214M   55M  207M   23M|2770k   37k
25-02 17:07:04|100   0   0   0   0   0| 214M   55M  207M   23M| 120B    0
25-02 17:07:05| 99   1   0   0   0   0| 214M   55M  207M   23M| 240B    0
25-02 17:07:06|100   0   0   0   0   0| 217M   55M  207M   20M| 120B   42B
25-02 17:07:07| 99   1   0   0   0   0| 220M   55M  207M   17M| 180B    0
25-02 17:07:08| 61   2  37   0   0   0|  96M   55M  207M  141M|1356B 4531B
25-02 17:07:09|  1   0  99   0   0   0|  96M   55M  207M  141M| 300B    0
25-02 17:07:10|  0   0 100   0   0   0|  96M   55M  207M  141M|  60B    0

Das wiederum ist lediglich die Sicht des Monitoring-Hosts, sowohl auf dem vCenter System als auch auf den ESX-Servern sind ähnliche Last-Spitzen zu sehen. Die Laufzeit bei einer VMware Landschaft mit 4 ESX Hosts und ca. 100 VMs beträgt etwa 8 Sekunden.

real    0m7.578s
user    0m6.666s
sys     0m0.251s

Spielt man das jetzt hoch und überlegt sich, mehrere, dedizierte, Perl-basierte Checks laufen zu lassen, kann man sich schnell errechnen, dass dem Monitoring-Host (mit Nagios, Icinga oder Co) schnell die Puste ausgehen wird.

Es geht auch schneller

Der Schlüssel liegt im Standard-Verhalten des Perl SDKs beim Datenaustausch, denn bei Abfragen von VMs werden per se alle zugehörigen Daten vom vCenter/ESX abgefragt – auch wenn ein kleines Subset für den konkreten Zweck eines Skriptes ausreichen würde. Ergo müssen vCenter/ESX all diese Daten aufbereiten und übers Netz schicken, während die Perl SDK Routinen auf der Empfängerseite all die erhaltenen Datenstrukturen (benötigt oder nicht) parsen und intern in Objekte umwandeln müssen. Alles sehr CPU- und Zeit-aufwändig.

Dass es auch zielführender und schneller geht, verrät ein kleiner Absatz des vSphere SDK for Perl Programming Guide auf Seite 34 (“Filtering Views Selectively Using Properties”).

The view subroutines—get_view(), get_views(), find_entity_view(), and find_entity_views()—can accept a properties argument that consists of a list of property paths for retrieval from the server.

Man kann also bei der Abfrage angeben, welche konkreten VM-Daten benötigt werden. Testen wir das mal in der Praxis.

Testweise angewandt auf check_snapshot.pl

Naiv angewandt auf das check_snapshot.pl Skript ergibt sich ein nicht zu verachtender Unterschied: Laufzeit reduziert auf 2-3 Sekunden, Speicherverbrauch reduziert um ca. 50MB.

-----time----- ----total-cpu-usage---- ------memory-usage----- -net/total-
  date/time   |usr sys idl wai hiq siq| used  buff  cach  free| recv  send
25-02 17:07:24|  0   0 100   0   0   0|  96M   55M  207M  141M| 240B    0
25-02 17:07:25|  0   0 100   0   0   0|  96M   55M  207M  141M| 120B    0
25-02 17:07:26| 54   7  39   0   0   0| 131M   55M  207M  106M|2541B 1147B
25-02 17:07:27| 91   7   2   0   0   0| 174M   55M  207M   63M|5847B 2346B
25-02 17:07:28| 64   1  35   0   0   0|  96M   55M  207M  141M| 319k   18k
25-02 17:07:29|  0   0 100   0   0   0|  96M   55M  207M  141M|  60B    0
25-02 17:07:30|  0   0 100   0   0   0|  96M   55M  207M  141M| 240B    0

real    0m2.326s
user    0m2.062s
sys     0m0.163s

Einzige Änderung hierfür ist eine hinzugefügte Zeile, über die wir spezifizieren an welchen Daten wir konkret interessiert sind.

my $vms = Vim::find_entity_views(
    view_type => 'VirtualMachine',
    filter => $filter,
    properties => ['summary', 'snapshot'] 
);

Das lässt sich ggf. noch weiter optimieren, denn aus der Summary benötigen wir für die Zwecke des Skriptes nur den Namen. Aber immerhin, bereits mit dieser einfachen Änderung ist viel erreicht. Stolperfalle bei der Verwendung von properties ist natürlich, dass auch nur die tatsächlich angefragten Properties im weiteren Skript-Verlauf zur Verfügung stehen. Bei Trial&Error sowie Data::Dumper Programmierung sollte man sich das nochmal bewusst machen.

Fazit

Sobald man weiß, worin sich die Langsamkeit der meisten Perl SDK Skripte begründet, kann man dagegen angehen und das properties Flag beim Abfragen einer VMware Landschaft bietet dazu eine einfache Möglichkeit. Kleine Änderung, große Wirkung.

Snapshots virtueller Maschinen sind ein gern genutztes Feature, denn speziell bei Upgrade-Aktionen ermöglichen sie einen einfachen Rollback-Pfad. Andererseits, und das ist in der vollen Tragweite meist weniger geläufig, sind sie ein zweischneidiges Schwert.

Snapshot-Stolperfallen …

Die offensichtlichen Einschränkungen von virtuellen Maschinen mit Snapshots sind in aller Regel noch klar:

• kein Storage VMotion
• keine dynamische Plattenvergrößerung
• keine physikalischen Raw Device Mappings
• kein Fault Tolerance

Weniger klar ist, dass mit der VM lebende Snapshots keine gute Idee für längerfristige Backups sind, einen nicht zu unterschätzenden Performance-Impact haben und im Zweifelsfall sogar zum Ausfall von VMs führen können. Die Liste von Stolperfallen mit Snapshots kann man beliebig fortsetzen (Beispiele hier, hier und hier). Quintessenz ist dabei immer, Snapshots sind äußerst praktisch für den Moment, aber nicht dafür bestimmt, dauerhaft mit der VM weiterzuleben.

… und Ansätze zur Verwaltung

Erfahrungsgemäß finden sich jedoch nach einer gewissen Zeit in jeder Umgebung verwaiste Snapshots, deren Existenz immer wieder zu Problemen führt. Ansätze, um dem entgegenzuwirken gibt es einige: Man kann via vCenter Alarme für Snapshots definieren (etwas mühselig), via Powershell-Skript die Ersteller von alten Snapshots automatisiert benachrichtigen, den snapshotmanager.pl des Perl SDKs zum Anzeigen verwenden oder aber den Report von William Lam’s VMware Health Check begutachten, der neben vielen anderen Metriken einer VMware Landschaft auch existente Snapshots analysiert und im Report je nach Alter farblich hervorhebt.

Finde Snapshots (jenseits einer Altersgrenze)

Wenn man jedoch eine simple Kommandozeilen-basierte Lösung benötigt, die Snapshots über einer gewissen Altersgrenze sucht und sich in Nagios integrieren lässt, findet man lediglich host-zentrierte Ansätze wie diesen hier, was bei größeren Umgebungen schnell umständlich wird. Folgender Perl-Schnipsel lässt sich vom vMA oder einem Management-System mit Perl SDK absetzen und findet alle Snapshots jenseits eines gewissen Alters.

#!/usr/bin/perl

# check_snapshots.pl: Displays VMs with snapshots older than a given age
#
# Extra packages required (URL given for vMA suitable RPMs)
# * Date::Parse from http://vault.centos.org/5.2/extras/i386/RPMS/

use strict;
use warnings;
use VMware::VIRuntime;
use Date::Parse;

my @badsnaps = ();

Opts::parse();
Opts::validate();
Util::connect();

# Get the service content reference, root to most of the API features
my $sc = Vim::get_service_content();

# Fetch only the given VM or all VMs
my $filter = $ARGV[0] ?  { 'name' => "$ARGV[0]" } : { };
my $vms = Vim::find_entity_views(
    view_type => 'VirtualMachine',
    filter => $filter
);

# Hardcoded for now, 1d = 86400s, 1w = 604800s, and so on
sub older_than_treshold {
  my $created = shift;

  if ((time() - $created) > 604800) {
     return 1;
  }
  return 0;
}

sub by_date_asc {
  $a->{'date'} <=> $b->{'date'}
}

# Traverse a snapshotlist including possible sub-trees, in fact we would
# only need to check for the root snapshot (which is the oldest one)
sub check_snaplist {
  my $vm_name = shift;
  my $vm_snaplist = shift;

  foreach my $vm_snap (@{$vm_snaplist}) {
    if ($vm_snap->{childSnapshotList}) {
      check_snaplist($vm_name, $vm_snap->{childSnapshotList});
    }

    my $epoch_snap = str2time($vm_snap->{createTime});
    next unless (older_than_treshold($epoch_snap));
    $badsnaps[scalar(@badsnaps)] = {
      'vm' => $vm_name,
      'snap' => $vm_snap->{name},
      'date' => $epoch_snap,
      };
  }
}

# Loop over VMs and check each one for snapshots
foreach my $vm_view (@{$vms}) {
  my $vm_name     = $vm_view->{summary}->{config}->{name};
  my $vm_snapinfo = $vm_view->{snapshot};

  next unless defined $vm_snapinfo;
  check_snaplist($vm_name, $vm_snapinfo->{rootSnapshotList});
}

# Display the list of "bad" snapshots, from oldest to newest
map {
  printf "%-30s: %-40s  created on %s\n",
    $_->{'vm'}, substr($_->{'snap'},0,40), scalar localtime $_->{'date'}
  } sort by_date_asc @badsnaps;

END {
        Util::disconnect();
}

Beispiel

Die Ausgabe sieht exemplarisch folgendermaßen aus.

[vi-admin@vma ~][vcenter.roc.consol.de]$ ./check_snapshots.pl
amber11.roc.consol.de         : pre-iscsi-tests                           created on Thu Nov 12 11:08:16 2009
amber21.roc.consol.de         : amber-before-reset                        created on Thu Nov 26 09:54:13 2009
ray42.roc.consol.de           : demo                                      created on Wed Jan 13 17:15:02 2010
ray42.roc.consol.de           : demo1                                     created on Wed Jan 13 17:21:19 2010

Mit ein paar Zeilen mehr lässt sich das in ein Nagios Plugin umbauen. Gutes Gelingen bei der Snapshot-Jagd!

Am 25.2.2010 werde ich den ersten WebCast zum Thema Desktop Virtualisierung moderieren. VMware hat Ende letzten Jahres VMware View 4 vorgestellt. ConSol hat sich in Projekten, aber auch im eigenen Test Labor mit der Desktop Virtualisierung auseinandergesetzt. Die Experten haben verschiedenste Konfigurationen ausprobiert und die neuen Funktionen getestet. Auch die Performance von VMware View 4 wurde gründlich untersucht. Nach der Feststellung der typischen Anforderungen der IT werde ich die einzelnen Komponenten der VMware Infrastruktur vorstellen.

Aber in dem WebCast werden auch ConSol Experten zu Wort kommen. So wird dann die Vorstellung der Produkte durch Praxis Tipps ergänzt. Daniel Reinold und Peter Weiss werden zum Beispiel den Ablauf einer ThinApp-Erstellung demonstrieren. Der WebCast lief schon in der ConSol Akademie und das Feedback war sehr positiv. Ich freue mich auf eine rege Teilnahme.

VMware View und Sun VDI sind bekannte Produkte für die Desktop-Virtualisierung. Kaviza bietet hierzu mit VDI-in-a-box eine Alternative an. Die wesentlichen Vorzüge liegen in der Bereitstellung des Installationspakets als Virtual Appliance und im somit sehr komfortablen Import über vCenter. Alle notwendigen VDI-Komponenten sind bereits enthalten. Die virtuelle Maschine, die dann nach erfolgreicher Installation vorhanden ist, basiert auf Ubuntu Linux 8.04.2 und wird als Kaviza Manager virtual Appliance (kMGR) bezeichnet. Aufgabe des kMGR ist die Erzeugung und Verwaltung der virtuellen Desktops, auf die die Benutzer per Webbrowser von einem ThinClient oder PC zugreifen.

Aktuell werden die folgenden Hypervisor-Versionen unterstützt:

• ESX Server 3.5/ ESXi 3.5 Updates 3&4
• ESX Server 4.0 / ESXi 4.0
• Virtual Infrastructure Client oder vSphere Client für die Installation der gelieferten Appliance

Für die virtuelle Maschine, welche dann in VDI-in-a-box verwendet wird, gelten aktuell unter anderem die folgenden Einschränkungen:

• nur Windows XP (32-Bit) oder Windows 7 (32-Bit)
• dürfen nur EIN disk image mit maximal 35Gb haben

Die virtuellen Desktops, welche vom kMGR erstellt und verwaltet werden, beinhalten das Desktop-Betriebssystem, eine oder mehrere Applikationen und den Kaviza Desktop Agent (kDA). Dieser ist für die Kommunikation mit dem kMGR zuständig und protokolliert Login-Vorgänge der Benutzer, sowie den Zustand der virtuellen Desktops. Zur Administration des kMGR steht eine Web-basierte Konsole bereit.

Existieren weitere Hypervisor mit installiertem kMGR, ist es sinnvoll, diese zu einem Kaviza Grid zu verbinden. Hierdurch wird eine Lastverteilung, eine Koordination der VM-Aktivitäten und Ausfallsicherheit gewährleistet. Da das Kaviza Grid selbständig verwaltet wird, ist die Verwendung von VMware HA, VMware DRS und vMotion nicht unterstützt.

Wie bei Sun VDI gibt es bei virtuellen Desktops von VDI-in-a-box die Möglichkeit diese einfach “mitzunehmen”. Dies bedeutet, dass, wenn der Benutzer sich vom Desktop eines Endgerätes trennt und sich an einem anderen Endgerät wieder anmeldet, er seinen zuvor benutzten Desktop 1:1 wieder vorfindet. Die Liste der Merkmale wird ergänzt durch zeitbasierte, dynamische Desktops, beispielsweise für Schichtarbeiter oder für Arbeiten im Lab, sowie durch statische und Kiosk-Mode Desktops. Bei der zuletzt genannten Möglichkeit wird nach jedem Gebrauch ein neuer Desktop zur Verfügung gestellt, welcher auch eingeschränkten Zugriff beinhalten kann.

Die Zielgruppe für VDI-in-a-box von Kaviza dürften in erster Linie Schulungs- und Testumgebungen oder auch die Produktionsumgebungen von kleineren bis mittelgroßen Firmen sein. Denkbar sind natürlich auch noch andere Einsatzgebiete.

In unserer letzten Pressemitteilung zum Thema Virtualisierung haben wir unser 3 Phasen-Modell vorgestellt. Entscheidend hierbei ist für mich der erste der drei Teile, die Analyse, in dem ich klären muss, warum ich virtualisieren will, und welche Ziele ich damit zu verfolgen gedenke.

Mögliche Ziele wären z.B.

• Kostenreduktion
• Anzahl der Server verringern und folglich Strom sparen
• Umgebungen zu standardisieren
• Den “Coolness”-Faktor erhöhen
• Datensicherheit verbessern
• Vereinfachung von IT-Compliance
• Unternehmenszusammenschlüsse
• Abhängigkeiten zu externen Lieferanten reduzieren

Neben den Zielen spielen aber auch die vorhandenen Gegebenheiten eine große Rolle bei der Auswahl der richtigen Lösung. Das heißt: Welche bereits bestehenden Systeme kann ich wiederverwenden, bzw. welche muss ich neu anschaffen? Habe ich Virtualisierungs-Know-how im Hause oder muss ich es mir extern zukaufen? Welche Art von Lizenzen – sowohl Client als auch Server – habe ich bereits, und welche kann ich wiederverwenden?

Wenn all diese und noch viel mehr Ansatzpunkte geklärt sind – und nur dann – macht es aus meiner Sicht einen Sinn, die Migration hin zu einer virtualisierten Umgebung zu planen. Essentiell hierbei ist, das Projekt wirklich zu planen und nicht mal “so nebenbei” zu erledigen. Dabei ist es wichtig, die Ziele und die damit verbundenen Use Cases immer mit den Anwendern zusammen zu erarbeiten, sie zu priorisieren und gemeinsam zu testen. Falls dies nicht geschieht, besteht die Gefahr, dass Ihre Virtualisierungslösung nicht den gewünschten Erfolg bzw. die nötige Akzeptanz erzielen wird.

Die mit 140 Besuchern restlos ausverkaufte Veranstaltung am vergangenen Donnerstag startete pünktlich um 9.15 Uhr mit der Begrüßung durch den stellvertretenden LANline-Chefredakteur Dr. Greiner. Die darauffolgende Keynote fand ich persönlich enttäuschend, da sie aus meiner Sicht lediglich eine Aufzählung von Produkt-Features der drei Marktfüherer VMware, Citrix und Microsoft war. Da hätte ich mir einen analytischeren Blick auf den Markt oder eine Vision erwartet, zumindest aber einen Ausblick auf die kommenden Monate.

Wer noch nicht genug von Features gehört hatte, konnte sein Wissen bei zwei anschließenden Vorträgen der Hauptkonkurrenten Citrix und VMware (vertreten durch DNS) weiter vertiefen. Im Fokus standen selbstredend die Desktop-Virtualisierungs-Produkte Citrix XenDesktop 4 und VMware View 4. Interessant fand ich die Tatsache, dass – obwohl beide Anbieter versuchten, sich voneinander weitmöglichst abzugrenzen – viele Folien inhaltlich nahezu kongruent waren.

Nach einem vorzüglichen Mittags-Buffet und diversen Produkt-Vorstellungen der Sponsoren, kam mein persönliches Highlight der Veranstaltung, ein Vortrag zu Migrationsstrategien für Desktop-Virtualisierung. Sehr erfreulich empfand ich, dass der Vortrag herstellerunabhängig war und – übrigens ähnlich der ConSol*-Strategie - die mit Virtualisierung angestrebten Ziele und die im Unternehmen vorhandenen Voraussetzungen überprüft. Wichtigste Aussagen waren für mich in diesem Zusammenhang:

• Keine VDI Lösung ist wie die andere
• VDI ist weder Technologie noch “Die Lösung”
• VDI ist nicht grundsätzlich kostengünstiger als klassische Clients
• Alle Stakeholder im Unternehmen müssen beim Entscheidungsprozess aus Akzeptanz-Gründen eingebunden werden
• Ein Umstieg auf VDI muss vollständig geplant werden
• Nutzung von Experten Know-how

Das Tech Forum schloss mit einem Blick in die Zukunft und dem Thema VDI als Service in der Cloud.

Insgesamt war es eine gelungene Veranstaltung mit sehr heterogenem Publikum. Anhand der geführten Gespräche und Stimmungen glaube ich, dass das Thema Desktop-Virtualisierung bereits dieses Jahr über großes Potential verfügt, allerdings nicht der – von vielen Seiten vermutete - Riesen-Hype wird, da dieser Markt für viele Interessenten einfach noch zu jung und dynamisch ist. Ohne Frage steckt aber in dem VDI-Markt erhebliches Wachstumspotential und ich denke, dass der Kuchen groß genug für alle sein wird.