ESX / ESXi - Hilfethread

Traffic wird erzeugt, wenn in einem System ein virtuelles NAS oder SAN läuft. Und das wird oft gemacht und geht mit aktueller Hardware mit mehreren GByte/s problemfrei über die vnics und den virtuellen Switch - insbesondere mit vmxnet3 bei denen die CPU Last deutlich geringer ausfällt als mit älteren vnics wie e1000.

Internet Traffic mit ein paar MByte/s ist tausendmal weniger und praktisch kein Traffic.
Ansonsten ist der Artikel aus 2008 und hat keine sonderliche Relevanz mehr.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Und nochmal:
Wenn die NIC Virtualisierungs Technologien unterstützt, ist der Unterschied sowieso gleich 0. ;)
 
Ok, habs verstanden, wenn VMDq/NextQueue unterstützt wird, kann es mir völlig egal sein ob ich die NIC's durchreiche oder virtuelle NIC's an die VM's zuweise.
Für mich ist der Fall nun klar, da ich kaum Slots für die Erweiterung habe und somit max. 1 NIC einbauen kann, setze ich auf eine Quad-Port Netzwerkkarte welche die erwähnten Features unterstützt.

Das wären Intel i340,i350 und Broadcom 5719/5720 soweit ich herausgefunden habe.
Nun suche ich mir da eine gute und günstige aus, und gut ist.

Vielen Dank für eure kompetente Hilfe :)
 
Vom Durchsatz her ist es nach meinen Tests egal ob du die Karte durchreichst oder mit einem vSwitch und virtuellen Adaptern (vmxnet3) arbeitest. Meine Tests habe ich mit einer 10GBe Karte gemacht.
 
Sehr gut.
Denn es ist für meine Verwendungszwecke besser, keine Physischen Adapter zu "verschwenden" weil ich diese durchreiche.
Je mehr ich den Traffic der VM's auf die physichen NIC's verteilen kann, desto besser.

Ich habe einen ITX Server und dennoch ein paar VM's drauf (u.A File-Server, DC, Mail
 
Ich hab den ESXi 6.0.0 U1 auf einer Fujitsu Celsus W550 laufen die onboard eine Intel GBit NIC hat.
Jetzt fällt mir auf dass beim Transfer der VMs aufs Datastore per Datenspeicherbrowser im vSphere Client oder SFTP per Filezilla auf 100 MBit/s fest genagelt schien.

Dann hab ich mich mal auf die Suche gemacht, Netzwerkschnittstelle läuft aber definitiv auf 1000 MBit/s.
Aus einer VM raus erreiche ich diese Bandbreite nach draußen auch.

Kann's sein dass die Transferrate von draußen über's LAN aufs Datastore irgendwo gedeckelt ist?
 
Über LAN können definitiv weitaus höhere Datenraten als 100 Mbit/s übertragen werden, solange alle Komponenten dementsprechend leistungsfähig sind und die Kabel nicht irgendwo einen Kabelbruch o.ä. haben.

Was ist das für ein Datastore? Wie sind die Geräte untereinander verbunden? Wenn nicht mehr als 11 MB/s durchkommen, gibt es irgendwo eine Komponente, dessen Netzwerk mit 100 Mbit/s betrieben wird.
 
Das Problem kenne ich auch.
Wobei ich neulich erstaunt über die Geschwindigkeit des Datenspeicherbrowsers bei ESXI 6 war, da habe ich beim Hochladen von ISO-Dateien um die 900Mbit/s erreicht.
Aber du kopierst ja VMs. Das habe ich auf dem Host jetzt noch nicht gemacht, aber ich glaube bei VM-Dateien ist das wirklich irgendwie gedeckelt.
Ist nach meinen Erfahrungen auch genau dasselbe, wenn man per SSH auf den Host geht und da per cp VM-Dateien kopiert.
 
Das Datastore im ESXi ist ein RAID 1 aus 2x 300 GB 15k SAS HDDs, die Quelle am PC eine Intel SSD 910 (PCIe) die auch ihre 1500-2000 MB/s lesend packt.
Sowohl der ESXi als auch der Quell-PC hängen per GBit am selben Switch.

Ich hab auch zwischen dem Quellrechner und einer VM auf dem betroffenen ESXi System mal per iPerf gemessen, da komm ich schon mit 1 GBit/s durch.
Nur beim Kopieren der VMs auf den ESXi, egal ob über vSphere Client oder Filezilla, komm ich nicht über die ~12 MB/s raus.
 
probiere mal mit die vms mit veeam backup free zu kopieren, das connected soweit ich weiss mehrmals über scp um dein netzwerk auszulasten.
 
Ja das dürfte tatsächlich schneller gehen, hab ich teilweise auch im Einsatz.

Hab mal etwas gegoogelt, letztendlich läuft's immer wieder darauf raus dass SCP beim ESXi einfach lahm ist.
 
Ich muss jetzt nochmal blöd fragen:

Kann ich meine virtuellen Maschinen bzw. die HDDs auch über den Server an sich backupen? Ich stelle mir das so vor, dass ich einen Dienst auf dem Server laufen habe (vermutlich in einer eigenen VM) und dieser mir ein Backup meines Servers auf eine externe HDD macht. Dazu möchte ich gerne auf verschiedene Versionen zurückgreifen (also wie das TimeMachine Backup mit der TimeCapsule).

Bei Veeam muss ich ja das Programm lokal auf meinem Desktoprechner laufen lassen.

Vielen Dank. Gruß :-)
 
nö du kannst veeam eigentlich auch in einer weiteren windows-vm (die deine externe usb-hdd durchgereicht hat) laufen lassen und backupst eben nur die anderen vm's. allerdings ist die IO last dann ziemlich hoch weil ja alles aufm gleichen host läuft, müsstest du testen ob das von der performance her brauchbar bei dir ist.
 
Hallo miteinander,
kämpfe aktuell mit dem onboard controller eines HP Proliant ML150 Gen9.
Handelt sich um einen B140i und der aktuellen Customized VMware 6.0 (vom Nov)

Egal ob ich den Controller im Raid oder SATA mode betreibe, die Schreibperformance ist sehr schlecht.
Mit einem testweise eingebauten Adpatec 6805 komme ich auf das 6 fache (50GB File lokal auf SSD kopiert, somit Cache nicht relevant)

Vielen Dank im Voraus
Treiber sind bereits laut HP Problemhinweis auf Stand Mai 2015 downgegradet.
Der offiziell zuegörige hpvsa Treiber auch mit der März version 5.5.0.26 getestet.
Performance weiterhin schlecht.
Hat einer von euch noch einen Tipp ?
(Für ein reines Raid 1 + SSD wollte ich mir eigentlich einen H240 ersparen)

Danke im Voraus
 
morumbinas schrieb:
Ich muss jetzt nochmal blöd fragen:

Kann ich meine virtuellen Maschinen bzw. die HDDs auch über den Server an sich backupen? Ich stelle mir das so vor, dass ich einen Dienst auf dem Server laufen habe (vermutlich in einer eigenen VM) und dieser mir ein Backup meines Servers auf eine externe HDD macht. Dazu möchte ich gerne auf verschiedene Versionen zurückgreifen (also wie das TimeMachine Backup mit der TimeCapsule).

Bei Veeam muss ich ja das Programm lokal auf meinem Desktoprechner laufen lassen.

Vielen Dank. Gruß :-)
Zum Vergrößern anklicken....

Die beste Option für Versionierung wäre ein ZFS NAS/SAN auf dem ESXi seine VMs per NFS ablegt.
Per ZFS kann man beliebig oft Snapshots anlegen auf die man z.B. per Windows "vorherige Version" zugreifen kann.

Mit ZFS Storage kann man auch den ESXi datastore im laufenden Betrieb replizieren/sichern.
Das Storage kann extern (barebone) oder virtualisiert unter ESXi laufen. Virtualisiert biete ich eine
ready to use ZFS Storage appliance (napp-it) als .ova template zum Download.
 
Hat jemand mal getestet, wenn man den Onboard Storagecontroller durchreicht, wieviel Verlust an Übertragungsleistung das ergibt?

Beispielsweise den Onboardcontroller einer OpenFiler VM durchreiche, dort einen Pool erstelle und diesen per iSCSI auf dem gleichen Host eintrage.
Die Übertragungsrate zwischen dvSwitch bzw. vSwitch zum darin befindlichen Managementport müssten ja theoretisch so hoch sein, wie es die Leistung hergibt.

Das wäre im Moment eine Alternative um mir keinen neuen Raidcontroller zu kaufen ... allerdings möchte ich bei den Platten bzw. vor allem der SSD eine hohe I/O behalten.
 
Gibt es eine Möglichkeit, dass Veeam (oder ein anderes Backup Programm) nur die tatsächlich vorhanden Dateien sichert? Bei mir ist zB eine virtuelle Festplatte 1TB groß (die vorhanden Dateien haben aber zusammen nur ca. 250GB). Erstelle ich jetzt mit Veeam ein Backup, brauche ich 1TB auf dem Backupvolumen.

Ein weiteres Problem ist, dass ich diese Virtuelle Festplatte auch für mehrere VMs durchreiche. Erstelle ich mit Veeam ein Backup von 2 VMs und beide VMs verwenden die selbe Virtuelle Festplatte, dann wird die Virtuelle Festplatte bei beiden VMs gesichert (dementsprechend brauche ich unnötig viel Platz auf dem Backupvolumen, da ja die Dateien 2x vorhanden sind).

Ist dies technisch geschuldet oder gibt es da eine Möglichkeit, dies zu umgehen?

Danke
 
morumbinas schrieb:
Gibt es eine Möglichkeit, dass Veeam (oder ein anderes Backup Programm) nur die tatsächlich vorhanden Dateien sichert? Bei mir ist zB eine virtuelle Festplatte 1TB groß (die vorhanden Dateien haben aber zusammen nur ca. 250GB). Erstelle ich jetzt mit Veeam ein Backup, brauche ich 1TB auf dem Backupvolumen.
Zum Vergrößern anklicken....
Bist Du dir da ganz sicher? Veeam sichert eigentlich nur das, was wirklich vorhanden ist, und dedupliziert und komprimiert noch zusätzlich, so dass noch weniger Platz für das Backup benötigt wird.

Wenn Du von der Anzeige der Größe der virtuellen Maschinen im Sicherungsjob sprichst: das wiederum wird anhand der Größe der virtuellen Festplatten angezeigt, nicht am tatsächlichen Füllstand der virtuellen Festplatten innerhalb der VMs. Was letztendlich als Sicherungsdatei herauskommt, ist weitaus weniger.

morumbinas schrieb:
Ein weiteres Problem ist, dass ich diese Virtuelle Festplatte auch für mehrere VMs durchreiche. Erstelle ich mit Veeam ein Backup von 2 VMs und beide VMs verwenden die selbe Virtuelle Festplatte, dann wird die Virtuelle Festplatte bei beiden VMs gesichert (dementsprechend brauche ich unnötig viel Platz auf dem Backupvolumen, da ja die Dateien 2x vorhanden sind).

Ist dies technisch geschuldet oder gibt es da eine Möglichkeit, dies zu umgehen?
Zum Vergrößern anklicken....
Du kannst bei einer von beiden virtuellen Maschinen die virtuelle Festplatte von der Sicherung ausschließen (den Backupjob bearbeiten und auf der Seite Virtual Machines gibt es einen Button "Exclusions", wo man einstellen kann, dass z.B. SCSI 0:2 ausgeschlossen werden soll. Welche virtuelle Festplatte Du bei der Sicherung ausschließen musst, kannst Du im vSphere Client beim Bearbeiten der virtuellen Maschine sehen, dort steht dann eben diese ID.
 
Zur ersten Frage: ghettoVCB kann die VMs thin-provisioned sichern. Dann sollte die Sicherung immer nur so groß wie der belegte Speicherplatz werden.
Wie man das einrichtet ist hier beschrieben: https://communities.vmware.com/docs/DOC-8760
Kann natürlich sein, dass das auch mit Veeam geht, damit habe ich aber noch nicht gearbeitet, da es das ja nicht (mehr) für ESXi free gibt soweit ich gelesen habe.
 
Sind die Festplatten der VMs Thick Provisioned? Bei ThinProvision sollte die .vmdk immer nur so groß sein wie der belegte Speicher der auf der virtuellen Festplatte(außer es wird viel gelöscht, kleiner wird sie nämlich unter keinen Umstände). Bei ThickProvision ist sie eben genau so groß wie du eingestellt hast und das von Anfang an egal wie viel darauf liegt.

Bezüglich des Backups der identischen Festplatten werden diese zwar bei jeder VM gesichert jedoch sollte es wegen der Deduplizierung von Veeam nicht groß ins Gewicht fallen.
 
Fr3@k schrieb:
Sind die Festplatten der VMs Thick Provisioned? Bei ThinProvision sollte die .vmdk immer nur so groß sein wie der belegte Speicher der auf der virtuellen Festplatte(außer es wird viel gelöscht, kleiner wird sie nämlich unter keinen Umstände). Bei ThickProvision ist sie eben genau so groß wie du eingestellt hast und das von Anfang an egal wie viel darauf liegt.
Zum Vergrößern anklicken....
Spielt bei Veeam keine Rolle, denn Veeam sichert nicht die vmdks, sondern über die VMWare Tools und (im Falle einer Windows-Maschine) VSS die Daten innerhalb des Gastbetriebssystems. Es kommen auch keine vmdks heraus, sondern vbk, vib etc., was Veeam-Sicherungsdateien sind.
 
Kurze Frage an die Profis :xmas:

Ich möchte ein NAS virtualisieren aber den SATA-Controller mit den Harddisks nicht direkt durchreichen.
Macht das Sinn oder ist die Performance dann gleich katastrophal?

Ich meine gehört zu haben dass ESXi onehin Fake/Software Raid doof findet...
Es geht um den Onboard Controller des Mainboards (C222 Chipsatz, nix spezielles)
 
den kannst du nicht durchleiten. wird schlicht nicht dazu angeboten in der passthrough liste.
Du müsstest einen VM-Ware verträglichen Raidcontroller z.b. nehmen und diesen für die VM durchleiten, bringt aber auch nur mehr probleme als Vorteile.
Ich habe mir z.b. einen supporteten lsi mit webmanagement geholt der direkt von esxi unterstützt wird und den datastore (raid5) bereitstellt. darauf dann einfach die NAS virtualisiert inkl dessen storage (thick volume) und läuft.

Generell kannst du mit intel onboard sata-controllern immer nur single-laufwerke maximal als datastore einbinden, nicht durchleiten.
Es sei denn du hast ein spezielles servrboard dessen sata/HBA auf der vm-supportliste steht. tun die ganzen Cxxx und standard Intel ICH Teile nicht..
 
Ich möchte ein NAS virtualisieren aber den SATA-Controller mit den Harddisks nicht direkt durchreichen.
Macht das Sinn oder ist die Performance dann gleich katastrophal?
Zum Vergrößern anklicken....

Meinst du mit durchreichen via VT-D?

Das sollte klappen, sofern da nix anderes dran hängt, was der ESXi benötigt.
Liegt dort ein Datastore drauf, auf dem wiederum die NAS VM liegt, klappts nicht.

Ansonsten kannst du entweder eine VMDK auf jeder Platte erstellen oder die einzelnen Platten via RDM an die NAS VM durchreichen.

Ich meine gehört zu haben dass ESXi onehin Fake/Software Raid doof findet...
Es geht um den Onboard Controller des Mainboards (C222 Chipsatz, nix spezielles)
Zum Vergrößern anklicken....

Ja, der ESXi kann mit dem Software RAID der Intel Onboard Controller nix anfangen und würde die Platten (sofern der Controller vom ESXi unterstützt wird) höchstens als einzelne Platten sehen.
 
Eye-Q schrieb:
Spielt bei Veeam keine Rolle, denn Veeam sichert nicht die vmdks, sondern über die VMWare Tools und (im Falle einer Windows-Maschine) VSS die Daten innerhalb des Gastbetriebssystems. Es kommen auch keine vmdks heraus, sondern vbk, vib etc., was Veeam-Sicherungsdateien sind.
Zum Vergrößern anklicken....

Das ist nicht korrekt, Veeam erstellt einen Snapshot der VM und dieser wird dann gesichert, VSS wird verwendet damit die Daten konsistent sind wenn es sich z.B. um einen SQL Server handelt.
Bei Hyper-V funktioniert das ganze über einen VSS Sanpshots.

https://www.veeam.com/university-course/backup-replication-how-it-works.html
 
Zuletzt bearbeitet:
Hallo,

habe des öfteren gelesen, dass ein "HP Smart Array B120i" Controller (Fake-Raid) mit entsprechenden Treibern bzw. dem HP Customized Image im ESXI als RAID Volume und nicht als separate physikalische Disks erkannt werden soll.
Habe es mit den Images ": "VMware-ESXi-6.0.0-Update1-3073146-HP-600.9.4.34-Nov2015.iso" und "VMware-ESXi-5.1.0-Update2-2000251-HP-5.69.2-Nov2014.iso" versucht.
Allerdings werden die Platten immer einzeln angezeigt (siehe Screenshots).

Ist es nun möglich das RAID als solches zu betreiben oder funktioniert das einfach nicht?

Danke
 

Anhänge

  • addstorage.jpg
    addstorage.jpg
    109 KB · Aufrufe: 130
  • storageadapters.jpg
    storageadapters.jpg
    110,3 KB · Aufrufe: 171
Fr3@k schrieb:
Blöde Frage hast du den vorher ein RAID eingerichtet?
Zum Vergrößern anklicken....

Aber berechtigt ;-)
Ein RAID 1 Array mit 2 Volumes wurde vorher natürlich eingerichtet und wird beim booten/initialisieren auch korrekt angezeigt.

btw: Grüsse von Linz nach Perg :-)
 
Zuletzt bearbeitet:
Wenn der Installer von VMware läuft bekommst Du da quasi auch beide Laufwerke dediziert gezeigt, ja?
schon mal das 5.5er ESXi oder 6.0er probiert?

beim Asrock E350M1 z.B. geht nur mit dem 5.5er von der Installation weg die Onboard NIC, beim 5.1er nicht und beim 6.0er auch nicht... o_O
 
Wenn der Installer von VMware läuft bekommst Du da quasi auch beide Laufwerke dediziert gezeigt, ja?
Zum Vergrößern anklicken....
Kann ich nicht mehr sagen. Mit korrekt angezeigt habe ich den Initialisierungsvorgang vom Server selbst gemeint.

schon mal das 5.5er ESXi oder 6.0er probiert?
Zum Vergrößern anklicken....
Habe 6.0 und 5.1 schon versucht: "VMware-ESXi-6.0.0-Update1-3073146-HP-600.9.4.34-Nov2015.iso", "VMware-ESXi-5.1.0-Update2-2000251-HP-5.69.2-Nov2014.iso"

Der Smart Array Controller läuft übrigens ohne FBWC.

Müssen noch irgendwelche BIOS Einstellungen vorgenommen werden (außer auf RAID einzustellen)?
 
Anmelden, um zu antworten.
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