Seite 1 von 2
vSphere 5.5 Update 1 verfügbar
Verfasst: 12.03.2014, 07:38
von rziwin
Antwort:
Verfasst: 12.03.2014, 08:18
von MarcelMack
Endlich "offiziell" 2012 R2 als vCenter OS!

Verfasst: 12.03.2014, 09:03
von MarcelMertens
Und e1000 Bugfix!
Verfasst: 12.03.2014, 11:19
von UrsDerBär
Nett, gab doch einiges an Bugfixes

Verfasst: 12.03.2014, 12:03
von stahly
Jetzt heisst es Update (von 5.1 / 2008 R2), oder Neuinstallation (von 5.5 / 2012 R2).

Verfasst: 13.03.2014, 09:01
von roeschu
http://partnerweb.vmware.com/comp_guide ... matrix.php
Wenn ich ESX 5.0 auswähle wird VCenter 5.5 U1 als nicht supported angezeigt.
Wenn ich Vcenter 5.5 U1 auswähle werden alle ESX Versionen aussert 5.5 U1 als nicht supported angezeigt.
Das ist ja sicher ein Fehler(?). Ich nehme an Vcenter 5.5 U1 unterstützt die gleichen ESX Versionen wie Vcenter 5.5...
Verfasst: 18.03.2014, 08:09
von PatrickW
Moin,
ich habe gerade noch mal reingeguckt in die HCL (
http://www.vmware.com/resources/compatibility/sim/interop_matrix.php) und da werden alle ESX(i) ab 4.0 als kompatibel angezeigt.
Verfasst: 20.03.2014, 15:40
von roeschu
Ja danke, jetzt ists bei mir auch ok...war wohl noch nicht in der Matrix an diesem Tag..
Verfasst: 20.03.2014, 16:38
von vMario156
Wer braucht schon BugFixes etc., hauptsache VSAN !!!

Verfasst: 20.03.2014, 17:00
von bla!zilla
Das konntest du auch vorher haben. ;D Da musstest du nicht bis zur GA warten. Aber wer eine P7200 zugunsten eines single-node VSAN verschmäht...

)
Verfasst: 20.03.2014, 20:41
von mbreidenbach
Mal ernsthaft...was finden die leute an VSAN toll ?
Weg mit Single Point of Failure wir machen jetzt Multiple Point of Failure ?
Das Ding schreit doch nach Ärger.
Verfasst: 21.03.2014, 02:21
von continuum
mbreidenbach hat geschrieben:Mal ernsthaft...was finden die leute an VSAN toll ?
Weg mit Single Point of Failure wir machen jetzt Multiple Point of Failure ?
Das Ding schreit doch nach Ärger.
Sehe ich genauso - wenn auf einem VSAN volume etwas schief geht dann gibt es keine Werkzeuge da noch irgendetwas auszulesen. Das ist bei VMFS an sich ja schon ein Problem - mit VSAN werden die Schwierigkeiten dann noch multipliziert.
Wie VMware einerseits so was wie VSAN als super neues Feature anpreisen kann und andererseits nicht mal ein checkdisk Tool mit Repairfunktion hinbekommt - und damit anscheinend auch noch durchkommt, ist mir ein Rätsel.
Ganz am Rande ...
Vorsicht bei Neuinstallation von "VMware-ESXi-5.5U1-RollupISO.iso"
Es gibt Berichte das ein damit installiertes System nach Aktivierung von Software-iSCSI nicht den nächsten Neustart überlebt.
Verfasst: 21.03.2014, 10:00
von bla!zilla
mbreidenbach hat geschrieben:Mal ernsthaft...was finden die leute an VSAN toll ?
Weg mit Single Point of Failure wir machen jetzt Multiple Point of Failure ?
Das Ding schreit doch nach Ärger.
Nach der Definition sind VSAN und Produkte wie die von Nutanix, Tintri oder Simplivity Hexenwerk. Lasst uns den ganzen Virtualisierungskram verbrennen und wieder zur guten, alten Vor-Virtualisierungsära zurückkehren.
Ich kann auch immer wieder nur meine Verwunderung zum Ausdruck bringen, wie instabil VMFS ist (oder es sein soll). Ich kann das in etlichen Umgebungen seit 2007 nicht bestätigen. Wenn ein VMFS gestorben ist, dann gab es einen Grund dafür, der war aber immer in Form von defekter HW zu finden.
Wenn ihr mal buggy VMware Stuff sehen wollt, dann schaut euch mal vCAC o.ä. an.
Verfasst: 21.03.2014, 13:18
von continuum
Ich kann auch immer wieder nur meine Verwunderung zum Ausdruck bringen, wie instabil VMFS ist (oder es sein soll).
Ich bin gerade an einem Fall in Hamburg zugange - 3 ESXi in einer kleinen Umgebung mit einer EqualLOGIC. Einer der 3 hatte Verbindungsprobleme über iSCSI.
Die Situation schaukelte sich hoch und heute morgen hatte keiner der 3 Hosts noch eine brauchbare Verbindung.
Die ESXi konnten nicht mal mehr die Partitionstabelle der wichtigsten LUN anzeigen.
Für den Kunden sieht das aus wie ein Totalausfall. DELL verweist an VMware und ist nicht zuständig.
Ich hab dann einen der 3 Hosts mit Linux gebootet und konnte ohne Probleme die Partitionstabelle und den Inhalt der LUN auslesen. Es gab also "eigentlich" gar keine Probleme - aber durch die nicht wirklich ausgereiften Clusterfunktionen des VMFS denken alle 3 Hosts das VMFS Volume sei korrupt und versuchen erst gar nicht es zu mounten.
So was sehe ich regelmässig - jedenfalls so oft dass ich überhaupt nicht mehr überrascht bin wenn ich sowas sehe.
Wahrscheinlich läuft das jetzt darauf hinaus , das wir alles von Linux aus auf ein anderes VMFS-volume umkopieren. 2 TB - das heisst wir brauchen wahrscheinlich fast einen ganzen Tag.
Eine einfache Funktion im ESXi : Reset Heartbeat-section - könnte das Problem beheben - aber so etwas gibt es nicht.
Im VMware Supportteam gibt es anscheinend auch nur ein Handvoll Leute die soetwas manuell beheben können - eine Dokumentation, die einem User helfen würde soetwas selbst zu machen, gibt es nicht einmal ansatzweise.
Verfasst: 21.03.2014, 13:44
von continuum
Nachtrag: wir sind um das Umkopieren herum gekommen.
Ein neu installierter ESXi konnte die Volumes wieder erkennen.
Das bedeutet dass alle 3 Hosts des Clusters das betroffene Volume als "dont mount this corrupt volume" geflagt haben, obwohl es offensichtlich nicht wirklich beschädigt ist.
So ein Verhalten kann man doch wohl nicht als wirklich ausgereift bezeichnen - oder ???
Verfasst: 21.03.2014, 13:46
von stahly
Wenn dem wirklich so ist, was kann man den machen, um das VMFS möglichst "stabil zu halten"? (Außer zu MS zu wechseln

)
Verfasst: 21.03.2014, 14:21
von roeschu
continuum hat geschrieben:
So ein Verhalten kann man doch wohl nicht als wirklich ausgereift bezeichnen - oder ???
Ist das nach einem Update auf 5.5 Upd1 passiert?
p.s Ich bin froh das ich mich nicht mehr mit VMFS rumschlagen muss. NFS bei VMware oder SMB bei Hyper-V vereinfachen vieles.
Verfasst: 21.03.2014, 14:43
von irix
@Ulli,
erfrage mal bitte den Firmwarestand der EQL bei deinem Kunden.
Gruss
Joerg
Verfasst: 21.03.2014, 14:53
von blue_focus
Also ich vermute ja eher ein "Protokollproblem". Wir haben zum Glück hier kein iSCSI oder FCoE im Einsatz.
Ich mache das hier nun auch schon ein paar Jahre und hatte so ein VMFS Problem noch nie. Unser SAN ist ausschließlich über FC angebunden.
Verfasst: 21.03.2014, 15:25
von bla!zilla
continuum hat geschrieben:Das bedeutet dass alle 3 Hosts des Clusters das betroffene Volume als "dont mount this corrupt volume" geflagt haben, obwohl es offensichtlich nicht wirklich beschädigt ist.
So ein Verhalten kann man doch wohl nicht als wirklich ausgereift bezeichnen - oder ???
Na ja, wenn der eigene Job daraus besteht sowas zu reparieren, dann sieht man das verdammt oft. Ein Kammerjäger könnte auch den Eindruck bekommen, dass es überall in Häusern nur von Ungeziefer wimmelt...
Zu VMFS vs. NFS. Ja, NFS ist super. Wäre nur schön, wenn Microsoft z.B. Exchange darauf supporten würde. Es ist immer wieder ein Fest den Gesichtsausdruck von Kunden zu sehen, wenn ich ihnen mitteile, dass Microsoft ihren Exchange (auf VMware auf $NFS-STORAGE) im Fehlerfall nicht supporten würde.
Verfasst: 21.03.2014, 15:26
von bla!zilla
stahly hat geschrieben:Wenn dem wirklich so ist, was kann man den machen, um das VMFS möglichst "stabil zu halten"? (Außer zu MS zu wechseln

)
LOL. Viel Spaß mit NTFS und CSV.

Verfasst: 21.03.2014, 16:59
von continuum
stahly hat geschrieben:Wenn dem wirklich so ist, was kann man den machen, um das VMFS möglichst "stabil zu halten"? (Außer zu MS zu wechseln

)
Guck dir mal das vmkernel.log an was in diesem VMTN post angehängt ist:
https://communities.vmware.com/thread/473936
Bei dem ist sowas ähnliches passiert. Am 20ten kam es zu einem wirklichen Problem.
Aber schon eine Woche vorher waren erste Anzeichen, dass mit der iSCSI-Anbindung was nicht in Ordnung ist, zu erkennen.
Solche Meldungen wie in dem log in Zeile 72-74 vorkommen sollten ernst genommen werden.
Der Mann hätte den Ernstfall wahrscheinlich vermeiden können wenn er die logs überwacht hätte.
@Irix
EqualLogic Version: R378146 v7.0.1
Verfasst: 21.03.2014, 22:18
von roeschu
bla!zilla hat geschrieben:
Zu VMFS vs. NFS. Ja, NFS ist super. Wäre nur schön, wenn Microsoft z.B. Exchange darauf supporten würde. Es ist immer wieder ein Fest den Gesichtsausdruck von Kunden zu sehen, wenn ich ihnen mitteile, dass Microsoft ihren Exchange (auf VMware auf $NFS-STORAGE) im Fehlerfall nicht supporten würde.
Ich wusste das bis vor ein paar Monaten auch nicht und bin nur per Zufall darauf gestossen.
Habe seit 4 Jahren 4 Exchange Installationen und keine Probleme bis jetzt. Ok alles kleine Installationen; keine DAG Konstellation oder so. Bin sicher es gibt viele tausende die das so laufen haben ohne Probleme.
Verfasst: 21.03.2014, 22:56
von vMario156
bla!zilla hat geschrieben:Das konntest du auch vorher haben. ;D Da musstest du nicht bis zur GA warten. Aber wer eine P7200 zugunsten eines single-node VSAN verschmäht...

)
Ja hatte ich auch seit der closed Beta Mitte 2013, allerdings bis dato immer nur in nested Umgebungen am laufen gehabt. Jetzt zum GA Release hab ich mal einen Schwung HDDs und SSDs für unsere Lab Hosts bestellen lassen.
Konnte aber erst mal nur einen Host installieren, da mir noch SD Karten fehlen für die ESXi Installation daher der Tweet auf den du anspielst

Hat ja ne ganz schöne Welle ausgelöst, aber die 3PAR hat nun mal alt ausgesehen auch wenn es natürlich kein fairer Vergleich war

Verfasst: 23.03.2014, 14:40
von Supi
zum Thema 5.5 U1 Rollup ISO:
https://communities.vmware.com/message/2360248#2360248
I could reproduce the issue by installing a nested ESXi host with the 5.5 U1 Driver Rollup ISO.
Creating a Software iSCSI adapter will crash the hostd daemon and make the host unmanageable.
I was able to track down the issue to the scsi-teradimm VIB that is included in this ISO.
Once you have removed it by running
esxcli vib remove -n scsi-teradimm
in an ESXi shell and reboot the host, the issue will no longer appear.