ESX / ESXi - Hilfethread
- Ersteller XTaZY
- Erstellt am
paulianer
HWLuxx SC2-Cup2 Silber#1
Hmm, mir gehts vor allem darum, die Verfügbarkeit meiner Daten etwas zu erhöhen. Das ganze ist nur im privaten Umfeld und ich will mir nicht weitere Stolpersteine basteln - aber gleichzeitig reizt mich der Umgang mit ZFS.
Ein guter HBA wäre z.B. ein IBM M1015, geflasht auf LSI-9211-8i?
Hach ja, der Basteltrieb :P
Ein guter HBA wäre z.B. ein IBM M1015, geflasht auf LSI-9211-8i?
Hach ja, der Basteltrieb :P
ja der würde wohl gehen...
Du nutzt doch den ML310e oder? Da ist auch genügend Bumms da... Und Passthrough geht meine ich auch.
PS: was natürlich auch funktioniert, du könntest den IBM Controller nehmen und dir native irgend ein Windows/Linux/Unix auf die Kiste drauf packen...
Je nach OS und Software kannst du dann darauf ebenso virtualisieren. Und lässt halt den Controller im Raidmodus laufen.
Würde zwar mit ESXi auch gehen, aber der Controller hat keine BBU und lässt sich nicht in den Write Back Mode zwingen -> was in grottigen teils einstelligen MB/sec Datenraten enden wird.
Du nutzt doch den ML310e oder? Da ist auch genügend Bumms da... Und Passthrough geht meine ich auch.
PS: was natürlich auch funktioniert, du könntest den IBM Controller nehmen und dir native irgend ein Windows/Linux/Unix auf die Kiste drauf packen...
Je nach OS und Software kannst du dann darauf ebenso virtualisieren. Und lässt halt den Controller im Raidmodus laufen.
Würde zwar mit ESXi auch gehen, aber der Controller hat keine BBU und lässt sich nicht in den Write Back Mode zwingen -> was in grottigen teils einstelligen MB/sec Datenraten enden wird.
@gea
die USV nicht vergessen
Kann nie schaden.
Wegen der Datensicherheit ist es aber nicht nötig, wenn ZFS mit sync-write benutzt wird. (ESXi macht das per default über NFS). Man sollte dann halt idealerweise ein Log-Device (SSD) mit Puffer-Kondensator haben, damit das nicht so sehr auf die Performance geht.
Zuletzt bearbeitet:
paulianer
HWLuxx SC2-Cup2 Silber#1
@fdsonne: ja, ich dachte mal wieder darüber nach den ML310e anzuschaffen. Meine aktuelle Datenhaltung ist einfach ein Graus, die Backups sind immer wieder ein Gefrickel da wichtige Daten über mehrere Geräte verteilt sind, bei Ausfall einer HDD sind alle Daten von dieser verloren (und die HDDs sind schon älter...) und so weiter.
Klar würde auch ein simples NAS diese Aufgabe bewältigen, aber ich will zwingend ESXi einsetzen
Klar würde auch ein simples NAS diese Aufgabe bewältigen, aber ich will zwingend ESXi einsetzen
Achso, wenn zwingend ESXi, dann bleiben quasi nur zwei (OK, eigentlich drei) Möglichkeiten unter anbetracht der Tatsache, das du ein Raidlevel für die HDDs willst...
-> Hardware Raidcontroller, der ESXi tauglich ist -> geht bei dem IBM1015 los für um die ~120€ bis hin zu großen und teuren anderen Controllern mit BBU und Cache.
-> Storage Appliance mit Softwareraid -> hier kommt es drauf an was du willst. ZFS beispielsweise so wie gea es sagt wäre ebenso mit nem Hardwarecontroller via Passthrough an die VM gereicht, Alternativ eben RDM oder simple VMDK Files. ESXi Install möglicherweise auf nem USB Stick (und ein Backup, sprich 1:1 Klon davon im Schrank)
-> eventuelle Möglichkeit drei ist der ESXi ohne lokales Storage gepaart mit nem externen Storage ala QNAP und Co. oder halt nem Selbstbau, wie auch immer aussehend -> Nachteil, zwei Geräte...
Leider besteht gerade im privaten Umfeld immer wieder das Problem, das die Leute idR nicht bereit sind, tief(er) in die Tasche zu greifen aber dennoch auf der anderen Seite extremste Ansprüche an die Verfügbarkeit und Sicherheit haben
Hier den Mittelweg zu finden ist äußerst schwer, schwerer noch als im Businessumfeld
PS: der ML310e ist immernoch eine sehr gute Basis...
Solltest du dich für die Softwareraid Version ala gea entscheiden, wäre das ein sehr guter Anfang für wenig Geldeinsatz. -> man müsste nur noch schauen, wie es mit dem RAM Ausbau ausschaut. Und was du sonst noch für VMs da drauf packen willst. Denn 16GB der möglichen 32GB von dem Ding würde ich persönlich nicht für das Storage verblasen, wenn es nur darum geht, ein paar Daten mit nem Raidlevel abzusichern...
Ich überlege immernoch ob ich mir das ML Teil besorgen soll. 16GB ECC RAM hätte ich sogar hier, die wohl passen müssten. Bin mir nur unschlüssig ob mir das Ding nicht zu wenig liefert Für den Preis zwar sehr gut, nur nutzt mir der Preis nix, wenn ich dann im 32GB RAM Limit hänge und nochmal neu kaufen muss 
Die Möglichkeit nach mehr RAM wie 32GB wäre sehr schön für mich... -> und das geht ja auch seit ESXi 5.5 wieder.
-> Hardware Raidcontroller, der ESXi tauglich ist -> geht bei dem IBM1015 los für um die ~120€ bis hin zu großen und teuren anderen Controllern mit BBU und Cache.
-> Storage Appliance mit Softwareraid -> hier kommt es drauf an was du willst. ZFS beispielsweise so wie gea es sagt wäre ebenso mit nem Hardwarecontroller via Passthrough an die VM gereicht, Alternativ eben RDM oder simple VMDK Files. ESXi Install möglicherweise auf nem USB Stick (und ein Backup, sprich 1:1 Klon davon im Schrank)
-> eventuelle Möglichkeit drei ist der ESXi ohne lokales Storage gepaart mit nem externen Storage ala QNAP und Co. oder halt nem Selbstbau, wie auch immer aussehend -> Nachteil, zwei Geräte...
Leider besteht gerade im privaten Umfeld immer wieder das Problem, das die Leute idR nicht bereit sind, tief(er) in die Tasche zu greifen aber dennoch auf der anderen Seite extremste Ansprüche an die Verfügbarkeit und Sicherheit haben
Hier den Mittelweg zu finden ist äußerst schwer, schwerer noch als im Businessumfeld
PS: der ML310e ist immernoch eine sehr gute Basis...
Solltest du dich für die Softwareraid Version ala gea entscheiden, wäre das ein sehr guter Anfang für wenig Geldeinsatz. -> man müsste nur noch schauen, wie es mit dem RAM Ausbau ausschaut. Und was du sonst noch für VMs da drauf packen willst. Denn 16GB der möglichen 32GB von dem Ding würde ich persönlich nicht für das Storage verblasen, wenn es nur darum geht, ein paar Daten mit nem Raidlevel abzusichern...
Ich überlege immernoch ob ich mir das ML Teil besorgen soll. 16GB ECC RAM hätte ich sogar hier, die wohl passen müssten. Bin mir nur unschlüssig ob mir das Ding nicht zu wenig liefert
Für den Preis zwar sehr gut, nur nutzt mir der Preis nix, wenn ich dann im 32GB RAM Limit hänge und nochmal neu kaufen muss Die Möglichkeit nach mehr RAM wie 32GB wäre sehr schön für mich... -> und das geht ja auch seit ESXi 5.5 wieder.
Zuletzt bearbeitet:
S1366 ist mir zu alt
Da die Kiste bei mir 24/7 laufen wird, muss es Stromsparend sein.
Ich überlege ja immernoch auf Desktopkomponenten für S2011 zu gehen und ne kleine Xeon CPU reinzudrücken -> + Undervolting und Multi runter.
CPU Leistung brauch ich im Grunde nur sporadisch. RAM aber um so mehr. Die SBS VM kann mal locker 12GB verblasen. Und ich will das Dingens halt nicht direkt nach Kauf schon wieder in die Ecke fahren...
Rein vom Preis her ist der ML310e ja quasi unschlagbar mit ~360€.
Nur bekommt man für eben diese ~360€ schon ein anständiges S2011 System. S115x Xeons sowieso (Board, CPU und NT) -> 4x4GB ECC RAM hätte ich halt noch hier...
Da die Kiste bei mir 24/7 laufen wird, muss es Stromsparend sein.
Ich überlege ja immernoch auf Desktopkomponenten für S2011 zu gehen und ne kleine Xeon CPU reinzudrücken -> + Undervolting und Multi runter.
CPU Leistung brauch ich im Grunde nur sporadisch. RAM aber um so mehr. Die SBS VM kann mal locker 12GB verblasen. Und ich will das Dingens halt nicht direkt nach Kauf schon wieder in die Ecke fahren...
Rein vom Preis her ist der ML310e ja quasi unschlagbar mit ~360€.
Nur bekommt man für eben diese ~360€ schon ein anständiges S2011 System. S115x Xeons sowieso (Board, CPU und NT) -> 4x4GB ECC RAM hätte ich halt noch hier...
PS: der ML310e ist immernoch eine sehr gute Basis...
Solltest du dich für die Softwareraid Version ala gea entscheiden, wäre das ein sehr guter Anfang für wenig Geldeinsatz. -> man müsste nur noch schauen, wie es mit dem RAM Ausbau ausschaut. Und was du sonst noch für VMs da drauf packen willst. Denn 16GB der möglichen 32GB von dem Ding würde ich persönlich nicht für das Storage verblasen, wenn es nur darum geht, ein paar Daten mit nem Raidlevel abzusichern...
Sehe ich auch so.
Wenn es nur um ZFS Raid geht, reichen 2 GB für die Storage VM. Man hat dann aber nur die Festplattenperformance. Viel RAM bedeutet ja viel Readcache und damit Performance. Meine eigene Standardkonfiguration für neue Setups geht daher von 64 GB RAM mit 24-32 GB für die Storage VM aus. Das setzt aber Sockel 2011 vorraus.
epionier
Enthusiast
- Mitglied seit
- 18.07.2008
- Beiträge
- 187
Hallo,
mal eine Frage an die Experten. Der kostenlose vSphere 5.5 Hypervisor hat ja ein Limit von 8 vCPU pro VM.
Wenn man einen 6-Kern Prozessor mit Hyper-Threading hat, hätte man ja theoretisch 12 vCPU in dem Hypervisor für alle VMs zur Verfügung.
Wenn man jetzt einer VM mehr als 8 vCPU zuweisen möchte, wäre das mit der Möglichkeit der virtuellen Sockets machbar?
Also man würde für eine VM zwei virtuelle Sockets mit je 6 vCPU zuweisen und hätte damit 12 vCPU für eine VM.
Oder umfasst die vCPU Beschränkung in der kostenlosen Version auch die virtuellen Sockets?
mal eine Frage an die Experten. Der kostenlose vSphere 5.5 Hypervisor hat ja ein Limit von 8 vCPU pro VM.
Wenn man einen 6-Kern Prozessor mit Hyper-Threading hat, hätte man ja theoretisch 12 vCPU in dem Hypervisor für alle VMs zur Verfügung.
Wenn man jetzt einer VM mehr als 8 vCPU zuweisen möchte, wäre das mit der Möglichkeit der virtuellen Sockets machbar?
Also man würde für eine VM zwei virtuelle Sockets mit je 6 vCPU zuweisen und hätte damit 12 vCPU für eine VM.
Oder umfasst die vCPU Beschränkung in der kostenlosen Version auch die virtuellen Sockets?
Zuletzt bearbeitet:
So schauts aus... Mal ganz davon ab, es macht imho wenig Sinn A) einer VM alle CPU Ressourcen zuzuteilen und B) die SMT Parts der CPU ebenso so strikt einzuplanen.
Denn durch die zusätzliche Abstraktionsschicht des Hypervisors zwischen Hardware und Clientbetriebssystem verliert das Gast OS schlicht die Möglichkeit zu sehen, ob es sich um SMT/CMT Parts handelt oder um "echte" Cores. -> sprich das Threadscheduling funktioniert nicht mehr sauber und ist gerade bei Teilllast unter Umständen stark langsamer. -> nämlich weil unter der Decke Last auf einen Core und dessen SMT Part gelegt wird, obwohl noch physische Cores vorhanden sind, die nix machen
SMT bringt im VMware Umfeld schon etwas, wenn man die CPU Leistung wirklich braucht. In der überwiegenden Mehrheit der Einsatzfälle dürfte die Gesamt-CPU Load aber so oder so eher gering sein und somit würde SMT gar nix bringen.
Mal ganz davon ab, der ESXi ist eher dafür da, die Ressourcen auf mehere VMs zu sharen, anstatt alle Ressourcen einer einzigen VM bereitzustellen.
In das 8 vCPU Limit vom freien ESXi kommt man im Regelfall gar nicht
Denn durch die zusätzliche Abstraktionsschicht des Hypervisors zwischen Hardware und Clientbetriebssystem verliert das Gast OS schlicht die Möglichkeit zu sehen, ob es sich um SMT/CMT Parts handelt oder um "echte" Cores. -> sprich das Threadscheduling funktioniert nicht mehr sauber und ist gerade bei Teilllast unter Umständen stark langsamer. -> nämlich weil unter der Decke Last auf einen Core und dessen SMT Part gelegt wird, obwohl noch physische Cores vorhanden sind, die nix machen
SMT bringt im VMware Umfeld schon etwas, wenn man die CPU Leistung wirklich braucht. In der überwiegenden Mehrheit der Einsatzfälle dürfte die Gesamt-CPU Load aber so oder so eher gering sein und somit würde SMT gar nix bringen.
Mal ganz davon ab, der ESXi ist eher dafür da, die Ressourcen auf mehere VMs zu sharen, anstatt alle Ressourcen einer einzigen VM bereitzustellen.
In das 8 vCPU Limit vom freien ESXi kommt man im Regelfall gar nicht
epionier
Enthusiast
- Mitglied seit
- 18.07.2008
- Beiträge
- 187
Vielen Dank für eure Antworten, hatte ich mir fast schon gedacht, dass man das Limit nicht so einfach "umschiffen" kann.
@fdsonne: Bei deinen Ausführungen zu den SMT Parts kann ich nur bedingt mithalten. Grund meiner Überlegung war, dass auf einem Sever nur eine VM ausgeführt wird (Win2008R2), mit der sich die Benutzer per Remote Desktop Services verbinden um hierauf zu arbeiten. Andere VMs bestehen nicht. Jetzt geht es darum die vorhandenen Ressourcen, soweit möglich, vollständig für diese VM bereitzustellen. Wenn ich aber nur 8 vCPU zuweisen kann, dann gibt es ja bei dem System übrige CPU-Kerne, die keine Leistung erbringen, da eine vCPU einem CPU-Kern bzw. dessen Hyper-Threading-Verdoppelung entspricht, richtig?
Grund für die (nicht für diesen Zweck gedachte) Virtualisierung auf dem Server ist die einfache Handhabung von Snapshots und Backups und die damit gegebene vereinfachte Wiederherstellungsfähigkeit einer korrupten VM. Zudem auch die bestehende Flexibilität mit einer eventuellen Erweiterung zur Ausnutzung der Hardware.
Ist in dieser Konstellation (vSphere->VM), im Vergleich zu einer Bare-Metal-Installation von Win2008R2 eine erhebliche Minderleistung zu erwarten? Ich meine jetzt ungeachtet von der konkreten Hardware/Treiber, etc.?
@fdsonne: Bei deinen Ausführungen zu den SMT Parts kann ich nur bedingt mithalten. Grund meiner Überlegung war, dass auf einem Sever nur eine VM ausgeführt wird (Win2008R2), mit der sich die Benutzer per Remote Desktop Services verbinden um hierauf zu arbeiten. Andere VMs bestehen nicht. Jetzt geht es darum die vorhandenen Ressourcen, soweit möglich, vollständig für diese VM bereitzustellen. Wenn ich aber nur 8 vCPU zuweisen kann, dann gibt es ja bei dem System übrige CPU-Kerne, die keine Leistung erbringen, da eine vCPU einem CPU-Kern bzw. dessen Hyper-Threading-Verdoppelung entspricht, richtig?
Grund für die (nicht für diesen Zweck gedachte) Virtualisierung auf dem Server ist die einfache Handhabung von Snapshots und Backups und die damit gegebene vereinfachte Wiederherstellungsfähigkeit einer korrupten VM. Zudem auch die bestehende Flexibilität mit einer eventuellen Erweiterung zur Ausnutzung der Hardware.
Ist in dieser Konstellation (vSphere->VM), im Vergleich zu einer Bare-Metal-Installation von Win2008R2 eine erhebliche Minderleistung zu erwarten? Ich meine jetzt ungeachtet von der konkreten Hardware/Treiber, etc.?
CeeS
Enthusiast
So schauts aus... Mal ganz davon ab, es macht imho wenig Sinn A) einer VM alle CPU Ressourcen zuzuteilen und B) die SMT Parts der CPU ebenso so strikt einzuplanen.
Denn durch die zusätzliche Abstraktionsschicht des Hypervisors zwischen Hardware und Clientbetriebssystem verliert das Gast OS schlicht die Möglichkeit zu sehen, ob es sich um SMT/CMT Parts handelt oder um "echte" Cores. -> sprich das Threadscheduling funktioniert nicht mehr sauber und ist gerade bei Teilllast unter Umständen stark langsamer. -> nämlich weil unter der Decke Last auf einen Core und dessen SMT Part gelegt wird, obwohl noch physische Cores vorhanden sind, die nix machen
Laut vmware werden auf CPUs mit HT/SMT zuerst die non-HT/SMT Kerne und danach erst die HT/SMT Kerne zugeteilt!
Trotzdem sollte man immer das Prinzip so wenig wie möglich, soviel wie nötig (bei vRessourcen) anwenden!
EDIT: Die Unterscheidung zwischen vSockets und vCores hat nur lizenzrechtliche Gründe wie sich die vCPU im BS darstellen. Es gibt Software die verlangt für die Lizensierung z.B. x Sockel statt Kerne
Zuletzt bearbeitet:
Jein
im Grunde macht das VMware so, aber wenn du 12 vCPUs einer VM zuteilst, kann diese VM nicht mehr wissen, was unter der Decke nun SMT ist und was nicht
Dann kommt es zu problemen, denn der OS Threadscheduler verteilt die Last unter Umständen schön gleichmäßig auf alle 12 Einheiten. Und es kommt zu nem Leistungsprolem
im Grunde macht das VMware so, aber wenn du 12 vCPUs einer VM zuteilst, kann diese VM nicht mehr wissen, was unter der Decke nun SMT ist und was nicht
Dann kommt es zu problemen, denn der OS Threadscheduler verteilt die Last unter Umständen schön gleichmäßig auf alle 12 Einheiten. Und es kommt zu nem Leistungsprolem
CeeS
Enthusiast
ja das ist mir absolut klar - gin mir eher um folgenden Satz:
den ich so verstanden hab, dass vmware bzw. das OS auch bei nicht vollbelegung der physischen Cores nicht unterscheiden kann, was ja nicht der Fall ist
den ich so verstanden hab, dass vmware bzw. das OS auch bei nicht vollbelegung der physischen Cores nicht unterscheiden kann, was ja nicht der Fall ist
??
Wenn es dir klar ist, gehst du quasi konform zu meiner Aussage, wie kann dann die Aussage nicht der Fall sein!?
Es geht eigentlich darum, das der Host zwar die Unterschiede kennt, ihm das aber unter der Decke fast nix nutzt, wenn die VM CPU Ressourcen von 12 vCPUs gleichzeitig haben möchte. Und diese sind eben bei 12 vCPUs gleichzeitig auch gleich priorisiert. Der Host unter der Decke muss dann versuchen das aufzuteilen. Aber das kann er schlicht nicht perfekt, da er nicht weis, was da für Berechnungen durchlaufen -> ein klarer Nachteil. Kostet dich bei SMT unterm Strich teils 20-40% Performance.
Ich hatte vor ein paar Wochen hier im Forum dazu sogar mal ein paar Bilder gemacht, wo man wunderhübsch erkannt hat, wie "beschissen" die Verteilung dann ist/wird.
PS: Auch mit Priorisierung kommt man da nicht weit. A) nur eine VM, B) wird wenn ich das sehe immer pro VM im gesamten Priorisiert. Und die Priorisierung ignoriert quasi die vCPU Zuteilung und geht auf MHz/GHz Ebene.
Wenn es dir klar ist, gehst du quasi konform zu meiner Aussage, wie kann dann die Aussage nicht der Fall sein!?
Es geht eigentlich darum, das der Host zwar die Unterschiede kennt, ihm das aber unter der Decke fast nix nutzt, wenn die VM CPU Ressourcen von 12 vCPUs gleichzeitig haben möchte. Und diese sind eben bei 12 vCPUs gleichzeitig auch gleich priorisiert. Der Host unter der Decke muss dann versuchen das aufzuteilen. Aber das kann er schlicht nicht perfekt, da er nicht weis, was da für Berechnungen durchlaufen -> ein klarer Nachteil. Kostet dich bei SMT unterm Strich teils 20-40% Performance.
Ich hatte vor ein paar Wochen hier im Forum dazu sogar mal ein paar Bilder gemacht, wo man wunderhübsch erkannt hat, wie "beschissen" die Verteilung dann ist/wird.
PS: Auch mit Priorisierung kommt man da nicht weit. A) nur eine VM, B) wird wenn ich das sehe immer pro VM im gesamten Priorisiert. Und die Priorisierung ignoriert quasi die vCPU Zuteilung und geht auf MHz/GHz Ebene.
G
Gelöschtes Mitglied 135497
Guest
Hi All,
ich wollte ursprünglich meinen ESXi 5.1 auf 5.5 updaten, hab mich schlussendlich dann doch umentschieden und komplett neu installiert - jetzt nach der Neuinstallation stehe ich vor einem kleinem Mysterium - die komplette Hardware ist unverändert, und doch funktioniert mein LSI MegaRAID 9260-8i Kontroller nicht mehr in dem Slot, in dem er unter 5.1 ein Jahr lang perfekt gelaufen ist.
Nachdem ich den Passtrough für das Gerät aktiviert und den Host neugestartet habe, sieht es so aus: (Slot 6)
Das Gerät kann im Gast nicht verwendet werden, es lässt sich nicht aktivieren.
Wenn ich den Kontroller aber in einen anderen PCIe Slot 4 stecke und Passtrough aktiviere, funktioniert er nach dem Neustart sofort und ohne Probleme, siehe:
Mainboard ist ein Supermicro X9SCM-F
WARUM IST DAS SO - WAS MUSS ICH TUN UM DEN ANDEREN SLOT ZUM FUNKTIONIEREN ZU BEKOMMEN ??
Bitte um eure Hilfe !!
DANKE,
Stefan
ich wollte ursprünglich meinen ESXi 5.1 auf 5.5 updaten, hab mich schlussendlich dann doch umentschieden und komplett neu installiert - jetzt nach der Neuinstallation stehe ich vor einem kleinem Mysterium - die komplette Hardware ist unverändert, und doch funktioniert mein LSI MegaRAID 9260-8i Kontroller nicht mehr in dem Slot, in dem er unter 5.1 ein Jahr lang perfekt gelaufen ist.
Nachdem ich den Passtrough für das Gerät aktiviert und den Host neugestartet habe, sieht es so aus: (Slot 6)
Das Gerät kann im Gast nicht verwendet werden, es lässt sich nicht aktivieren.
Wenn ich den Kontroller aber in einen anderen PCIe Slot 4 stecke und Passtrough aktiviere, funktioniert er nach dem Neustart sofort und ohne Probleme, siehe:
Mainboard ist ein Supermicro X9SCM-F
WARUM IST DAS SO - WAS MUSS ICH TUN UM DEN ANDEREN SLOT ZUM FUNKTIONIEREN ZU BEKOMMEN ??
Bitte um eure Hilfe !!
DANKE,
Stefan
automatenraum
Enthusiast
- Mitglied seit
- 15.02.2013
- Beiträge
- 179
Hi!
Wenn man so durch die Foren liest, gibt es verstärkt Probleme mit dem Passthrough beim Wechsel auf ESXi 5.5, daher gehen viele wieder zurück auf die ältere Version. Auch für dich wird es keine andere Lösung geben, als die alte Version einzusetzen und auf einen Fix in der Zukunft zu hoffen...
EDIT: Ich habe gerade gesehen für das Board gibt es eine neue BIOS Version (2.0c), ich weiss nicht ob ein Update helfen würde und ob es ein Changelog dafür gibt, Versuch macht klug.
Wenn man so durch die Foren liest, gibt es verstärkt Probleme mit dem Passthrough beim Wechsel auf ESXi 5.5, daher gehen viele wieder zurück auf die ältere Version. Auch für dich wird es keine andere Lösung geben, als die alte Version einzusetzen und auf einen Fix in der Zukunft zu hoffen...
EDIT: Ich habe gerade gesehen für das Board gibt es eine neue BIOS Version (2.0c), ich weiss nicht ob ein Update helfen würde und ob es ein Changelog dafür gibt, Versuch macht klug.
Zuletzt bearbeitet:
LichtiF
Enthusiast
Ja die haben bei ESXi 5.5 etliches geändert was wohl etliche Probleme mit Passthrough macht ich würde auch bei 5.1 bleiben wenn du nicht unbedingt 5.5 brauchst.
vmnic/vmhba sequence changed in ESXi 5.5 tippe mal das die Änderung die Probleme machen könnte.
vmnic/vmhba sequence changed in ESXi 5.5 tippe mal das die Änderung die Probleme machen könnte.
Also zumindest abseits von Passthrough laufen die 5.5er definitiv sauber. Bei uns sinds jetzt sechs Hosts die das haben und rennt wie Hanne
Einzig der Umstand, das man im VI Client nicht mehr die vmx10 VMs bearbeiten kann, ist ärgerlich. Der Webclient ist leider immernoch etwas grausig. Zumindest was die Performance angeht... -> das Java/Flash Zeugs scheint nicht wirklich schnell laufen zu können.
Einzig der Umstand, das man im VI Client nicht mehr die vmx10 VMs bearbeiten kann, ist ärgerlich. Der Webclient ist leider immernoch etwas grausig. Zumindest was die Performance angeht... -> das Java/Flash Zeugs scheint nicht wirklich schnell laufen zu können.
automatenraum
Enthusiast
- Mitglied seit
- 15.02.2013
- Beiträge
- 179
Ich habe gerade mal noch etwas geforscht, bei dem Board gab es wohl mit der BIOS Version 2.0 Passthrough Probleme, das wurde definitiv ab der BIOS Version 2.0b behoben, also wenn du eine ältere Version als 2.0b drauf hast, könnte ein Update auf 2.0c Abhilfe schaffen. Wenn es allerdings mit 5.1 ging und mit 5.5 dann nicht mehr, glaube ich hast du wenig Hoffnung und musst auf einen Fix warten. Ich habe das selbe Board, setze aber noch 5.1 ein, weil ich nie direkt neue Software Versionen einsetze, weil es immer Probleme und Bugs gibt. Was sich hier ja auch mal wieder bestätigt...
G
Gelöschtes Mitglied 135497
Guest
ok - danke für die BIOS info, werde herausfinden welche ich drauf hab, ggf. ein update durchführen und die Ergebnisse posten.
Der Update bzw. meine Neuinstallation von 5.1 auf 5.5 war nicht ganz freiwillig - habe den 5.1er zu Tode virtualisiert und einen passtrough konfig fehler gemacht, danach ging garnichtsmehr - also alles neu, zu diesem Zeitpunkt ist die 5.5er gerade rausgekommen, ich dachte mir, was kanns schaden ??
Der Update bzw. meine Neuinstallation von 5.1 auf 5.5 war nicht ganz freiwillig - habe den 5.1er zu Tode virtualisiert und einen passtrough konfig fehler gemacht, danach ging garnichtsmehr - also alles neu, zu diesem Zeitpunkt ist die 5.5er gerade rausgekommen, ich dachte mir, was kanns schaden ??
@Besserpunk11
Hast du schon mal versucht (ich kenne das Board nicht) UEFI oder Legacy zu booten? Ich hatte das Problem in einer anderen Konstellation mit einem anderen Board und diesem Controller. Der Controller wurde nur im Legacy Mode erkannt.
VG
Hast du schon mal versucht (ich kenne das Board nicht) UEFI oder Legacy zu booten? Ich hatte das Problem in einer anderen Konstellation mit einem anderen Board und diesem Controller. Der Controller wurde nur im Legacy Mode erkannt.
VG
Vogelbecker
Enthusiast
Hallo zusammen,
ich konnte auf der Arbeit einige Server abgreifen:
Sun Fire X4140 mit 2x Amd Opteron 2347, 32 GB Ram und 2x 73 GB SAS HDD.
An sich also ganz nette Kisten.
Leide sind die nun ja schon etwas älter. Offiziell wird ESXi 4.1 unsterstützt. Das läuft soweit auch perfekt.
Leider ließ sich 5.5 nicht installieren, der Installer hat sich immer aufgehängt.
Meint ihr, es ist möglich, die Kiste nun von 4.1 auf 5.5 upzugraden?
Viele Grüße
ich konnte auf der Arbeit einige Server abgreifen:
Sun Fire X4140 mit 2x Amd Opteron 2347, 32 GB Ram und 2x 73 GB SAS HDD.
An sich also ganz nette Kisten.
Leide sind die nun ja schon etwas älter. Offiziell wird ESXi 4.1 unsterstützt. Das läuft soweit auch perfekt.
Leider ließ sich 5.5 nicht installieren, der Installer hat sich immer aufgehängt.
Meint ihr, es ist möglich, die Kiste nun von 4.1 auf 5.5 upzugraden?
Viele Grüße
Zuletzt bearbeitet:
@Vogelbecker
es wäre hilfreich rauszubekommen, warum sich der Installer aufhängt
Mal ganz davon ab, es gibt noch ne 5.0 und 5.1, die du durchtesten kannst... Ein Update von 4.x direkt auf 5.5 würde ich nicht unbedingt machen... Potentiell gehen sollte es aber imho schon.
Klingt aber irgendwie so, als würden ihm ein paar Treiber oder sowas fehlen. Das muss nach dem Update dann aber nicht unbedingt immernoch so sein.
es wäre hilfreich rauszubekommen, warum sich der Installer aufhängt
Mal ganz davon ab, es gibt noch ne 5.0 und 5.1, die du durchtesten kannst... Ein Update von 4.x direkt auf 5.5 würde ich nicht unbedingt machen... Potentiell gehen sollte es aber imho schon.
Klingt aber irgendwie so, als würden ihm ein paar Treiber oder sowas fehlen. Das muss nach dem Update dann aber nicht unbedingt immernoch so sein.
Vogelbecker
Enthusiast
Jau das ist eine gute Frage, werde nachher mal schauen. Zur Not gehe ich die Schritte über 5.0 und 5.1 nach 5.5.
Grüße
Grüße
automatenraum
Enthusiast
- Mitglied seit
- 15.02.2013
- Beiträge
- 179
@besserpunk11:
Bezüglich Änderungen im Bios vom Supermicro X9SCM-F, habe ich mal den Support angeschrieben, weil ich auch das Board habe und es mich interessiert hat. Ich denke zur Problematik sind aber keine Änderungen vorgenommen worden:
Here is the change log from 2.0b to 2.0c:
1. Update Intel RC package to 1.8
2. Fix console screen corrupt issue(after OPROM initial POST screen restore)
3. Update Intel RST to 12.6
4. Correct setup power button override function(4-sec shutdown)
5. Correct setup Above4GDecode function
6. Update BMC initial process
7. Fix USB hot-plug event cause system hang(in BIOS / legacy OS)
8. Update CPU microcode
9. Hide Driver health setup menu
10.Allow user change SMBIOS data multiple times.{Funciton improve.}
11.Change BIOS revision to 2.0c
Grüße Reiner
Bezüglich Änderungen im Bios vom Supermicro X9SCM-F, habe ich mal den Support angeschrieben, weil ich auch das Board habe und es mich interessiert hat. Ich denke zur Problematik sind aber keine Änderungen vorgenommen worden:
Here is the change log from 2.0b to 2.0c:
1. Update Intel RC package to 1.8
2. Fix console screen corrupt issue(after OPROM initial POST screen restore)
3. Update Intel RST to 12.6
4. Correct setup power button override function(4-sec shutdown)
5. Correct setup Above4GDecode function
6. Update BMC initial process
7. Fix USB hot-plug event cause system hang(in BIOS / legacy OS)
8. Update CPU microcode
9. Hide Driver health setup menu
10.Allow user change SMBIOS data multiple times.{Funciton improve.}
11.Change BIOS revision to 2.0c
Grüße Reiner