27.11.2009 von gg.

Nach dem Update eines unserer Server auf Centos 5.4 stellten wir fest, dass wir uns nicht mehr mit unserem darauf laufenden Vmware Server 2.0.2 verbinden konnten.

• Das hing damit zusammen, dass der Vmware Server nicht dazu in der Lage war, mit der neuen glibc zusammenzuarbeiten, die mit Centos 5.4 kam. Ein Workaround (ursprünglich in den Vmware Communities vorgestellt) bestand darin, erst das System auf Centos 5.4 zu aktualisieren und dann ­- bis zur Lösung des Problems - die glibc wieder auf die Centos-5.3-Variante downzugraden. Dazu ergab es Sinn, zunächst die Datei “/etc/yum/repos.d/CentOS-Base.repo” nach “/etc/yum/repos.d/Centos53-Base.repo” zu kopieren. Danach ersetzten wir innerhalb dieser kopierten Datei den String “$releasever” einfach überall durch den Wert “5.3″ und fügten zu allen in “[]” stehenden Repositories noch “53″ hinzu (Beispiel “[base53]”). Anschließend kann es an den eigentlichen Downgrade-Prozess gehen, und zwar mit dem Befehl:
  yum downgrade glibc\* libstdc++\* gcc gcc-c++ cpp nscd nss_ldap
  Jetzt war ein Neustart fällig. Damit yum die Libraries bei der nächsten Systemaktualisierung nicht wieder überschrieb, nahmen wir sie nun explizit aus. Das ging über die Zeile
  exclude=glibc* libstdc++* gcc gcc-c++ cpp nscd nss_ldap
  in der Datei “/etc/yum.conf”. Nachdem das erledigt war, führten wir erneut das Script “vmware-config.pl” aus, um den Vmware Server an die anderen Libraries anzupassen. Danach starteten wir den Rechner nochmals neu. Jetzt war der Vmware Server wieder ansprechbar. Die Änderungen lassen sich einfach durch das Löschen der Datei “/etc/yum/repos.d/CentOS53-Base.repo” und das Löschen der exclude-Zeile aus der yum.conf rückgängig machen.

Geschrieben in Technik | Drucken | Keine Kommentare »

17.11.2009 von gg.

Als wir versuchten, mit dem Vsphere Client von der 64-Bit-Version von Windows 7 aus auf einen ESXi-Server 4.0 zuzugreifen, stellten wir fest, dass die neue Client Software von Vmware unter Windows 7 nicht läuft.

• Es gibt in den Vmware Communities einen Workaround für dieses Problem. Dazu muss der zuständige IT-Mitarbeiter zunächst von einem Windows Vista System oder einer vergleichbaren Nicht-Windows-7-Plattform die Datei “system.dll” aus dem Ordner “%SystemRoot%\Microsoft.NET\Framework64\{Aktuelle Version des Dot.Net-Frameworks}” besorgen und auf das Windows-7-System kopieren, und zwar in das Vsphere-Client-Programmverzeichnis unter {Laufwerk}:\Program Files (x86)\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\Lib”. Danach geht es daran, die Datei “VpxClient.exe.config” zu editieren. Hier sollte unterhalb der Zeile “</appSettings>” folgendes eingefügt werden:
  <runtime>
  <developmentMode developerInstallation=”true”/>
  </runtime>
  Nun reicht es, eine CMD-Datei anzulegen, die den Vsphere Client mit der neuen DLL aufruft. Bei diesem Beispiel wurde der Vsphere Client auf Laufwerk C:\ installiert:
  SET DEVPATH=C:\Program Files (x86)\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\Lib
  “C:\Program Files (x86)\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\VpxClient.exe”
  Jetzt läuft der Vsphere Client auch unter Windows 7. Er kann aber nur auf ESX-Umgebungen zugreifen, die Zusammenarbeit mit dem Vmware Server 2 funktioniert noch nicht.

Geschrieben in Technik | Drucken | 1 Kommentar »

12.11.2009 von gg.

Beim Versuch, Fedora 11 mit Hilfe des Befehls “yum update” auf den aktuellen Stand zu bringen, hängte sich yum auf und meldete einen Abhängigkeitenfehler zwischen “iptstate-2.2.1-5.fc11.i586″ und “libnetfilter_conntrack.so.1″.

• Das Libnetfilter-Conntrack-Packet scheint zur Zeit nicht zu funktionieren. Auf unserem System konnten wir das Problem dadurch umgehen, dass wir zuerst das Paket “iptstate” deinstallierten (mit “yum remove iptstate”), dann das Libnetfilter-Pakete aktualisierten (”yum install libnetfilter_conntrack”) und anschließend das System mit “yum update” auf den aktuellen Stand brachten. Während des Update-Vorgangs wurde iptstate automatisch wieder mit eingespielt.

Geschrieben in Technik | Drucken | Keine Kommentare »

3.11.2009 von gg.

Versucht man, Windows XP als Guest unter dem Vmware ESX-Server 3.5 Update 4 oder einer vergleichbaren Version einzuspielen, so bricht das Setup ab, da es keine virtuelle Zielfestplatte finden kann.

• Der Grund dafür liegt darin, dass die vom ESX-Server angebotenen virtuellen SCSI-Controller von der Windows-Setup-Routine nicht unterstützt werden. Vmware bietet aber ein Floppy-Image mit einem passenden SCSI-Treiber an. Dieser findet sich auf dem ESX-Host unter /vmimages/floppies/vmscsi-1.2.0.2.flp. Wird dieses Floppy-Image vor dem Start in die virtuelle Maschine eingebunden, haben die Anwender während des Setups die Möglichkeit, mit Hilfe eines Drucks auf die Taste „F6“ SCSI-Treiber von diesem externen Datenträger in das Setup zu integrieren. Wenn die Windows-Installationsroutine den Treiber auf der virtuellen Floppy gefunden hat, kann das Setup ganz normal fortfahren.

Geschrieben in Technik | Drucken | Keine Kommentare »