ESX / ESXi - Hilfethread

Da gibt's so schöne Suchmaschinen, die man z.B. mit ESXi + Treiber + installieren füttern könnte und die dann u.a. diesen Artikel in der VMWare Knowledgebase ausspucken. ;)
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ich frage mich die ganze Zeit ob das wohl Sinn macht ESX ohne Raid Controller zu verwenden. Das ganze ist nur ein Homeserver und sollte möglichst wenig verbrauchen.
Also einfach Datastore auf jeder Disk erzeugen und dann darauf z.B. mit einer Linux VM ein Software RAID1 erstellen.
 
Mein Ziel ist nicht zwingend Audio über RDP.

Ich will nur ein Windows 7 Pro virtuell einschließlich Audio support auf dem ESXI aufsetzen. Wie der Zugriff auf die VM erfolgt ist dem Benutzer egal.
Wenn Audio mit ESXI aber gar nicht ruckelfrei geht,dann stelle ich meine Fragen hier ein. Googlesuche brachte mir bisher keine Antwort, also weder ja noch nein.

Ich habe hier einen USB Sound Stick an eine Windows 7 VM unter ESXi 5.1 durchgereicht. Winamp läuft einwandfrei und gibt den Sound stotterfrei an einen Verstärker aus.

Hardware:
Sound Stick TerraTec Aureon Dual USB (10542) Preisvergleich | Geizhals Deutschland
Mainboard Intel DQ67SW, Q67 (B3) (dual PC3-10667U DDR3) (BOXDQ67SWB3) Preisvergleich | Geizhals Deutschland
 
Ich habe hier einen USB Sound Stick an eine Windows 7 VM unter ESXi 5.1 durchgereicht. Winamp läuft einwandfrei und gibt den Sound stotterfrei an einen Verstärker aus.
Dann bitte nochmal für einen ESXI-Anfänger. Sound scheint hier auch nicht jeder hier zu nutzen, was natürlich nicht zu einer Server-VM gehört.

Steckt die Audiohardware (Dein USB Sound Stick) im ESXI Server, im Sphere-Client oder RDP-Client?
Und wo konfigurierst Du im Sphere-Client das "durchreichen" der Sound-Hardware?

triangle
 
Einfach in der VM bei den virtuellen Geräten einen USB Controller hinzufügen. Dann siehst du die USB Geräte die im ESX stecken, in der VM.
 
Ich frage mich die ganze Zeit ob das wohl Sinn macht ESX ohne Raid Controller zu verwenden. Das ganze ist nur ein Homeserver und sollte möglichst wenig verbrauchen.
Also einfach Datastore auf jeder Disk erzeugen und dann darauf z.B. mit einer Linux VM ein Software RAID1 erstellen.

Der Frage schließe ich mich an, weil das gleiche geht mir auch durch den Kopf.

Und als absoluter Anfänger noch eine Frage: Wenn ich auf der VM 1 FreeNAS laufen lasse, alle SATA Platten durchreiche und ein Software-Raid erstelle, kann ich dann in der VM 2 (bspw. WHS 2011) darauf zugreifen? Wenn ja, wie? Als normales Netzwerklaufwerk oder steht mir das dann sogar als gewöhnliches Laufwerk zur Verfügung?
 
Habe ein sehr merkwürdiges Problem:
Ich habe in meinem ESXi (leider nur) 4 GB RAM verbaut.
Wenn ich alle anderen VMs aushabe, kann ich eine erstellen, bei der 3 GB RAM zugeteilt sind.
Sobald ich aber über PCI-Passthrough meinen LSI SAS 3041E-R hinzufüge kommt folgende Fehlermeldung
Das Einschalten der VM ist fehlgeschlagen.
Die virtuelle Maschine konnte nicht eingeschaltet werden: Zugangsprüfung fehlgeschlagen für Arbeitsspeicherressource Weitere Informationen zu den Ressourcenverwaltungseinstellungen finden Sie im Handbuch zur VMware ESX-Ressourcenverwaltung.
Gruppe vm.4408: Ungültige Parameter für die Arbeitsspeicherreservierung angefordert für VM vmm0:storage2. (Min.: 786432, Max.: -1, minLimit: -1, Anteile: -1, Einheiten: pages)
Gruppe vm.4408: Kein Zugang für VM: Arbeitsspeicher-Zugangsprüfung fehlgeschlagen. Angefordertes Minimum: 797930 pages
SharedArea: 'testSharedAreaPtr' wurde in Bereich SHARED_PER_VM_VMX nicht gefunden.
Ich muss den zugeteilten Arbeitsspeicher auf etwa 1,5 GB verringern, damit die VM startet.
Kann mir jemand helfen?

Edit:
gerade gelesen:
VMware KB: Configuring VMDirectPath I/O pass-through devices on an ESX/ESXi host
"When the device is assigned, the virtual machine must have a memory reservation for the full configured memory size."
Das kann man nicht irgendwie umgehen? Verstehe ich das richtig, dass die VM wo etwas durchgereicht ist eigentlich doppelt so viel RAM benötigt?
 
Zuletzt bearbeitet:
Wenn etwas an die VM durchgereicht wird dann muss der RAM der in der Maschine konfiguriert ist auch zu 100% reserviert werden. Da führt afaik kein Weg dran vorbei.

Das du nur 1,5GB nutzen kannst (bzw. es nur dann startet) setzt sich wahrscheinlich so zusammen:
- Wahrscheinlich nur 3,2GB statt 4GB nutzbar (je nach Board)
- 3,2 - Speicherbedarf ESXi = X
- X - Speicher-Overhead deiner virtuellen Maschine = Y

Und Y dürfte dann scheinbar in deinem Fall bei ~1,5GB liegen.

Also ich hatte 8GB bei einer VM an die auch was durchgereicht war und noch ne andere VM und es waren 12GB im Server verbaut. Das ging
 
Also das Board erkennt schon die vollen 4GB.
Könnt ihr mir das erklären? esxi3.jpg
Edit:
Bei Übersicht steht auch 4 GB
 
Zuletzt bearbeitet:
Und als absoluter Anfänger noch eine Frage: Wenn ich auf der VM 1 FreeNAS laufen lasse, alle SATA Platten durchreiche und ein Software-Raid erstelle, kann ich dann in der VM 2 (bspw. WHS 2011) darauf zugreifen? Wenn ja, wie? Als normales Netzwerklaufwerk oder steht mir das dann sogar als gewöhnliches Laufwerk zur Verfügung?

Also 1:1 durchreichen ohne Zwischenlayer geht nur mit vt-d oder IOMMU, wobei man da glaube ich den ganzen Controller an die VM weiterreicht per Passthrough. Man kann aber auf jeder Platte einen Datastore mit VMFS erstellen und darin ein VMDK File. Im OS sieht man dann dieses VMDK einfach als Disk und kann ein Software RAID erstellen.

Die Quizfrage ist nur, wieviel Geschwindigkeit verliert man dadurch. Es gäbe noch RDM aber da hat man glaube ich auch keinen Geschwindigkeitsvorteil gegenüber VMFS.
Laut hier ist es wohl vernachlässigbar:
http://www.windowspro.de/wolfgang-s...s-vmfs-resource-pools-cbt-paravirtualisierung

Wenn du mit WHS auf Freenas zugreifen willst, dann geht das z.B. mit CIFS oder iSCSI
 
Zuletzt bearbeitet:
Vielleicht kann mir ja einer von euch einen Tip geben. Ich hab nen ESXi 5.1 komplett neu installiert. Hardware: PowerEdge 840
Beim installieren und auch beim starten hängt die Kiste 10min bei modul pata_sil680

Hat irgendjemand ne Idee wie ich das gelöst bekomme?

ESXi ist auf einer SAS Platte installiert und dann hab ich noch einen Datastore über ein RAID5 (Perc5i).
 
Hallo zusammen.
Ich habe mal wieder eine Frage zu ESXi.

Wenn ich ein Server mit 32GB RAM habe...dem einen System 32GB zuweise, kann ich dann einem zweiten System trotzdem 8GB zuweisen, oder sollte ich dann der VM1 24GB und der VM2 dann 8GB zuweisen?


Danke und Grüße
 
@MarV8501
PATA Controller im Bios deaktivieren oder auf AHCI stellen
@LaMagra-X
Bei ESX gibt es Memory Sharing, man kann mehreren VMs mehr zuweisen als der Host insgesamt hat. Das Sharing funktioniert aber nur wenn das Gast OS gleich ist. Jedoch nimmt sich das Gast nur den Teil den er braucht, wodurch man auch Overprovisioning machen kann. Entscheidend ist der Gesamtverbrauch. Ich glaube aber nicht das eine VM bei dir wirklich 32GB braucht.
 
Also eine VM ist ein Server 2012 mit Exchange-Rolle. Die zweite VM ein schnödes Windows 7, was jedoch mindestens 8GB benötigt, weil es Datev hosten soll.

Der Exchange kann sehr wohl gut 32GB verwenden...wenngleich er auch mit weniger läuft.
 
Windows kann immer mehr Speicher verwenden ob es sinnvoll ist dann was anderes , wir haben hier nur 8-16 GB bei unseren Exchange Server und ca 900 Postfächer und es läuft alles rund.
 
Zuletzt bearbeitet:
Ja, das stimmt sicher was du sagst.

Grundsätzlich wollte ich eben nur wissen, ob es nagative Auswirkungen hat, wenn man mehr virtuellen Speicher (in der Summe) verteilt, als tatsächlich vorhanden.

Wenn ich das richtig verstanden habe ist es demnach kein Problem.
 
Solange die Server den Speicher nicht wirklich brauchen ist es kein Problem.
 
Und sonst swapt er auf die (im Vergleich) lahmen Platten und da machts dann wenig Spaß...
 
Grundsätzlich wollte ich eben nur wissen, ob es nagative Auswirkungen hat, wenn man mehr virtuellen Speicher (in der Summe) verteilt, als tatsächlich vorhanden.
Da sich Exchange standardmäßig alles an RAM greift, was das darunterliegende System zur Verfügung stellt, wird es in deinem Falle besser sein, der Exchange-Maschine maximal 24 GB zu geben, damit der ESXi nicht auslagern muss.
 
Bei ESX gibt es Memory Sharing, man kann mehreren VMs mehr zuweisen als der Host insgesamt hat. Das Sharing funktioniert aber nur wenn das Gast OS gleich ist. Jedoch nimmt sich das Gast nur den Teil den er braucht, wodurch man auch Overprovisioning machen kann. Entscheidend ist der Gesamtverbrauch. Ich glaube aber nicht das eine VM bei dir wirklich 32GB braucht.

Das kann man so nicht sagen...
Der ESX kann nicht unterscheiden, was da wie wann wer an RAM wirklich benötigt. Zumindest nicht wirklich effektiv.
Es ist somit absolut nicht zu empfehlen, mehr RAM zuzuteilen, als auch vorhanden ist. Speziel trifft diese Empfehlung dort zu, wo man mit OSen arbeitet, die intelligenterweise den RAM als Filecache nutzen. Was mittlerweile im *nix/Windows Bereich gang und gebe ist. Laufen die Kisten dauerhaft (also 24/7) kommt es sehr schnell vor, das ungenutzter RAM als Filecache in der VM belegt wird. Somit wird der ESX Host gezwungen, der VM auch all diesen RAM zu geben.
Kommt es nun zu einem Engpass, weil mehr RAM ausgeteilt wird, als vorhanden ist, wird der ESX Host anfangen zu swappen. Und das lässt die Performance extremst in den Keller schnellen.
Auch kommt hinzu, das der ESX Host nicht wie das VM OS selbst intelligent den Speicher auslagern kann. Da er nicht weis (entgegen dem OS in der VM), welche Daten im Zugriff sind und wie sich das Zugriffsmuster verhällt.

Zusammengefasst, bei Gast OSen mit RAM Cache und/oder Diensten, die allen RAM auch belegen wollen (Exchange, SQL usw.) ist ein überbuchen der Performancetod!

Ja, das stimmt sicher was du sagst.

Grundsätzlich wollte ich eben nur wissen, ob es nagative Auswirkungen hat, wenn man mehr virtuellen Speicher (in der Summe) verteilt, als tatsächlich vorhanden.

Wenn ich das richtig verstanden habe ist es demnach kein Problem.

Siehe oben, mach es nicht...

Ich gehe sogar soweit, das 24+8 zwar 32GB sind. Aber du vergisst, auch der Host will etwas RAM für sich (~1GB)
Dazu kommt, die VMs selbst benötigen Hostseitig immer etwas mehr physischen RAM als man ihr zuteilt. So hat ne 8GB Maschine also vllt 8,5-9GB physisch in Benutzung, wenn sie ihren zugeteilten RAM auch ausnutzen kann. Du überbuchst also mit 8+24GB + Host + das, was noch oben drauf kommt, schon den Host. -> klar nicht zu empfehlen.

Den RAM zu überbuchen macht genau dort Sinn, wo du steuern kannst, wer wann wie viel RAM benötigt.
Beispielsweise kann es je nach Anforderung an die VMs vorkommen, dass in Stoßzeiten mehr RAM benötigt wird. In einem starren Konstrukt muss du hier also den zugeteilten virtuellen RAM an diesen Stoßzeiten messen.
Es würde sich also anbieten, hier in den Stoßzeiten zu überbuchen, wenn sicher gestellt ist, das in den Stoßzeiten beispielsweise andere Systeme weniger als üblich an RAM vertilgen.
Leider ist mittlerweile diese Steuerung so ohne weiteres nicht mehr machbar. Stichwort wie oben, Filecache. Oder Dienste, die den RAM auch vollknallen, den es gibt.

Meine Empfehlung wäre hier, Exchange mit 16GB + 8GB für die Windows 7 Kiste. Der Rest als Luft für später.
Je nach Anforderungen an den Exchange geht das schon sehr gut. Vor allem ist es oftmals durchaus vertretbar, wenn der Exchange beim Browsen riesiger Postfächer mal ne Gedenksekunde benötigt, weil dies idR nicht das typische Nutzerverhalten ist. Der reine Exchangebetrieb wird dabei nämlich idR nicht wirklich beeinträchtigt.
 
Es ist somit absolut nicht zu empfehlen, mehr RAM zuzuteilen, als auch vorhanden ist.

Das ist gängige Praxis wenn man viele VMs hat und dann auch noch ein Cluster mit DRS vorhanden ist wo man noch einiges an Reserven hat. Alleine schon durch Memory Sharing ist es gar nicht möglich das die Maschinen das brauchen was ihnen zugewiesen ist. Wenn man dann z.B. 30 VMs mit identischem OS auf einem Host hat, sieht man das richtig schön.
Da gilt es natürlich ein Auge drauf zu haben wie hoch der tatsächliche Verbrauch ist. Gut, hier bei den 2 VMs ist das weniger von belang und ich würde es auch nicht empfehlen.
Exchange oder SQL ist natürlich ein Sonderfall aber es gibt ja auch noch mehr als das.
 
Die aktuelle Frage war aber spezifisch daraufhin gestellt, dass auf einem Host genau zwei Maschinen laufen, nämlich eine Exchange-Maschine unter Windows 2012 und eine Windows 7-Maschine, die auch die 8 GB RAM benötigt, die ihr zugewiesen werden soll.

Natürlich ist das bei vielen Hosts mit vielen gleichartigen virtuellen Maschinen durchaus ein Faktor, der den RAM-Bedarf drückt, aber nicht in diesem Fall.
 
Wie viele User hängen an dem Exchange ?

Wir haben hier 550 und insgesamt ca 900 Postfächer und der Exchange hat nur 16 GB und läuft einwandfrei :)
 
Kommt aber auch ein bisschen drauf an wie der Exchange genutzt wird. In meinem damaligen Ausbildungsbetrieb gab es für die Postfächer keine Größenbeschränkung. Da waren durchaus Postfächer mit 20GB dabei. In meinem letzten Job warens dann 150MB pro Mitarbeiter, rest musste in PSTs archivhiert werden (wovon dann manche Leute ~30 Stück a 2GB hatten)

Alleine die Anzahl der Postfächer machts m.M. nach nicht aus, man sollte auch evtl. Größenlimits mit bedenken
 
*hust*

300MB - 4GB Postfächer alles dabei :)

Ich tippe aber mal das es keine große Firma ist weil sonst nicht so oft Fragen zu ESXi hier kommen würden *grins*
 
Sooo groß war mein Ausbildungsbetrieb auch nicht (ca. 50 MA) - wir hatten aber trotzdem ~400GB an Postfächern und mit 2 Leuten in der EDV und einem Azubi sicherlich auch keine Vmware Experten ;)

Lief aber auch mit 16GB Ram, so ist das ja nicht :p
 
Das ist gängige Praxis wenn man viele VMs hat und dann auch noch ein Cluster mit DRS vorhanden ist wo man noch einiges an Reserven hat. Alleine schon durch Memory Sharing ist es gar nicht möglich das die Maschinen das brauchen was ihnen zugewiesen ist. Wenn man dann z.B. 30 VMs mit identischem OS auf einem Host hat, sieht man das richtig schön.

Damit wiedersprichst du dir selbst ;)
Entweder man überbucht... Oder man hat Reserven. Hat man Reserven, überbucht man schlicht nicht.

Und das Memory Sharing Feature kannst du getrost in die Tonne treten. Speziell bei heutigen OSen. Denn wie angesprochen ist der mit abstand meiste Platzbedarf neben den reinen (Zusatz)Diensten allein vom OS in der VM her der, der durch Diskcaching hervorgerufen wird. Teilst du 4GB jeweils sagen wir 10 VMs zu, hast du nach einiger Zeit 40GB+ RAM Verbrauch auf dem Host -> Fakt!
Teilst du nun diesen 10 VMs aber unsinnigerweise 8GB pro VM zu, hast du schlicht nach einiger Zeit den doppelten Bedarf am Host -> ebenso Fakt!
Hat der Host dabei aber nur 64GB physisch, fängt der Host an, zu swappen. Man sieht beispielsweise auch den Balooningwert massiv steigen. Die Performance geht extrem in den Keller und das überbuchen ist dabei der Performancetod für die ganze Umgebung.
Schlimmer noch, die Kommunikation zwischen Gast OS und Host ist bestenfalls als minimal einzustufen. Denn das Gast OS sieht die zugewiesenen 8GB, sieht aber nicht, das der Host unter der Decke diese virtuellen 8GB ggf. swappt. Es kann somit nicht unterscheiden, ob von den zugewiesenen 8GB auch wirklich 8GB im physischen RAM Platz finden, oder ein Teil davon im Swapbereich des Hosts unterkommen. Durch das fehlende Wissen auch auf Hostebene wird es also vorkommen, das für den Betrieb der Gast VM essentiel wichtige Teile im lahmen Swapbereich unterkommen -> was die Performance extremst in den Keller zieht.
Dies geht idR auf die HDDs vom Storage. Welche wiederum sinnigerweise mit anderen VMs geshared genutzt werden -> mit den negativen Effekt, das die Storageperformance auch andere VMs in den Keller sinkt. Bei RAM Knappheit werden ohne Nutzung von Reservierungen/Priorisierungen eiskalt alle VMs gleich betrachtet. Somit verstärkt sich der Negativeffekt auch mit der Anzahl der VMs.

Und was willst du hier mit DRS? Mit DRS in einem Cluster ändert sich am Verhalten absolut gar nichts. Es gibt dann halt mindestens zwei Hosts. Der physische RAM wird addiert. Das Verhalten bleibt identisch.

PS: wie sich sowas zeigt, sieht man hier:
Unbenannt.JPG

Also erzählt mir nix von wegen, "ist es gar nicht möglich das die Maschinen das brauchen was ihnen zugewiesen ist"... Denn das ist schlicht und ergreifend Falsch! Denn wie man sieht, nahezu alle Maschinen benötigen (bis auf zwei drei Außnahmen, die vor kurzem gebootet wurden, oder so fast gar nix machen) benötigen mindestens so viel RAM am Host direkt, wie ihnen auch zugewiesen ist.
 
Erstmal vielen Dank für euren ganzen Antworten.

Ich kann jetzt nicht auf alle Aussagen eingehen.

Also wenn ich das richtig verstanden habe, ist das im Grunde eher kein Problem, nur für arbeitsspeicherintensive Geschichten wie z.B. Exchange oder SQL Server sollte man dann doch auf Nummer sicher gehen.

Heißt ich gebe meiner Exchange VM weniger RAM.

Bekomme ich da Probleme mit dem Server 2012 wenn ich die VM herunterfahre, RAM verkleiner und wieder hochfahre?

Einen physikalischen SBS2011 habe ich durch solche eine Maßnahme nämlich schon mal "getötet".


VG
 
da passiert nix...

Und dem SBS2011 idR auch nicht ;) da muss was anderes schief gelaufen sein...
Ich drehe alle Nase lang bei meinem SBS2011 den RAM hoch und runter :fresse:


Wie angesprochen, Problem ist rellativ, da das Geschwindigkeitsempfinden von jedem anders ausfällt. Es fällt schlicht extrem auf, selbst bei kleinst VMs, wenn dehnen der RAM nicht bereitgestellt werden kann. Das heist nicht, das es nicht ggf. irgendwie mit biegen und brechen geht.
Gnadenlos den RAM überbuchen ist auch nicht das Konzept der Virtualisierung. ;) Da gehts eher darum, möglichst die Ressourcen effizient zu nutzen anstatt mehr zu wollen, als physisch überhaupt drin steckt ;)
 
Also habe es gemacht...Exchange hat nun 16/32...Datev 8/32...Rest bleit frei.

Gleich die nächste Frage *wegduck*:

Wie verhält sich das bei den CPU Cores? :fresse:


EDIT:
Der Exchange mit dem halbierten RAM läuft spürbar kein bisschen langsamer...
 
Zuletzt bearbeitet:
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