VMBlox.com » Bug http://www.vmblox.com Virtualisierung und mehr Wed, 14 Dec 2011 10:17:11 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 Bug in vSphere beim Virtual Hardware Upgrade http://www.vmblox.com/96/bug-in-vsphere-beim-virtual-hardware-upgrade/?utm_source=rss&utm_medium=rss&utm_campaign=bug-in-vsphere-beim-virtual-hardware-upgrade http://www.vmblox.com/96/bug-in-vsphere-beim-virtual-hardware-upgrade/#comments Tue, 16 Jun 2009 19:26:48 +0000 markus http://www.vmblox.com/?p=96 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:

ErrorVMotion

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.

CPU Identification Mask

Nach dem Hochfahren kann man die Maschine wieder ganz normal per VMotion live migrieren.

]]> http://www.vmblox.com/96/bug-in-vsphere-beim-virtual-hardware-upgrade/feed/ 0 ESX 3.5U2 VM’s starten nicht mehr http://www.vmblox.com/85/esx-35u2-vms-starten-nicht-mehr/?utm_source=rss&utm_medium=rss&utm_campaign=esx-35u2-vms-starten-nicht-mehr http://www.vmblox.com/85/esx-35u2-vms-starten-nicht-mehr/#comments Tue, 12 Aug 2008 07:54:49 +0000 markus http://www.vmblox.com/?p=85 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.

  1. NTP Dämon stoppen
  2. Das datum auf 10.08.2008 zurückdrehen, das geht entweder im VI Client >> Configuration >> Time & Date, oder über die Commandline mit date -s “08/10/2008″
  3. Danach starten alle VM’ s wieder normal.

VMWare arbeitet mit Hochdruck an einem Patch

]]> http://www.vmblox.com/85/esx-35u2-vms-starten-nicht-mehr/feed/ 0 Rescan SAN läuft in einen PSOD bei Dell 29xx http://www.vmblox.com/46/rescan-san-lauft-in-einen-psod-bei-dell-29xx/?utm_source=rss&utm_medium=rss&utm_campaign=rescan-san-lauft-in-einen-psod-bei-dell-29xx http://www.vmblox.com/46/rescan-san-lauft-in-einen-psod-bei-dell-29xx/#comments Mon, 28 Apr 2008 10:44:43 +0000 markus http://www.vmblox.com/?p=46 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.

]]> http://www.vmblox.com/46/rescan-san-lauft-in-einen-psod-bei-dell-29xx/feed/ 1 Fehler in der Pegasus install queue bremst ESX 3.5Update 1 start http://www.vmblox.com/45/fehler-in-der-pegasus-install-queue-bremst-esx-35update-1-start/?utm_source=rss&utm_medium=rss&utm_campaign=fehler-in-der-pegasus-install-queue-bremst-esx-35update-1-start http://www.vmblox.com/45/fehler-in-der-pegasus-install-queue-bremst-esx-35update-1-start/#comments Thu, 24 Apr 2008 18:57:11 +0000 markus http://www.vmblox.com/?p=45 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.mof
sondern:

/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 start

Once the scripts completes the install_queues will be empty and the service will start much more quickly.

]]> http://www.vmblox.com/45/fehler-in-der-pegasus-install-queue-bremst-esx-35update-1-start/feed/ 0