ESX / ESXi - Hilfethread

So....
Ein Leichtsinn Fehler hatte sich eingeschlichen! Ich muss natürlich auch das Passwort hinter das ssh root@esxi setzen. Das hab ich getan und im esxi hätte ich noch eine Änderung im automatisch herunterfahren gemacht. Jetzt passt es.

Ich bekomm eine E-Mail mit UPS on Batterie und er fährt dann wenn die usv die Batterie low Meldung bringt alles ganz ordentlich herunter. Für meinen privatgebrauch ist das völlig ausreichend. [emoji12]
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Guten Abend,

ich beschäftige mich das erste Mal mit Virtualisierung und bin nun schon seit einiger Zeit am Lesen und Probieren. Als nächstes steht der Test von ESXI als Hypervisor an. Meine Frage bezieht sich nun auf die spätere Vorgehensweise bei der Aufsetzung des System, vorallem gedacht als NAS-Storage und diverse kleine VM`s. Ich habe mir überlegt ESXI + NappIT als Storage VM auf eine SSD zu installieren. Die restlichen VM sollen auf ein Raid1 (bestehend aus 2 SSD´s und ZFS als Dateisystem) kommen.Eine M.2 SSD eventuell als Cache, oder sollte ich die anderweitig nutzen? Restlicher Storage dann auf HDD´s. Die Frage die sich daraus ergibt ist,ob das so Sinn macht, bzw. ob es andere Lösungen gibt?

Vielen Dank schonmal,und ich hoffe mal das ist der richtige Thread für meine Fragen.

Mit freundlichen Grüßen,

tekken321
 
Die spannende Frage ist einfach, was soll in den VMs laufen? Für normale Applilationen die vielleicht ein wenig rechnen (transkodieren) sollen, passt das mit Sicherheit mit den SSD ohne NVME als Cache. Aber wenn du wirklich richtig I/O-lastige Anwendungen fährst und die SATA-SSDs limitieren würde ich überlegen, dieser VM vielleicht auch die NVME-SSD (direkt) zu geben.
 
Hehehe... und dann wären wir auch schon beim Thema Budget. :)

Am besten machst Du einen Kaufberatungsthread auf mit Deinen genaueren Anforderungen, Budget usw.
 
Hi, vielen Dank schonmal für die Antworten. Also es werden keine I/O lastigen Anwendungen drauf laufen,in Summe wohl auch nicht mehr als 6-7 VM.
Also spricht soweit nix dagegen, ESXi & NappIT auf eine SSD und den Rest der VM als Raid1?

Gesendet von meinem SM-G935F mit Tapatalk
 
Ja. Passt so.
 
Habe jetzt mal versucht von meiner OMV VM ein NFS4 Share in ESXi als Datastore zu mounten.
Funktioniert auch erstmal. D.h. der Datastore wird erfolgreich eingebunden.
Danach gibt es aber zwei Probleme:

1. Der Datastore lässt sich nicht browsen, denn er taucht im Browser gar nicht auf
2. Beim Reboot des ESXi Hosts kommt es zu einer längeren Wartezeit beim Starten des nfs4 Clients (vermutlich weil die Storage VM ja noch nicht gestartet ist). Wenns ESXi dann weiter startet, ist der NFS Datastore nicht gemountet und das bleinbt auch so. Ich kann ihn nur neu anlegen.

Es lassen sich auch VMs auf dem NFS Datastore anlegen, d.h. Schreibberechtigung ist vorhanden.

Ist das ein bekanntes Problem? Muss ich noch irgendwas bestimmtes einstellen, wenn der Datastore erst später (nach Start der Storage VM) gemountet werden soll?

Danke für eure Hilfe ... (Die Suche hat leider nicht zum Erfolg geführt) :(

VG
André
 
Ja, es kommt zu teilweise sehr langen Wartezeiten, wenn die Storage-VM und damit die NFS-Freigabe weg ist. Das merkt man zum Teil dann auch recht stark (Minuten-Aussetzer) im ESXi Web-UI. Da ist dann Geduld gefragt.

Das Phänomen, dass die NDS-Freigabe dauerthaft nicht erkannt wird, habe ich nicht. VMs die dort liegen werden als ungültig oder so gekennzeichnet, wenn die Storage-VM weg ist, aber wenn die wieder oben ist, kommen auch Storage und VM wieder (entweder wenn man die Ansicht im Web-UI wechselt oder auf „aktualisieren“ klickt.

Nach einem Reboot genauso: Nach Verlassen des Wartungsmodus’ erst Storage-VM hochfahren und dann eben den Rest. Habe ich hier keine Probleme mit, habe das aber auch nicht automatisiert oder so, sondern mache das nach Reboots immer manuell übers Web-UI.
 
Es liegt wohl an der Kombination OMV und NFS4.
Habe es jetzt mit napp-it getestet und es funktioniert perfekt.
Und mit der entsprechenden Start-Priorität ist die Storage-VM verfügbar, bevor die VMs, die auf napp-it liegen, gestartet werden.
Beim runterfahren des Hosts funktioniert es genauso vollautomatisch. D.h. jetzt ist der Umstieg auf napp-it besiegelt. ;)
 
Hi,

ich habe mir auch mal ein System mit ESXi aufgesetzt, leider habe ich da noch ein paar Probleme.

System:
Supermicro X10SDV-TLN4F Xeon-D 1541 8Core/16Thread
2x Samsung DIMM 32GB, DDR4-2400, CL17-17-17, reg ECC M393A4K40BB1
Dell Perc H310 geflasht mit LSI IT Firmware Version 20.00.07.00 zeigt jetzt LSI 9211-8i an, in ESXi und unter Windows wird es aber als DELL SAS 6GB erkannt
1xSamsung 840, 250GB an SATA Port des Boards
2xSeagate Nytro XF1230 1920GB am H310

Installiert ist ESXi 6.5.0 Update 1 (Build 7388607) auf der Samsung SSD.

Ich habe drei Datastores (VMFS6):
-Store1: Einmal der von ESXi nicht benötigte Speicher auf der Samsung SSD, darauf liegt auch die einzige VM Windows Server 2016.
-Store2 und Store3: jeweils der Speicher der Seagate SSDs


Die VM hat eine 100 GB OS Partion auf Store 1 und je eine 1TB Partition auf Store2 und Store3.

Kopiere ich jetzt eine Datei von Store2 nach Store3 bzw. von Store3 nach Store2 habe ich eine totale niedrige Übertragungsrate mit starken Einbrüchen.
e nach f.JPG
f nach e.JPG

Kopieren von Store1 auf Store2/3 oder umgekehrt sieht ähnlich aus.

Gleiche Konfig nur direkt unter Windows Server 2016 liefert konstant 460-490 MB/s. Die SSDs habe ich auch in einem anderen System getestet und dort auch keinerlei Probleme oder Einbrüche feststellen können, SMART etc. ebenfalls ohne Auffälligkeiten.

Sind die Datastores tatsächlich so langsam?

Vielleich kann mir jemand hier helfen.

Viele Grüße

Jürgen
 
Zuletzt bearbeitet:
Ich denke das Hauptproblem ist, dass ESXi zwar so ziemlich den besten Virtualisierer macht, aber die ESXi internen Storagefeatures eher sagen wir mal mau sind. Das kann man teilweise durch einen High-End Storagecontroller mit RAM kompensieren. Im Pass-through Modus kommt es dann auf das Gastsystem an und Windows ist da nicht gerade Spitze wenn es um Storage Performance geht. Auch sind die Desktop Samsung SSDs ganz gut in Desktops aber eher weniger gut wenn es um dauerhafte Schreibperformance geht.

ESXi selber möchte eher SAN Storage als lokalen Storage um schnell zu sein. Den kann man aber durchaus auch virtualisiert bereitstellen, vgl meine Tests unter http://napp-it.org/doc/downloads/optane_slog_pool_performane.pdf

Vor allem RAM sofern das genutzt wird wie bei ZFS und in geringerem Umfang schnelle SSDs sind der Schlüssel.
 
Datastores mit VMFS5/VMFS6 sind eigentlich durchaus performant, von dem gerade erwähnten Sata-AHCI-Problem abgesehen.
Das geht durchaus in den Gbyte/s-Bereich, wenn die Speichergeräte es hergeben (also z.B. bei NVMe-SSDs wie der 960, Optane 900p, etc.)

Aber insbesondere eine 840 Basic oder 840 Evo würde ich nicht wirklich in einem ESXI packen, deren TLC-Generation hat nicht gerade geglänzt. Einer 840pro/850pro kann man bei Dauereinsatz helfen, wenn man dem Controller genug GB an Platz zum rangieren der Blocks/Pages frei lässt, also z.B. bei einer 256er z.B. nur 200 GB als Partitiongröße nutzt.
Eine 850Evo ist zwar gut zum Lesen, aber bei Dauerbelastung mit Schreiben limitiert deren arg begrenzter TurboWrite-Cache.
 
Zuletzt bearbeitet:
Entscheidend ist ob ein Workload per Schreib/Lesecache aus dem RAM bedient werden kann. In dem Fall ist Plattenperformance absolut nicht relevant. Ansonsten gilt zumindest wenn es um Latenz oder iops geht

RAM ist viel schneller als die neuen Optane Flash Laufwerke
Optane (außer die kleinen 16/32GB Cache devices) ist viel schneller als Flash NVMe
Flash NVMe ist viel schneller als Sata Flash
Sata Flash ist viel schneller als mechanische Festplatten
 
Danke für die bisherigen Infos. Bitte die Samsung SSD nicht beachten, die dient nur als Speicher für ESXi und als Speicher für die VM (Betriebssystem).
Die Schreibe-/Leseperferomance sollte ja so eigentlich nur die beiden Seagate SSDs und den Dell H310 betreffen, oder?
Bezüglich dem Link, hier wird der vmw_ahci erwähnt, kommt der hier überhaupt zum Tragen? Sollte hier nicht nur der mpt2sas eine Rolle spielen?
Wie oben erwähnt sind die SSDs unter Windows einiges schneller.

Danke
 
Hi,

ich habe mir auch mal ein System mit ESXi aufgesetzt, leider habe ich da noch ein paar Probleme.

System:
Supermicro X10SDV-TLN4F Xeon-D 1541 8Core/16Thread
2x Samsung DIMM 32GB, DDR4-2400, CL17-17-17, reg ECC M393A4K40BB1
Dell Perc H310 geflasht mit LSI IT Firmware Version 20.00.07.00 zeigt jetzt LSI 9211-8i an, in ESXi und unter Windows wird es aber als DELL SAS 6GB erkannt
1xSamsung 840, 250GB an SATA Port des Boards
2xSeagate Nytro XF1230 1920GB am H310

Installiert ist ESXi 6.5.0 Update 1 (Build 7388607) auf der Samsung SSD.

Ich habe drei Datastores (VMFS6):
-Store1: Einmal der von ESXi nicht benötigte Speicher auf der Samsung SSD, darauf liegt auch die einzige VM Windows Server 2016.
-Store2 und Store3: jeweils der Speicher der Seagate SSDs


Die VM hat eine 100 GB OS Partion auf Store 1 und je eine 1TB Partition auf Store2 und Store3.

Kopiere ich jetzt eine Datei von Store2 nach Store3 bzw. von Store3 nach Store2 habe ich eine totale niedrige Übertragungsrate mit starken Einbrüchen.
Anhang anzeigen 424391
Anhang anzeigen 424392

Kopieren von Store1 auf Store2/3 oder umgekehrt sieht ähnlich aus.

Gleiche Konfig nur direkt unter Windows Server 2016 liefert konstant 460-490 MB/s. Die SSDs habe ich auch in einem anderen System getestet und dort auch keinerlei Probleme oder Einbrüche feststellen können, SMART etc. ebenfalls ohne Auffälligkeiten.

Sind die Datastores tatsächlich so langsam?

Vielleich kann mir jemand hier helfen.

Viele Grüße

Jürgen

-> hast Du hier Infos zu der VM, also wie die konfiguriert ist?
Hast Du die Stor2+3 unter VMware ESXi als Datastores angelegt, oder sind die mit dem Controller direkt in die VM durchgereicht?

und wie war die vergleichskonfig unter Windows?
 
Welche Details der Konfigurationsdetails möchtest Du hier wissen? Sind die angehängten Bilder ausreichend?

Konfig1.JPG

Konfig2.JPG

Konfig3.JPG

Konfig4.jpg Konfig5.jpg Konfig6.jpg

Windows hatte natürlich die komplette Maschine (CPU + RAM) zur Verfügung. Die Platten waren ebenfalls am Dell H310.
Unter Windows jeweils eine große Partition mit der gesamten Kapazität.

Gruß Jürgen
 
Zuletzt bearbeitet:
hm, interessant wäre jetzt, ob Dein Drop nach ungefähr 8GB passiert - worauf ich jetzt mal tippen würde.
Da die Disks ja auch noch als Thin bereitgestellt sind, muss diese auf dem Host auch noch wachsen - ich weiß jetzt nicht, wieviele Schreibvorgänge das im Detail sind, würde aber grob mal auf die doppelte Anzahl tippen, als bei direktem Zugriff. -> Ergo verlierst du hier etwas Performance.

Da der H310 ja zusätzlich verbaut ist, könntest Du ja mal testen, wie sich die Performance Deiner VM verhält, wenn Du den Controller direkt durchreichst - da die Disks dann direkt vom OS verwaltet werden und die Zwischenschicht vom ESX wegfällt, sollte das auch etwas schneller sein.

Der Vergleich einer Baremetall-Installation vs. einer VM mit deutlich weniger Ressourcen ist daher wie MACs und Birnen zu vergleichen ;)
 
Nabend

Evtl. kann mir ein ESXI Spezi diese Frage beantworten. Ich werde bei einem Kunden verbauten IBM M3 Server, gegen ein AMD Epyc System austauschen. Nun sind leider nicht alle CPU für das Dual Board vorrätig, sondern erst nur eine, und die 2 te wird mir in circa 7 Tagen nachgeschickt. Ich würde aber gerne den ESXI schon vorher auf das Blech legen und jetzt kommen wir zu meiner Frage.

Muss ich mit Schwierigkeiten rechnen, wenn ich erst mit einer CPU arbeite und dann 7 Tage später die 2 te CPU dazustecke ? Macht da der ESXI zicken oder läuft das dann so auf Anhieb und der ESXI hat dann einfach mehr Ressourcen und ordnet die automatisch zu ? Würde es etwas bringen wenn ich auf meinem TR4 System (ESXI läuft da sauber drauf im Kurztest), 8 Kerne deaktiviere und ESXI installiere und dann einfach nochmal 8 dazuschalte? Oder macht das kein Sinn weil es nur ein Sockel ist ?

Oder soll ich einfach warten bis die 2 te CPU da ist ?

Vielen Dank für die Fachkundigen Antworten.

Das Board ist übrigens ein Supermicro H11DSi und als CPU kommen 2 x AMD EPYC 7251 zum Einsatz.
 
Zuletzt bearbeitet:
hm, interessant wäre jetzt, ob Dein Drop nach ungefähr 8GB passiert - worauf ich jetzt mal tippen würde.
Da die Disks ja auch noch als Thin bereitgestellt sind, muss diese auf dem Host auch noch wachsen - ich weiß jetzt nicht, wieviele Schreibvorgänge das im Detail sind, würde aber grob mal auf die doppelte Anzahl tippen, als bei direktem Zugriff. -> Ergo verlierst du hier etwas Performance.

Da der H310 ja zusätzlich verbaut ist, könntest Du ja mal testen, wie sich die Performance Deiner VM verhält, wenn Du den Controller direkt durchreichst - da die Disks dann direkt vom OS verwaltet werden und die Zwischenschicht vom ESX wegfällt, sollte das auch etwas schneller sein.

Der Vergleich einer Baremetall-Installation vs. einer VM mit deutlich weniger Ressourcen ist daher wie MACs und Birnen zu vergleichen ;)

Könnte hinkommen mit den 8GB. Habe heute nochmal etwas herumprobiert. Der Drop tritt nicht immer auf, nur etwa jeder 5. Versuch. Pause zwischen den Versuchen 10min.

Aber wenn kein Einbruch auftritt ist die Übertragungsrate dennoch etwa 1/3 unter den Werten direkt mit Windows.

e nach f 2.JPG

Habe dann mal etwas mit dem Arbeitsspeicher der VM herumprobiert.

24GB
e nach f 24GB.JPG

4GB
e nach f 4GB.JPG

Mit dem H310 im Passthrough bricht die Leistung komplett ein??? Hier wieder 8GB RAM.

e nach f passthrough.JPG

e nach f passthrough2.JPG
Muss ich hier noch etwas beachten/einstellen?

Danke und Gruß

Jürgen
 
Zuletzt bearbeitet:
Puh, warum die Leistung im Passthrough auch nicht berauschender ist, kann ich Dir auf Anhieb nicht sagen, da man meinen möchte, die Daten bleiben quasi am Controller - Faktisch wird es aber wohl in der Anbindung (PCIe-Lanes der CPU) liegen, sofern der Controller im virtuellen Windows genauso erscheint wie im physischen.

Die Frage ist natürlich, was die Hauptaufgabe ist, denn ist es notwendig ständig Dateien von einem Store auf den anderen zu kopieren?
 
Die Lese-/Schreibleistung sollte schon passable Werte haben und vor allem nicht einbrechen.
Habe es noch ein paar mal probiert im Passthrough, manchmal bricht er auch hier nicht ein???
Mir ist auch noch aufgefallen, dass die CPU auf 50% Auslastung geht beim Kopieren, das passierte beim direkt installierten Windows nicht.
Hat jemand noch Ideen?
 
Ich hab ESXi auch aufgegeben mit meinem Supermicro X10SDV-TLN4F. Hab zwar kein Passthrough gemacht, sondern direkt einen LSI 9271-8i Raidcontroller verwendet, der auch auf der HCL steht, aber war mit der Storageperformance 2x850evo Raid 1 und 4x4TB HGST Raid10 auch nicht zufrieden. Hatte ein CacheVault Modul, Write Back aktiviert, auch alles andere getestet..

Zuvor lief der Controller in gleicher Konfig unter einem Server 2016 in einem anderen System mehrere Monate ohne irgendwelche Probleme mit den Platten.. Man liest ja immer wieder von schlechter Performance mit Evo´s an den LSI Controllern, aber unter Windows war die Performance der Festplatten einfach so wie es sein soll.

Wollte bei einem Server bleiben ohne extra Storagebox und hab seit einiger Zeit wie vorher wieder Windows Server als Basis und VMware Workstation als Virtualisierer. Für den Heimgebrauch brauch ich keinen ESXi. Hab 20 VMs laufen und Performance ist wie erwartet. Die ganze Flucherei die ich mit ESXi hatte, nicht nur Storage.. hatte ich mit der Kombination noch nie.

Auf dem Host läuft außer der VM Workstation, paar Diagnosetools und der APC Software nichts. Alles andere dann in den VMs.
Die System VMDKs liegen auf den SSDs, alle anderen Daten auf dem Host. SMB Freigabe auf dem Host angelegt und innerhalb der VMs wird über ein extra Hostonly Netz darauf zugegriffen. Laut iperf gehen da auch 5-6Gbit drüber, also limitieren nur die 4TB Platten. Trägt man in den Konfigdateien statt dem e1000 den vmxnet3 manuell ein und installiert die Tools, dann gibts auch vmxnet3 in der VM Workstation.
 
Zuletzt bearbeitet:
Hab hier ein Konfigurationsproblem auf meinem Host:


Das passierte, nach dem ich einen lokalen Storage im Server entfernt habe (Vorher gelöscht, unmounted und anschließend neugestartet ohne dem Storage).

ScratchConfig zeigte davor und danach auf den Hauptspeicher, den ich seit Anfang an drin habe:


Versuche ich das nun zu irgendwas anderes zu ändern (einen testweiße angehangenen iSCSI Storage) kriege ich immer folgende Fehlermeldung:


Der Fehler ist mir so auch mehr oder weniger bekannt (Hier und da kommt er mal) - Kriege den jetzt aber absolut nicht mehr gelöst. .locker löschen/neuanlegen usw. half mir auch nichts. (Pfad vom Laufwerk ist btw. identisch/in Ordnung). Ändere ich btw. am Ende auf z. B. "locker2" auf gleichem Storage, übernimmt er mir bei "OK" nicht die Änderung.
Noch eine Idee hier, oder soll ich einfach nochmal ESXi drüberbügeln?
 
Zuletzt bearbeitet:
Ich hab ESXi auch aufgegeben mit meinem Supermicro X10SDV-TLN4F. Hab zwar kein Passthrough gemacht, sondern direkt einen LSI 9271-8i Raidcontroller verwendet, der auch auf der HCL steht, aber war mit der Storageperformance 2x850evo Raid 1 und 4x4TB HGST Raid10 auch nicht zufrieden. Hatte ein CacheVault Modul, Write Back aktiviert, auch alles andere getestet..

Zuvor lief der Controller in gleicher Konfig unter einem Server 2016 in einem anderen System mehrere Monate ohne irgendwelche Probleme mit den Platten.. Man liest ja immer wieder von schlechter Performance mit Evo´s an den LSI Controllern, aber unter Windows war die Performance der Festplatten einfach so wie es sein soll.

Wollte bei einem Server bleiben ohne extra Storagebox und hab seit einiger Zeit wie vorher wieder Windows Server als Basis und VMware Workstation als Virtualisierer. Für den Heimgebrauch brauch ich keinen ESXi. Hab 20 VMs laufen und Performance ist wie erwartet. Die ganze Flucherei die ich mit ESXi hatte, nicht nur Storage.. hatte ich mit der Kombination noch nie.

Auf dem Host läuft außer der VM Workstation, paar Diagnosetools und der APC Software nichts. Alles andere dann in den VMs.
Die System VMDKs liegen auf den SSDs, alle anderen Daten auf dem Host. SMB Freigabe auf dem Host angelegt und innerhalb der VMs wird über ein extra Hostonly Netz darauf zugegriffen. Laut iperf gehen da auch 5-6Gbit drüber, also limitieren nur die 4TB Platten. Trägt man in den Konfigdateien statt dem e1000 den vmxnet3 manuell ein und installiert die Tools, dann gibts auch vmxnet3 in der VM Workstation.

Ich bin leider auch noch nicht weiter gekommen, habe jetzt auch mal die P19 Firmware geflasht, hat aber nicht geholfen. Dass aber die Leistung so einbricht selbst im Passthrough kann ja nicht normal sein.
Dieses Board benutzen ja doch einige, zumindest liest man häufig in Englischsprachigen Foren davon, offenbar haben die Leute keine Probleme.
Keine Ahnung was ich da falsch mache. :(:(
 
wie gesagt, in der VM sind die CPU-PCIe Lanes ja nicht direkt am Controller verfügbar, Du hast hier einfach noch eine weitere Zwischenschicht.

VMware Workstation kostet aber Geld - der VMware Player ist kostenlos, genauso der ESXi...

Ich habe 2 getrennte Systeme, sprich ESXi (headless) und Storage - der neue bekommt zwar Platten, aber diesen hohen Durchsatz brauch ich dann doch nicht... - Es kommt halt immer darauf an, was man mit dem System machen will...
 
Hmmm... also ich habe ja auch einen LSI-Controller (Dell h200) an meine Storage-VM (Solaris 11.3) per Passthrough durchgereicht.

Damit Du mal erste Vergleichswerte hast:

Alle Tests zwischen VMs auf gleichem Host durchgeführt, also Win10-VM auf Storage-VM, Flaschenhals also jedenfalls nicht ein physisches Netzwerk.

CDM auf 8x4TB HDD Pool im RaidZ2 (keine Verschlüsselung, keine Kompression, Füllstand Pool bei 93%!, Sync: Standard):
00_CDM512x64_8x4TB_RaidZ2.jpg
CDM auf 2x120GB SSD Pool im Raid-Mirror (keine Verschlüsselung, keine Kompression, Füllstand Pool bei 0%, Sync: Standard):
01_CDM512x64_2x120GB_RaidMirror.jpg
CDM auf 2x120GB SSD Pool im Raid-Mirror (keine Verschlüsselung, keine Kompression, Füllstand Pool bei 0%, Sync: Disabled):
02_CDM512x64_2x120GB_RaidMirror_SyncDIS.jpg
Kopiervorgang HDD-Pool auf SSD-Pool (schwankt zwischen 200-320MB/s:
03_HDD_zu_SSD.jpg
Kopiervorgang SSD-Pool auf HDD-Pool (jetzt 4x4TB wg. 93% Füllstand des anderen Pools):
04_SSD_zu_HDD.jpg
Dann nochmal mit den SSD im Raid0 (basic):
05_CMD512x64_2x120GB_Basic.jpg 06_HDD_zu_SSD_Basic.jpg

Hab grad noch gesehen, dass die CPU-Last in der VM auf Maximum ist:
07_VM-Auslastung.jpg
Gebe der bei Interesse / auf Wunsch gerne mal noch 2 Kerne mehr.
 
wie gesagt, in der VM sind die CPU-PCIe Lanes ja nicht direkt am Controller verfügbar, Du hast hier einfach noch eine weitere Zwischenschicht.

VMware Workstation kostet aber Geld - der VMware Player ist kostenlos, genauso der ESXi...

Ich habe 2 getrennte Systeme, sprich ESXi (headless) und Storage - der neue bekommt zwar Platten, aber diesen hohen Durchsatz brauch ich dann doch nicht... - Es kommt halt immer darauf an, was man mit dem System machen will...

EVALEXPERIENCE aka VMUG Member Plus Advantage heißt das Zauberwort:

EVALExperience


beinhaltet:


VMware vCenter Server v6.x Standard
VMware vSphere® ESXi Enterprise Plus with Operations Management™ (6 CPU licenses) = bis zu 6 Server
VMware vCloud Suite® Standard
VMware vRealize Operations™
VMware vRealize Log Insight™
VMware vRealize Operations for Horizon®
VMware Horizon® Advanced Edition
VMware vSAN™
VMware Workstation Pro 14
VMware Fusion Pro 10
VMware NSX Enterprise Edition (6 CPU licenses)
VMware vRealize Network Insight
VMware vRealize Automation 7.3 Enterprise



kostet ohne Coupons (und da gibts massig immer, grad zu Messen):

VMUG Member + Advantage Single User Subscription - $200 USD
VMUG Member + Advantage Single User Subscription (2 years) - $360 USD
VMUG Member + Advantage Single User Subscription (3 years) - $510 USD

davon gehen je nach coupons von 10% bis zu teils 40% (sehr selten) ab :) und natürlich in Dollar (atm 1,20:1)
 
Zuletzt bearbeitet:
Wie kommt es, dass im SSD Pool mit Sync Writes die ausgerechnet schneller sind ? Müsste durch das Warten auf die Bestädigung des erfolgreichen Schreibens, das nicht sogar einbrechen ?
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh