VMWare ESXi 4.1 & HP P2000 MSA

[spyro032]

Hi

Vorweg: Ich weiß nicht ob das hier richtig platziert ist, aber ich brauch ein wenig Input um heraus zu finden woran das gelegen haben könnte!

Letzte Woche hab ich bei nem Neukunden die bestehenden Server virtualisiert. 2x physikalische, 2x virtuelle die mit VMWare Server auf der einen Kiste liefen.

Als Hardware stand ein ML350G6 und irgendein Terra Server zur Verfügung, alles per Converter bzw Coldclone rübergezogen aufs SAN, lief auch alles bestens! Problem war nur das der zweite Controller im SAN ne DOA war, also von Anfang an defekt, am selben Tag des Aufbaus vor Ort noch reklamiert, heute, bzw. gestern, kam von HP ein neuer. Ebenso wie ein zweiter ML350 kam, weil die Terra Kiste doch langsam von der Hardware muckte.

Alles hingekarrt, Server zusammen gesteckt, ESXi installiert. Die VMs in den neuen Server integriert, getestet, alles tipp topp! Die auf VMs auf den bestehenden Hosts runtergefahren, die Hosts selber runtergefahren, SAN runtergefahren - Controller ausgetauscht & redundant verkabelt. SAN wieder hochgefahren, alles bestens, zweiter Controller zog sich die Konfig vom ersten, alles super, Fehler weg!

Die ESXi Server beide hochgefahren, alles super, die 2 Hauptserver hochgefahren: Bluescreen - c00002e2 - Angeblich geänderte Hardware (als Systeme laufen da 2 Server 2008 R2, ein Debian Server und eine XP Maschine die Konvertierungsjobs übernimmt) - Den Linux Server hochgefahren -> Der kann angeblich keine HDDs mounten. Den XP Rechner hochgefahren -> Lief!

Nach kurzer suche festgestellt das bis auf die XP VM alles andere als Typ SCSI Platten im ESXi hat, nur der XP läuft auf IDE. Die Platten der anderen Server von SCSI auf IDE geändert, brachte auch nichts! Testweise dem einen Server eine neue Platte gegeben, diesmal Typ IDE, mit Acronis die Systempartition (die ja mitlerweile wieder Typ SCSI war) auf die IDE Platte geklont, SCSI Platten entfernt, mit Server 2008 R2 DVD gebootet, neuen MBR und Bootsektor geschrieben - Selbe Problem! Weiter Google befragt, alles was ich gefunden hab brachte keinen Erfolg...

In der Zwischenzeit hab ich den Hauptserver dann schon wieder physikalisch zum laufen gebracht (ich hatte zum Glück das alte Raid nicht angerührt, sondern für den ESXi nur ne neue Platte reingestopft) und dank DaSi auf aktuellen Datenstand gebracht. Letzte Idee war die ganzen Kisten nochmal neu zu virtualisieren, der erste ist jetzt durch, und siehe da: Funktioniert!

Ich hab solche Probleme noch NIE gehabt, und kann mir nicht wirklich erklären wodurch das Zustande gekommen ist, irgendwer vielleicht eine Idee?

[pantsoff]

Warum hast du keine neuen VMs anhand vorhandener vmdk-Dateien erstellt?

Dann wird die vmx neu geschrieben-sollte dann zur "neuen Hardware" passen.

Hab ich etwas missverstanden?

Sorry, der Post liest sich etwas anstrengend:).

[DocInfra]

VMware ESX kennt keine IDE Platten. Also irgendwas ist beim Konvertieren, Kopieren oder irgendwo anders schief gelaufen.

[pantsoff]

Hallo,

die vmx-Datei passt nicht mehr, wenn Sich das Storage drunter ändert. Deshalb mein Anreiz, eine neue VM anhand der vorhandenen vmdk Datei zu erstellen, der ESXi erzeugt dabei automatisch die passende .vmx Datei.

[DocInfra]

Warum sollte sich das VMX ändern, wen sich dahinter das Storagesystem ändert?! Wenn die VM vorher einen LSI Adapter hatte, dann hat die VM den auch auf einem neuen Storage/ Datastore. Die Pfadnamen zu den VMDK Dateien stehen mit der relativen Pfadangabe in der VM. Wenn die VM IDE Platten hatte, dann wurde sie falsch importiert. Noch ein Hinweis zum Erstellen neuer VMs anhand der VMDKs: Oft eine dumme Idee. Existieren Snapshosts, ist die VM hinüber bzw. kommt mit einem alten Stand hoch. Danach hat man dann richtig Spaß die Snapshotkette wieder per Hand zurecht zu bauen.