ESX / ESXi - Hilfethread

Entweder sind die Xeon echt mies beim AES-NI oder es geht über den ESXi viel von der Hardwarebeschleunigung verloren...
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Hallo Leute.
Ich bräuchte von euch mal einen Rat zum Thema Backup Strategie.
Wir haben nun das VMWare Essential Kit (3 Hosts) sowie Veeam Backup & Replication (Version 7). Alle 3 Hosts werden nun komplett auf den vierten physischen Backupserver (Server 2012) gesichert. Zusätzlich laufen diese gesicherten Daten noch auf externe Datenträger.
Nun wollte ich ursprünglich den Backupserver über Windows Sicherung auf eine NAS sichern. Das habe ich aber aufgrund der Möglichkeiten und des Platzbedarfs aber eigentlich wieder verworfen.

Wie sollte man nun den Backupserver (der VM Hosts) sichern?

VG
 
Ich kann nur über Commvault Simpana berichten, aber da sollte man die virtuelle Maschine, welche man im worst Case zur Wiederherstellung aller Hosts benötigt zumindest mal auf eine USB Platte kopieren und in einem anderen Brandbereich ablegen.
Und ansonsten kann man den Server eigentlich ganz normal mitsichern (oder es lassen - je nachdem).

Im schlimmsten Fall muss man dann seine USB Platte nehmen, die VM irgendwo anschmeißen und kann von da aus alle Backups zurückspielen. Das halte ich zunächst mal für die günstigste Lösung, die garnicht mal so schlecht ist.
 
Zuletzt bearbeitet:
Die gesamten VMs (vmdk, etc.) werden ja täglich über Veeam auf den Backupserver gesichert und von dort aus (ebenfalls täglich) auf eine externe Platte geschrieben. Das ist also abgedeckt. Die Frage ist eben nur wie ich den Windows-Backupserver am besten sichere. Denn der kann ja auch ausfallen.

VG
 
Über die Windows Server-Sicherung. Es brauchen ja nur die Systempartition und der Systemstatus gesichert zu werden, die Datenpartitionen (wo die Backups der virtuellen Maschinen gespeichert sind) werden ja separat gesichert.
 
Stimmt eigentlich. Denke dann werde ich es doch über die Windows Server Sicherung machen.

Danke und viele Grüße!
 
Mal so in den Raum geworfen: Hat jemand mal den Stromverbrauch verschiedener Hypervisor gegeneinander getestet? Ich habe gerade Proxmox (1 HDD, 1x Sophos UTM VM) gegen ESXi (1 HDD, 1 SD-Card, 1x Sophos UTM VM) getestet und Proxmox liegt im Schnitt 5 Watt unter ESXI. Dies ist keine Langzeitmessung und wurde ohne​ profesionelles Equipment durchgeführt.

Habt ihr mal ähnliche Tests gemacht?
 
Was war den beim ESXi im Power Management eingestellt? Aber selbstverständlich kann und wird da immer ein Unterschied sein.
 
Oh die Einstellung kannte ich noch gar nicht. Die steht auf "Balanced". Ich teste bei Gelegenheit mal "Low power". Aber wirklich nennenswert sind die 5 Watt im idle mit nur einer VM meiner Meinung nach nicht.
 
Naja da wird immer ein Unterschied sein. Jedes Betriebssystem ist anders. Installiere dir ein Linux mit Desktop und ein Windows, da wird auch immer ein Unterschied sein.
 
Ich habe leider ein ärgerliches Problem unter ESXii 5.5.

Ich habe vier WD RED HDDs per RDM an OpenMediaVault durch gereicht. Funktioniert auch soweit ganz gut, also Performance ist ok, SMART geht auch. Manueller Spindown auch und automatischer, bei Idle bis 30 Minuten.

Und das ist dann auch schon mein Problem. Wenn ich den automatischen Spin Down auf 30 oder 60 Minuten stelle, dann funktioniert es nicht. Beim ESXi gibt es also irgendetwas, dass alle 30 Minuten oder so auf die HDDs zugreift.
Ich habe leider keine Ahnung, wo ich da ansetzen soll, also welche Einstellung geändert werden muss.

Das mit dem Spin Down ist insofern wichtig für mich, als dass ich damit ca. 20 Watt sparen kann und das macht bei 24/7 doch einiges aus.
 
Manueller Spindown auch und automatischer, bei Idle bis 30 Minuten.

Wenn ich den automatischen Spin Down auf 30 oder 60 Minuten stelle, dann funktioniert es nicht.

Funzt es jetzt manuell und mit 30 Minuten oder nicht? :)

hdparm -y /dev/sdaX geht?
 
Manuell geht, also mit hdparm -y /dev/sda.
Automatisch auch, aber nur bei 10 oder 20 Minuten Idle bis Spindown.
Wenn ich zB zwei Stunden einstelle, die die HDD idlen soll, bevor der Spindown stattfindet, dann passiert genau gar nichts :d
 
Frage an die Profis:

vSphere 5.5 Documentation Center

Bisher war ich immer der Meinung, dass die Unterscheidung zwischen vCPU Cores und vCPU Sockets nur lizenztechnische Unterschiede hat, sprich für Software gedacht ist die auf Sockets lizensiert ist und das GuestOS deswegen auch zwei Sockets "sehen" muss.

Der Artiekl in den Pubs ließt sich aber für mich irgendwie ein bisschen so, als ob das auch Performance technische Unterschiede macht - ist dem so oder ist der Artikel einfach nicht ausführlich genug beschrieben? oO

Gruß
 
Hmm, auch nach zweimal lesen finde ich nicht wo du rausliest, dass es einen Performance Unterschied gibt?
 
## Nachdem im anderen Thread keine Reaktion auf meinen Post kam, versuche ich es mal hier, sorry wenn ich hier fehl am Platz bin. Der andere Thread ist anscheinend nicht so aktiv. ###

Hallo zusammen,

ich möchte mir einen kleinen Homeserver zusammenbasteln und dafür ESXi verwenden.

Da es ungefähr 9 Millionen verschiedene Konfigurationen dazu gibt, würde ich mich freuen, wenn mir jemand eine paar Infos zu Hardware geben könnte, die ich brauchen würde.
Ich hätte ein Budget bis so ca. 500 Euro. Wenn meine Vorstellung dazu übertrieben sind, bitte macht mich darauf aufmerksam ;-)

Folgende Anforderungen hätte ich:

-Größe nicht so wichtig (Klein wäre fein)
-Es MUSS nahezu lautlos sein (sofern möglich, also es steht im Wohnzimmer und sollte möglichst nicht wahrnehmbar sein)
-3-4 VMs sollten schon laufen (FreeNas, IPFire, Spiel / Test VMs) [Denke mal min 16 GB RAM?]
-Genug Speicher für Datenablage (3x2 TB im Raid5?)
-min. 2 LAN Schnittstellen (Egal ob intern oder Zusatzkarte)
-Eventl XMBC, Fernseh mit HDMI ist in der nähe vorhanden
-Da 24/7 Betrieb vorgesehen ist, wäre ein möglichst geringer Stromverbrauch auch wichtig

Das ist eigentlich schon mein Hauptanliegen.

Meint ihr das liegt im Budget?
Könnt ihr mir passende HW empfehlen? Ich nehme auch gerne Gehäuseempfehlungen entgegen.

Ich hoffe ich bin hier im richtigen Unterforum...

Danke für alle Infos!
 
Wir sind @work jetzt vom ESX 4.0 auf ESXi 5.1 umgestiegen.
Wie funktioniert denn jetzt das mit dem iSCSI Multipathing korrekt?
Im 4.0 hat man ja noch beim vmKernel Port in der Netzwerkconfig den Haken gesetzt dass er auch als iSCSI agiert.
Beim 5.1 hat man diese Möglichkeit nicht mehr, man kann aber (iSCSI arbeitet grundsätzlich aber auch ohne dass man das macht, so der aktuelle Konfigurationsstand bei uns) im iSCSI Adapter einen VMKernel Port zuweisen (oder mehrere) der aber jeweils nur einer physischen NIC zugeordnet sein darf.

Heißt das im Klartext ich müsste um iSCSI nach VMWare Denke korrekt zu betreiben mehrere VMKernel Ports für iSCSI erstellen mit jeweils unterschiedlichen IPs und jeweils an nur eine NIC gebunden?
Was bringt mir das gegenüber der alten Variante mit nur einem VMKernel Port mit mehreren zugewiesenen aktiven NICs für Vorteile?
 
Hmm, auch nach zweimal lesen finde ich nicht wo du rausliest, dass es einen Performance Unterschied gibt?

This capability lets operating systems with socket restrictions use more of the host CPU's cores, which increases overall performance.
Using multicore virtual CPUs can be useful when you run operating systems or applications that can take advantage of only a limited number of CPU sockets.

vllt interpretier ich aber auch zuviel rein und es ist, wie schon gesagt, nur eine lizenztechnische Angelegenheit :rolleyes:
 
Frage in die Runde.

Kennt jemand eine USB PCi-E Karte welche man auch unter esxi 5.5 an die VM durchschleifen kann?
Mit der "HighPoint RU1144A kann man dies, jedoch liegt sie nicht in meinem Preisrahmen für meine Verwendungszwecke.
 
vllt interpretier ich aber auch zuviel rein und es ist, wie schon gesagt, nur eine lizenztechnische Angelegenheit :rolleyes:

Ja das tust du, es ist aber nicht nur Lizenztechnik. Windows XP Home zum Beispiel kann nur 1 Socket, XP Pro kann 2 Sockets. Cores können sie aber jeweils mehr. Windows 7 kann ab Pro Mutli-CPU (2 Sockets) aber in jeder Version unlimited Cores. Heisst also ich könnte die 64 Threads (Cores) von unseren DL580 an eine Windows 7 Home Premium VM weiterreichen über 1 Socket mit 64 Cores. Und das ist eine 4 CPU Maschine ;)

Und der erwähnte Performance Gewinn erklärt sich halt dadurch, dass die Applikation die mehr Cores aber nur 1 Socket benutzen kann durch die 1 CPU mit 64 Cores entsprechend 64 Cores benutzen kann statt "nur" 16 wenn Sie nur 1 Socket CPU nutzen könnte.
 
Zuletzt bearbeitet:
Wahrscheinlich eine totale Anfängerfrage: Kann ich meine Festplatte auf die der DataStore liegt ohne Weiteres an einem anderen SATA Controller anschließen, oder bringe ich damit das ESXi durcheinander?

Danke für die Hilfe.
 
Ja das tust du, es ist aber nicht nur Lizenztechnik. Windows XP Home zum Beispiel kann nur 1 Socket, XP Pro kann 2 Sockets. Cores können sie aber jeweils mehr. Windows 7 kann ab Pro Mutli-CPU (2 Sockets) aber in jeder Version unlimited Cores. Heisst also ich könnte die 64 Threads (Cores) von unseren DL580 an eine Windows 7 Home Premium VM weiterreichen über 1 Socket mit 64 Cores. Und das ist eine 4 CPU Maschine ;)

Und der erwähnte Performance Gewinn erklärt sich halt dadurch, dass die Applikation die mehr Cores aber nur 1 Socket benutzen kann durch die 1 CPU mit 64 Cores entsprechend 64 Cores benutzen kann statt "nur" 16 wenn Sie nur 1 Socket CPU nutzen könnte.

Danke ;)
Heißt das, dass es früher(ESXi3/4??) so war, das eine VM max soviele Cores per Socket haben konnte wie der Host und nun kann ich alle Cores aller Sockets (des Hosts) auf beliebig viele vSockets im GuestOS verteilen?

Sprich früher
Host - 2 Sockets - 12 Cores
Guest OS <= 6 Cores = 1 Socket
Guest OS > 6 Cores = 2 Sockets

Heute
Host - 2 Sockets - 12Cores
Guest OS <= 6 Cores = 1 Socket
Guest OS > 6 Cores = 1 Sockets (wenn gewollt)

SMP ist aber wieder was anderes, oder? Sprich früher war es garnicht möglich mehr Cores als die eines Sockets einer VM zuzuweisen und mit SMP ging das dann, richtig?
http://www.vmware.com/files/de/pdf/vsmp_datasheet_de.pdf
 
Kennt jemand folgende Problematik?

Esxi 5.5 mit IBM 1015 geflasht auf LSI und per Passtrough an eine Windows 2012 R2 VM -> lief einen Tag problemlos mit Konfiguriertem RAID1 mit 2 HDDs

Seit heute erhalte ich die Meldung "Gerät kann nicht gestartet werden" im Gerätemanager beim LSI....
 
hab mal irgend wo gelesen das der 5.5 mit bestimmten karten bei passtrough recht wählerisch sein soll, hab hier seit ca 3 wochen auch 2x 1015 allerdings unter 5.1 und läuft ohne probleme
 
Dann wird das ganze morgen einmal mit 5.1 getestet.

Danke für den Hinweis
 
Heißt das im Klartext ich müsste um iSCSI nach VMWare Denke korrekt zu betreiben mehrere VMKernel Ports für iSCSI erstellen mit jeweils unterschiedlichen IPs und jeweils an nur eine NIC gebunden?
Was bringt mir das gegenüber der alten Variante mit nur einem VMKernel Port mit mehreren zugewiesenen aktiven NICs für Vorteile?

Ja es scheint so, das VMware will, das man dort mit mehreren IPs arbeitet. Aber das hat wohl auch triviale Gründe, so bekommst du nämlich die Limitierung auf Ethernet Ebene schön umschifft. Wenn jeder Host mit zwei IPs von zwei Kernel Ports arbeitet, so hast du zumindest Switchseitig am Host erstmal kein Problem das ganze zu Bündeln. Der ESXi scheint wenn ich das richtig sehe beide Kernelports zu nutzen.
Was der Host nämlich selbst nicht kann, er spricht bei mehreren zugewiesenen NICs pro Portgruppe bzw. pro Kernelport immer nur mit einer NIC. Es gibt zwar ne Redundanz, wenn ein Link wegfällt, springt ein anderer ein, aber du bekommst kein Load Balancing auf der Ebene hin -> dafür müssen deine Switches die Kanäle bündeln können. Je nach Switch und Modell ist das aber gewissen Limitierungen in der Anzahl unterlegen ;) Simple Accessswitches können oft nur 4-8 dieser "Teams" bilden. Was halt sehr sehr wenig ist, wenn man da mit mehreren Hosts kommt. Zumindest für iSCSI unterbindest du den Spaß nämlich damit ziemlich simpel, indem einfach über mehrere IPs gesprochen wird. Das Storage sollte das ganze dann natürlich ebenso irgendwie können. -> je nachdem, was man dort verbaut hat.
Und das dürfte dann auch schon der Unterschied zur alten Lösung sein. AKtuell kannst du, soweit ich das bis jetzt im Einsatz hatte eben nur immer eine physische NIC angehangen im Kernelport für iSCSI nutzen. Für eine zweite NIC benötigt es dann einen zweiten Kernelport. Beide müssen dann im iSCSI Menü gekoppelt werden. Früher gingen wenn ich das recht in Erinnerung habe ein Kernelport auch mit mehreren NICs -> aber eben der Limitierung auf den Speed von einem Link, wenn man Switchseitig dort keine Teams bilden konnte.

Danke ;)
Heißt das, dass es früher(ESXi3/4??) so war, das eine VM max soviele Cores per Socket haben konnte wie der Host und nun kann ich alle Cores aller Sockets (des Hosts) auf beliebig viele vSockets im GuestOS verteilen?

Nein ;)
Es gab wenn man so will eine derartige Einschränkung im Grunde nicht... Was es aber gab, je nach Version und Lizenz waren gewisse Limitierungen in der Anzahl der vCPUs gegeben. So konnte beispielsweise die ESXi 4.1er Version als Hypervisor mit freiem Key nur vier vCPUs pro VM. Egal ob da nun zwei Cores + SMT, vier Cores oder weit mehr wie vier Cores (+ SMT) drin steckten. Pro VM war das Limit bei vier und nicht mehr. Die nächst höhere Standard Edition konnte meine ich dann acht. Was aber definitiv Versionsunabhängig beschränkt war, man konnte nie mehr vCPUs (oder vCores) einer einzigen VM zuweisen, als physisch in Summe vorhanden waren. Sprich du kannst nicht acht vCPUs zuweisen, wenn nur ein Quadcore ohne SMT im Host tuckert.
Was noch zu erwähnen wäre, erst seit dem 4.1er bekommt man offiziell in der GUI die Möglichkeit überhaupt auf vCore Ebene da rumzustellen. Bis 3.5 gab es glaube ich nur vCPUs (keine Möglichkeit auf die Cores zu gehen). In der 4.0 ging es via händischem Editieren der VMX Files. Das vorhandene Limit auf die vCPUs bleibt aber bestehen. Im Hypervisor 4.1 ist es egal ob du 4x vCPU oder 1x vCPU zu 4x Cores zuweist, mehr ist nicht...

Was die Speedunterschiede angeht, es gibt Leistungsunterschiede zwischen vCPUs und vCores. Unabhängig der Anzahl. Man sollte tunlichst vermeiden mehr vCPUs einer VM zuzuordnen, wie man physische CPUs im Host stecken hat, einfach weil es ein wenig Performance kostet. Auch sollte man vermeiden mehr vCores einer VM zu geben, als eine physische CPU bereit stellen kann, die im Host steckt. Macht man das, bedeutet es gleichsam, das der Host in die NUMA Node Problematik gezwungen wird, nämlich das die Berechnungen auf mehrere physische CPUs verteilt werden. Cachezugriffe gehen dann über den im Vergleich extrem lahmen "Bus".

Was die vCPUs generell angeht, hier ist weniger oftmals einfach mehr. Zu viele virtuelle CPUs bzw. Cores zugewiesen kann sich schnell negativ auswirken. Da die VMs bei erzeugender Last vereinfacht gesagt warten, bis die physischen Einheiten frei sind. Ne VM mit einer vCPU und nur einen vCore muss weit weniger lange warten, bis die Ressourcen mal "frei" sind, als wenn viele VMs jeweils immer die ganze CPU zugewiesen bekommen haben. Der Grund liegt hier eher am Gastbetriebssystem als am Host selbst. Hintergrundanwendungen verlangen immer mal wieder (wenn auch wenig) Rechenzeit von der CPU. VMs, die gänzlich schlafen, hat es im Grunde eher selten bis nie. Um so mehr hier gewartet werden muss, desto mehr Performance lässt man liegen, obwohl die VMs im Grunde die ihr zugewiesenen vCPUs gar nicht voll auslasten ;)
 
OK dann hab ich wohl richtig vermutet bzw. nachgelesen.
Miene andere Vermutung ist dass viele iSCSI Appliances anständiges Multipathing nur über mehrere IPs hinbekommen.
 
Was ja auch gar nicht sooo extrem abwägig ist. Denn wenn du getrennte LAN Infrastrukturen hast, die eben pro "Strecke" insich geschlossen sind, ist oftmals mit irgendwelcher Teambildung nicht viel zu machen... Wobei es dort ein paar Lösungen bei Cisco und Nortel/Avaya gibt, die das auch Switchübergreifend machen lassen. Dürfte aber durchaus eher selten vorkommen solch eine Konfig.
 
hallo zusammen,

ich habe die aktuellen Patches für ESXi 5.1 installiert und auch auf dem Windows XP Rechner den neuen VSphere-Client installiert, kann mich aber mit diesem nicht mehr auf den ESXi Server verbinden. Hat VMware den Windows XP Support für den VSphere Client schon eingestellt (wie beim VSphere 5.5)?
 
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