heig.de

Beim Upgrade von VI3.5 auf vSphere 4 letzte Nacht ist uns aufgefallen, dass die automatische Installaten/Upgrade der VMWare Tools einige Macken hat. Unter anderem löscht der Installer die msvcp71.dll aus dem System32-Verzeichniss. Für Datev Kunden ist dies sehr unvorteilhaft, da 90% der Programme darauf aufsetzten. Eine Reparaturistallation des “Installationspacketes” behebt das Problem. Laut der VMWare Community kann man die msvcp71.dll auch von einem nicht aktualisiertem System einfach wieder ins System32 Verzeichniss kopieren.

[UPDATE1]
Weitere, von dem Problem betroffene Applikationen:

• Microsoft SQL Server
• Symantec pcAnywhere
• Symantec Antivirus
• Adobe Acrobat Reader

Die msvcp71.dll ist auch auf der VMWare Tools CD (Windows.iso, wird gemountet wenn man die Tools installiert) unter folgendem Pfad zu finden:

<cdrom drive>\program files\VMware\VMware Tools\

[/UPDATE1]

[UPDATE2]

Laut http://communities.vmware.com/message/1363520#1363520 gibt es eine Möglichkeit dieses Problem zu umgehen. Ich muss gestehen, diese Möglichkeit ist nicht schön, aber vielleicht nützlich:

chjones behauptet u.a. die msvcp71.dll wurde nicht angefasst wenn man folgendes beachtet:

• die automatische Aktualisierung der Tools aktivieren
• VMs NICHT mit VMotion auf einen vSphere 4 Host migrieren
• VMs herunterfahren und auf einem vSphere 4 Host neu booten

BTW, VMWare hat diesen Bug erkannt. Er soll in vSphere 4 Update 1 behoben werden. U1 erscheint voraussichtlich erst im November 09. Anscheinend sollte man genau wie bei M$ bis zum ersten ServicePack warten

[/UPDATE2]

written by gk \\ tags: failed, msvcp71.dll, VMWare, vSphere 4

Wird bei einer Windows Server 2008 virtuellen Maschine die virtuelle Hardware von Version 4 (VI3) auf Version 7 (vSphere 4) upgegraded werden alle virtuellen Festplatten außer c:\ im Windows Diskmanager (Start->Ausführen->diskmgmt.msc) als ‘offline’ gekennzeichnet und sind nicht verfügbar. Dieser Effekt tritt nur bei virtuellen Maschinen mit mehr als einer virtuellen Festplatte auf.

Das Problem kann behoben werden, indem man die zusätzlichen Festplatten im Diskmanager wieder ‘online’ schaltet und die VM neu startet. Der Bug wurde mir gerade von VMWare bestätigt – es wird an einer Lösung gearbeitet!

Die Ursache ist anscheinend der Austausch des virtuellen Festplattencontrollers. Windows sieht diese Festplatten als “neu” an und bindet sie nicht automatisch wieder ins System ein.

written by gk \\ tags: failed, Microsoft, VMWare, vSphere 4