Wenn man bei der neuen vSphere die virtuellen Maschinen auf Hardware Version 7 Upgradet, ist es bei dieser VM ein VMotion nicht mehr ohne weiteres möglich. Beim versuch erscheint nämlich folgende Fehlermeldung:
Im Moment ist der einzige Workaround den ich gefunden habe die VM wieder herunterzufahren und in den Advanced Options auf CPU Identification MASK einen Reset all to default zu machen.
Nach dem Hochfahren kann man die Maschine wieder ganz normal per VMotion live migrieren.
Heute ist eine Zeitbombe geplatz die VMWare sich anscheinend versehentlich selbst in seinen ESX eingebaut hat.
Wenn man eine VM auf ESX 3.5U2 starten will kommt folgende fehlermeldung:
„A general system error occurred: Internal Error“
Wie es aussieht ist dies ein Lizenzproblem das VMWare selbst gebastelt hat.
Als workaround um zur Zeit überhaupt VM‘ s starten zu können müsst ihr vorgehen wie folgt.
VMWare arbeitet mit Hochdruck an einem Patch
Habe heute Morgen mit schrecken Feststellen müssen das ESX 3.5 sich nicht mit unseren nagelneuen Dell PE 2900 verträgt. Installation verläuft bis auf den Bug in der Pegasus install_queue eigentlich reibungslos.
Heute Morgen noch schnell das Zoning gemacht und dann ein Rescan SAN, aber anstatt mir meine VMFS Luns anzuzeigen nur ein hässlicher PSOD, dann das Selbe nochmal mit dem 2. Server versucht, das Selbe.
Im VMTN-Forum habe ich dann jemanden gefunden der dasselbe Problem hat.
Ich hab jetzt mal einen SR bei VMware und Dell aufgemacht und hoffe bald eine Lösung berichten zu können.
Update 1: Habe einen Workaround gefunden der mir in sofern weiterhilft das ich nun zumindest mal wieder arbeiten kann.
Man muss den INTERNEN USB Controller deaktivieren.
Dann funktioniert es dahingehend wieder das der Server beim reboot die neuen LUN‘ s erkennt und man sie nutzen kann.
Allerdings führt ein manueller Rescan weiterhin zum PSOD.
Update 2: So nun erstmal eine praktikable Lösung auf die mich der Dell Support gestoßen hat.
Nachdem man den internen USB Controller im BIOS deaktiviert hat, muss man noch in der /etc/modules.conf alle USB einträge auskommentieren.
Danach noch ein Reboot und auch einem manuellen Rescan steht nichts mehr im Wege.
Heute habe ich 4 Fabrikneue Server mit ESX 3.5 Update 1 installiert, dabei fiel mit auf das beim start der Pegasus queue ein rotes failed erschien.
Ich habe mich dann im VMTN Forum umgesehen und habe die Lösung für mein Problem gefunden.
Allerdings leicht abgewandelt.
Hier erstmal der Link zum VMTN Thread
Bei mir war es allerdings nicht wie im Forum beschrieben:
/var/pegasus/vmware/install_queue/3_files/mofs/root/cimv2/roleauth-schema.mofsondern:
/var/pegasus/vmware/install_queue/1_files/mofs/root/cimv2/roleauth-schema.mof ansonsten war aber alles soweit korregt.
Daher hier nochmal als fullquote:
Edit the roleauth-schema compiler directive to include the VMware_Identity class definition using
nano /var/pegasus/vmware/install_queue/3_files/mofs/root/PG_Interop/roleauth-schema.mof
Add the bolded line above the pre-existing member directive.
#pragma include („VMware_Identity.mof“)
#pragma include („VMware_IdentityMemberOfCollection.mof“)It also needs to be added in the standard cimv2 path.
nano /var/pegasus/vmware/install_queue/3_files/mofs/root/cimv2/roleauth-schema.mof
#pragma include („VMware_Identity.mof“)
#pragma include („VMware_IdentityMemberOfCollection.mof“)Copy the missing file from the stardard cimv2 path to the shared path.
cp /var/pegasus/vmware/install_queue/3_files/mofs/root/cimv2/VMware_Identity.mof /var/pegasus/vmware/install_queue/3_files/mofs/root/PG_Interop/
Stop and start the service with these commands.
/etc/init.d/pegasus stop
/etc/init.d/pegasus startOnce the scripts completes the install_queues will be empty and the service will start much more quickly.