Wie bereitet man sich auf so eine Prüfung vor?

Schaut man sich bei VMware den Anforderungskatalog Blue Print an, bekommt man einen ersten Vorgeschmack auf das Geforderte. Hier sind alle den Prüfungen zu Grunde liegende Themenbereiche und Dokumente aufgeführt. Die Menge lässt den Umfang der Vorbereitungen nur vage erkennen…

Da diese Dokumente sehr umfangreich und ausführlich sind, und kaum in einer Woche Vorbereitungszeit für mich durchzuarbeiten waren (jeder VCP kann ein Lied davon singen: VMware-Umgebungen aufbauen/betreuen und die VCP-Prüfung ablegen sind zwei unterschiedliche Paar Stiefel), habe ich mich im Netz nach einer Abkürzung umgeschaut und bin auf die Seite www.vreference.com gestoßen, wo das Wesentliche der Dokumente auf 27 Seiten PDF eingedampft zur Verfügung gestellt wird. Ein sehr gutes Dokument, nicht nur zur Vorbereitung auf die Zertifizierung geeignet. Schaut man sich dann noch die wichtigsten Werte des “Configuration Maximums” Dokuments an, hat man eine gute Grundlage geschaffen und gute Chancen die Prüfung erfolgreich abzulegen.

Manche Fragen lassen sich einfach beantworten, wie beispielsweise die Frage aus welchen einzelnen Dateien sich eine virtuelle Maschine auf einem ESX-Server zusammensetzt. Andere Fragen gehen teilweise sehr in die Details, oder wissen Sie was die Unterschiede zwischen Ingress- und Egress-Traffic Shaping sind und wo diese zu konfigurieren sind? Oder ab welcher Version der vCenter Converter Images im Norton Ghost-Format unterstützt. Einige Fragen lassen sich auch aus der täglichen Praxis oder nach dem Ausschluss-Prinzip beantworten.

Und schließlich verlangt VMware ja nicht, dass man alle Fragen richtig beantwortet, es genügt ein Score von 300 von 500 Punkten um das Zertifikat zu erhalten (das Ergebnis gibt’s natürlich gleich nach Testende).

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!

Langfristig landet man beim Bauen der passenden Skripte für die eigene Umgebung dann entweder in seitenlangen Perl Data::Dumper Ausgaben, um passende Attribute und Methoden zu finden, oder aber im Managed Object Browser (MOB), der die via Perl SDK verfügbare Objekt-Struktur einer ESX/vSphere/vCenter-Installation per Web-Interface visualisiert und klickbar macht. Damit kann man sich direkt durch bestehende Datenstrukturen hangeln und muss diese nicht erst über ein Skript zusammensuchen. Sehr, sehr praktisch.

VM-Objekte im MOB

Sobald die Skript-Anforderung jedoch VM-zentriert wird (z.B. Iterieren über existierende VMs und prüfen, welche davon ein ISO gemountet haben) und man dafür die VM-Objekte im MOB sucht, wird man merken, dass diese gut versteckt sind. Folgendes Perl Skript schafft hier Abhilfe. Es zeigt ohne langwieriges Suchen direkt die zugehörigen MOB URLs für VMs an – per Default für alle VMs, bei expliziter Angabe eines VM-Namen nur für diese eine VM.

#!/usr/bin/perl
#
# get_mob_url.pl: return the Managed Object Browser URL for a given VM

use Data::Dumper;
use strict;
use warnings;
use URI;
use VMware::VIRuntime;

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

# Get the base URL of the remote server
my $service_url = URI->new(Vim::get_service_url());
my $base_url    = $service_url->scheme . "://" . $service_url->host_port ."/";

# 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
);

# Find the vm-id which can be used to access the MOB browser for the VM
# https://<servername>/mob/?moid=
foreach my $vm_view (@{$vms}) {
  my $vm_name = $vm_view->{summary}->{config}->{name};
  my $vm_id   = $vm_view->{'mo_ref'}->value;
  my $vm_url  = $base_url . "mob/?moid=" . $vm_id;

  printf "%-30s: %s\n", $vm_name, $vm_url;
}

END {
Util::disconnect();
}

Beispiel

Folgendes Beispiel demonstriert die Ausgabe von obigem Skript, wenn es darum geht, die Managed Object ID und damit die MOB URL einer VM zu bestimmen. Der verwendete Namen (amber11.roc.consol.de) hat übrigens erstmal rein gar nichts mit dem DNS-Namen der VM zu tun, sondern ist der Anzeigename der VM im vSphere Client. In unserem Fall ist lediglich beides identisch. Falls VMs in der eigenen Umgebung also ‘DEV jboss-15′, ‘Apache Intranet Test’ oder ähnlich heißen sollten, sind diese Namen zu verwenden.

[vi-admin@vma ~][vcenter.roc.consol.de]$ ./get_mob_url.pl amber11.roc.consol.de
amber11.roc.consol.de         : https://vcenter.roc.consol.de:443/mob/?moid=vm-1770

Mit der zurückgelieferten URL kann man sich dann im MOB die Attribute der VM betrachten, um herauszufinden/sicherzustellen, welche davon man für sein Projekt konkret benötigt. Sehr hilfreich.

Vorweg müssen wir ein ISO Image der aktuellen VMware ESXi Version von der VMware Webseite heraus laden. Den Inhalt des ISO Images auf bekannte Art und Weise in unsere tftpboot Umgebung kopieren.

Zur Konfiguration von SYSLINUX

Analog zu den bestehenden Konfigurationsdateien, hier eine exemplarische Datei für ein System mit der Hardware MAC Adresse 00:11:22:33:44:55. Unsere ESXi Installation wurde unter /tftpboot/esx4iu1 abgelegt.

# cat /tftpboot/pxelinux.cfg/01-00-11-22-33-44-55
DEFAULT menu.c32
PROMPT 0
MENU WIDTH 80
MENU MARGIN 10
MENU PASSWORDMARGIN 3
MENU ROWS 12
MENU TABMSGROW 18
MENU CMDLINEROW 18
MENU ENDROW 24
MENU PASSWORDROW 11
MENU TIMEOUTROW 20
MENU TITLE VMware ESX
MENU AUTOBOOT Kickstart VMware ESXi 4.0 Update 1 in 5 seconds
LABEL esx4
MENU LABEL esx
MENU DEFAULT
TIMEOUT 50
KERNEL esx4iu1/mboot.c32
APPEND esx4iu1/vmkboot.gz --- esx4iu1/vmkernel.gz --- esx4iu1/sys.vgz --- esx4iu1/cim.vgz --- esx4iu1/ienviron.tgz --- esx4iu1/image.tgz --- esx4iu1/install.tgz

Wird das System nur über PXE gebootet, startet die ESXi Installation an.

Viel Spaß beim Testen!

Da Anleitungen zur vollautomatisierten Installation von ESX Servern im Internet etwas rar sind, wollen wir mit dem folgenden Artikel demonstrieren, wie so etwas via PXELINUX und Kickstart funktionieren kann. Das Starten (Kicken) des ESX 4.0 Systems wird mittels BOOTP erfolgen, die Installation der eigentlichen Software erfolgt dann über HTTP. Es ist daher notwendig, diese Dienste im Installationsnetz zur Verfügung zu haben. Alternativ zu HTTP, ist die Softwareinstallation auch über NFS oder FTP möglich, dies wird hier jedoch nicht näher beschrieben. Eine Installation von ESX 3.5 Servern über dieses Setup sollte ebenso möglich sein.

1. Wir benötigen ein (ubuntu) Linux-System mit den nachfolgenden Software-Komponenten:

Die fiktive IP-Adresse des Linux Kickstart Systems ist 10.0.0.1

# apt-get install dhcp3-server
# apt-get install atftpd
# apt-get install syslinux
# apt-get install apache2-mpm-prefork

2. VMware ESX 4.0 iso Image ausgepackt im Filesystem

# mount -o loop esx-DVD-4.0.0-171294.iso /mnt/disk
# mkdir -p /tftpboot/esx4 ; cp -pr /mnt/disk /tftpboot/esx
# umount /mnt/disk

3. PXE-fähiges System, das wir über BOOTP kicken.

Die fiktive MAC-Adresse des zukünftigen ESX Systems ist 00:11:22:33:44:55, die IP-Adresse 10.0.0.2

# cat /etc/dhcp3/dhcpd.conf
group {
use-host-decl-names on;

next-server 10.0.0.1;
filename “pxelinux.0″;

host esx { hardware ethernet 00:11:22:33:44:55; }
}
# cat /etc/xinetd.d/tftp
service tftp
{
disable = no
socket_type = dgram
protocol     = udp
wait     = yes
user     = root
server   = /usr/sbin/in.tftpd
server_args = /tftpboot
per_source   = 11
cps = 100 2
flags    = IPv4
}

4. Konfiguration des Apache Webservers

Folgenden Eintrag in /etc/apache2/sites-enabled/000-default schreiben

<VirtualHost 10.0.0.1>
ServerName 10.0.0.1
DocumentRoot /tftpboot

<Directory /tftpboot/>
Options +Indexes
AllowOverride AuthConfig
order allow,deny
allow from all
</Directory>
CustomLog /var/log/apache2/tftpboot_access.log combined
ErrorLog /var/log/apache2/tftpboot_error.log

</VirtualHost>

5. Konfiguration von SYSLINUX bzw. pxelinux

# mkdir -p /tftpboot/pxelinux.cfg
# cp /usr/lib/syslinux/menu.c32 /tftpboot
# cp /usr/lib/syslinux/pxelinux.0 /tftpboot
# cat /tftpboot/pxelinux.cfg/01-00-11-22-33-44-55
DEFAULT menu.c32
PROMPT 0
MENU WIDTH 80
MENU MARGIN 10
MENU PASSWORDMARGIN 3
MENU ROWS 12
MENU TABMSGROW 18
MENU CMDLINEROW 18
MENU ENDROW 24
MENU PASSWORDROW 11
MENU TIMEOUTROW 20
MENU TITLE VMware ESX
MENU AUTOBOOT Kickstart VMware ESX 4.0 in 5 seconds
LABEL esx4
MENU LABEL esx
MENU DEFAULT
TIMEOUT 50
KERNEL esx/isolinux/vmlinuz
APPEND initrd=esx/isolinux/initrd.img mem=512M ks=http://10.0.0.1/esx/ks/esx-ks.cfg

6. Last but not least benötigen wir ein Kickstart-File für den neuen ESX Server.

Anbei eine Beispiel-kickstart-Datei, natürlich muss sie in jedem Einzelfall angepasst werden. Eine Beschreibung der möglichen Parameter und ihre Bedeutung findet sich unter http://www.vmware.com/files/de/pdf/vsp_40_esx_vc_installation_guide_de.pdf ab Seite 50 ff.

#  cat /tftpboot/esx/ks/esx-ks.cfg
accepteula
keyboard us
auth –enablemd5 –enableshadow
clearpart –overwritevmfs –drives=mpx.vmhba0:C0:T0:L0
install url http://10.0.0.1/esx
rootpw –iscrypted <root password hash>
timezone –utc ‘Europe/Berlin’
network –addvmportgroup=true –device=vmnic0 –bootproto=static –ip=10.0.0.1 –netmask=255.255.255.0 –gateway=10.0.0.1 –nameserver=10.0.0.1 –hostname=esx
part ‘/boot’  –fstype=ext3 –size=1100  –ondisk=mpx.vmhba0:C0:T0:L0
part ‘none’  –fstype=vmkcore –size=110  –ondisk=mpx.vmhba0:C0:T0:L0
part ‘esx-local’  –fstype=vmfs3 –size=26029 –grow  –ondisk=mpx.vmhba0:C0:T0:L0
virtualdisk ‘esxconsole’ –size=25029 –onvmfs=’esx1-local1′
part ‘/’  –fstype=ext3 –size=15000 –maxsize=15000 –onvirtualdisk=’esxconsole’
part ‘swap’  –fstype=swap –size=1024 –maxsize=1024 –onvirtualdisk=’esxconsole’
part ‘/var’  –fstype=ext3 –size=8000 –maxsize=8000 –onvirtualdisk=’esxconsole’
part ‘/tmp’  –fstype=ext3 –size=1000 –maxsize=1000 –onvirtualdisk=’esxconsole’
reboot

Ich wünsche allgemein gutes Gelingen und viel Spaß!