JumpySkippy
Enthusiast
- Mitglied seit
- 08.01.2003
- Beiträge
- 20
Der Windows-Ressourcenschutz hat keine Integritätsverletzungen gefunden.
Bei dism funktioniert der Schalter /restorehealth unter Windows 7 nicht.
ESX / ESXi - Hilfethread
- Ersteller XTaZY
- Erstellt am
Der Windows-Ressourcenschutz hat keine Integritätsverletzungen gefunden.
Bei dism funktioniert der Schalter /restorehealth unter Windows 7 nicht.
Ja im grunde genommen die ESXI-Config und die VMs komplett.
Gut wäre, wenn man aus einer Debian-VM heraus auf den Speicherort der Backups zugreifen könnte, dann können die regelmässig per Cronjob, VPN/SSH-FS auf einen externen Server kopiert werden.
![[SoD]r4z0r](/community/data/avatars/m/111/111944.jpg?1577437183){kind=avatar}
[SoD]r4z0r
Enthusiast
- Mitglied seit
- 11.04.2009
- Beiträge
- 3.950
@KBastian
Um dich richtig zu verstehen: Du hast bei Site A deine ESXer + Datastore und möchtest dort VMs sichern und die anschließend per SSH über ein Debian was bei Site B läuft sichern dass das Backup nicht mehr nur lokal bei Site A ist?
Wie sieht das mit der Größe der VMs aus? Evtl. könntest du auf Site A eine VMware VDP nutzen um die VMs lokal auf den Datastore zu sichern. Dann per Script die VDP runterfahren, per SSH die VDP vom Datastore zu Site B kopieren und danach die VDP wieder starten...
Rein eine Überlegung. Ob das praktikabel ist weiß ich nicht.
Ob das ganze evtl. inkrementell, dedupliziert etc. mit kostenfreier Backupsoftware geht weiß ich nicht...
Um dich richtig zu verstehen: Du hast bei Site A deine ESXer + Datastore und möchtest dort VMs sichern und die anschließend per SSH über ein Debian was bei Site B läuft sichern dass das Backup nicht mehr nur lokal bei Site A ist?
Wie sieht das mit der Größe der VMs aus? Evtl. könntest du auf Site A eine VMware VDP nutzen um die VMs lokal auf den Datastore zu sichern. Dann per Script die VDP runterfahren, per SSH die VDP vom Datastore zu Site B kopieren und danach die VDP wieder starten...
Rein eine Überlegung. Ob das praktikabel ist weiß ich nicht.
Ob das ganze evtl. inkrementell, dedupliziert etc. mit kostenfreier Backupsoftware geht weiß ich nicht...
Ich sichere meine VMs mittels xsibackup:xsibackup
Das ist ein Script, welches ohne Overhead nativ auf ESXI läuft. Es sichert meine VMs per xsibackup-cron-job jede Nacht auf eine datastoreMirror auf der ESXI Maschine (2. Platte) und einmal die Woche auf mein NAS. Auf dem NAS halte ich ca. 10 Versionen kompletter Backups vor. Wird über die zur Verfügung gestellte Kapazität (1TB oder 500 GB oder ...) im cron-job geregelt.
Die auf dem Mirror nutze ich als "Sofort-Verfügbar-Fallback" falls ich mal eine VM zerschiesse oder mir eine VM-datastore-Platte verratzt.
In der ProVersion wird auch die Config mit gesichert. Die kostet allerdings ein paar Euro. Erlaubt dann aber u.a. auch inkrementelle Backups. Was insbesondere für WAN Backups von Vorteil ist.
Mir war am Ende die Simplizität von xsibackup lieber als eine extra Maschine für Backups mit Veeam (als Beispiel) laufen zu lassen. Ich habe die Pro Version gekauft und bin zufrieden. Service von den Jungs aus Spanien ist auch sehr gut. Hatte ein paar mal hin und her geschrieben.
Jetzt gibt es allerdings keine Lifetime-Upgrades mehr. Insoweit könnte alternativ das hier von Interesse sein, ist komplett frei:ghettoVCB
Das ist ein Script, welches ohne Overhead nativ auf ESXI läuft. Es sichert meine VMs per xsibackup-cron-job jede Nacht auf eine datastoreMirror auf der ESXI Maschine (2. Platte) und einmal die Woche auf mein NAS. Auf dem NAS halte ich ca. 10 Versionen kompletter Backups vor. Wird über die zur Verfügung gestellte Kapazität (1TB oder 500 GB oder ...) im cron-job geregelt.
Die auf dem Mirror nutze ich als "Sofort-Verfügbar-Fallback" falls ich mal eine VM zerschiesse oder mir eine VM-datastore-Platte verratzt.
In der ProVersion wird auch die Config mit gesichert. Die kostet allerdings ein paar Euro. Erlaubt dann aber u.a. auch inkrementelle Backups. Was insbesondere für WAN Backups von Vorteil ist.
Mir war am Ende die Simplizität von xsibackup lieber als eine extra Maschine für Backups mit Veeam (als Beispiel) laufen zu lassen. Ich habe die Pro Version gekauft und bin zufrieden. Service von den Jungs aus Spanien ist auch sehr gut. Hatte ein paar mal hin und her geschrieben.
Jetzt gibt es allerdings keine Lifetime-Upgrades mehr. Insoweit könnte alternativ das hier von Interesse sein, ist komplett frei:ghettoVCB
Zuletzt bearbeitet:
Ja richtig, es sollen lokale Backups erstellt werden und die zur Sicherheit in Kopie auf nen zweiten Datastore bzw. Debian Fileserver abgelegt werden.
Die VMs selbst sind nur einige Gigabytes netto, die Debian-VM bedient mein Datengrab, aber das sichere ich separat per rsync.
Die Sicherung der VMs zu Site B könnte ggf auch nur wöchentlich erfolgen, je nachdem wie lange der Sync zwischen den Sites dauert.
Lightflasher
Enthusiast
Nabend hat wer noch Probleme mit dem PCI Passthrough bei vSphere 6.5? Geht hierbei einmal um eine USB 3 Karte und einmal um einen SAS HBA, gleicher Host aber zwei unterschiedliche VMs. In 6.0 war es zuvor ohne Probleme möglich diese durchzureichen.
Grüße
Code:
2017-02-28T19:41:59.684Z| vcpu-0| I125: Msg_Post: Error
2017-02-28T19:41:59.684Z| vcpu-0| I125: [msg.log.error.unrecoverable] VMware ESX unrecoverable error: (vcpu-0)
2017-02-28T19:41:59.684Z| vcpu-0| I125+ PCIPassthruChangeIntrSettings: 0000:03:00.0 failed to register interrupt (error code 195887105)
2017-02-28T19:41:59.684Z| vcpu-0| I125: [msg.panic.haveLog] A log file is available in "/vmfs/volumes/#####/vmware.log".
2017-02-28T19:41:59.684Z| vcpu-0| I125: [msg.panic.requestSupport.withoutLog] You can request support.
2017-02-28T19:41:59.684Z| vcpu-0| I125: [msg.panic.requestSupport.vmSupport.vmx86]
2017-02-28T19:41:59.684Z| vcpu-0| I125+ To collect data to submit to VMware technical support, run "vm-support".
2017-02-28T19:41:59.684Z| vcpu-0| I125: [msg.panic.response] We will respond on the basis of your support entitlement.Grüße
Forenreiter
Experte
- Mitglied seit
- 10.06.2014
- Beiträge
- 58
Hallo zusammen,
habe mit dem aktuellen ESXi 6.5.0 HP Custom Image (VMware-ESXi-6.5.0-OS-Release-4564106-HPE-650.9.6.0.28-Nov2016) auf meinem Microserver experimentiert. Läuft soweit einwandfrei bis auf eine Fehlermeldung. Bei jeder Neueinrichtung und dann Starten der VM bekomme ich folgende Fehlermeldung und muss dann den Web-Client neu starten. Gelegentlich auch mal bei anderen Aktionen.
Fehlermeldung:
In den Details steht dann:
Hat das jemand schon in der Version 6.5.0 gehabt? Gibts ggf. Patche oder Lösungen?
Danke vorab.
habe mit dem aktuellen ESXi 6.5.0 HP Custom Image (VMware-ESXi-6.5.0-OS-Release-4564106-HPE-650.9.6.0.28-Nov2016) auf meinem Microserver experimentiert. Läuft soweit einwandfrei bis auf eine Fehlermeldung. Bei jeder Neueinrichtung und dann Starten der VM bekomme ich folgende Fehlermeldung und muss dann den Web-Client neu starten. Gelegentlich auch mal bei anderen Aktionen.
Fehlermeldung:
In den Details steht dann:
Hat das jemand schon in der Version 6.5.0 gehabt? Gibts ggf. Patche oder Lösungen?
Danke vorab.
Luckysh0t
Enthusiast
Hacker brechen aus virtueller Maschine aus | heise online
Auch wenn es es da primär um VMWare Workstation geht.
Frage ich mich ob es diese Schwachstelle auch in ESXi gibt und wenn ja, was dann die Möglichkeiten sind..Zugriff auf den RAM und damit ggf. auf Daten anderer VM ?
Ist das nun Clickbait (wenn auch nicht in der Überschrift) oder doch "real", weil von ESXi wird ja wie gesagt nicht gesprochen.Mal davon ab, dass man (unpatched) Windows 10 und Edge benötigt.
Auch wenn es es da primär um VMWare Workstation geht.
Frage ich mich ob es diese Schwachstelle auch in ESXi gibt und wenn ja, was dann die Möglichkeiten sind..Zugriff auf den RAM und damit ggf. auf Daten anderer VM ?
Ist das nun Clickbait (wenn auch nicht in der Überschrift) oder doch "real", weil von ESXi wird ja wie gesagt nicht gesprochen.Mal davon ab, dass man (unpatched) Windows 10 und Edge benötigt.
Zuletzt bearbeitet:
Prinzipiell gibt es nur relative sicherere Software und je mehr Angriffsoptionen man bietet desto prinzipiell angreifbarer wird es. Ein Linux/OSX/Unix/Windows mit Desktopumgebung und allerlei Web/ Mediatools oder vielen Services ist einfach unsicher. Das sieht man schon daran dass speziell dafür die meisten Security Fixes kommen. Hierunter fällt auch dieser Angriff.
Ein vollwertiges aber strikt minimalisiertes OS egal ob Linux/Unix/Windows ohne GUI ist da schon erheblich sicherer, egal ob man das Basis OS betrachtet oder darauf virtualisierte Umgebungen.
Nimmt man kein vollwertiges OS sondern eine nochmal reduzierte Umgebung wie einen Type-1 Hypervisor z.B. ESXi oder Xen so reduzieren sich die Angriffsoptionen nochmal. Da gibt es kaum noch Möglichkeiten ausser Speicher/Buffer Overflow oder komprommitierte Dienste wie SSH/SSL oder Treiber um tatsächlich den Hypervisor zu übernehmen. Vermutlich würde da ein Angriff über die Managementfunktion am einfachsten sein (Passwort ausspähen).
Bei ESXi würde ich eher davon ausgehen, dass die Gäste oder die Services angegriffen werden. Die letzten großen Sachen waren ja SSH und SMB. Will jemand an die Daten ist es ohnehin so, dass ein Diebstahl eines Systems ohne jegliches Knowhow viel einfacher und billiger ist. Bei Geheimdiensten und verdeckten Angriffen mag das anders sein.
Ein vollwertiges aber strikt minimalisiertes OS egal ob Linux/Unix/Windows ohne GUI ist da schon erheblich sicherer, egal ob man das Basis OS betrachtet oder darauf virtualisierte Umgebungen.
Nimmt man kein vollwertiges OS sondern eine nochmal reduzierte Umgebung wie einen Type-1 Hypervisor z.B. ESXi oder Xen so reduzieren sich die Angriffsoptionen nochmal. Da gibt es kaum noch Möglichkeiten ausser Speicher/Buffer Overflow oder komprommitierte Dienste wie SSH/SSL oder Treiber um tatsächlich den Hypervisor zu übernehmen. Vermutlich würde da ein Angriff über die Managementfunktion am einfachsten sein (Passwort ausspähen).
Bei ESXi würde ich eher davon ausgehen, dass die Gäste oder die Services angegriffen werden. Die letzten großen Sachen waren ja SSH und SMB. Will jemand an die Daten ist es ohnehin so, dass ein Diebstahl eines Systems ohne jegliches Knowhow viel einfacher und billiger ist. Bei Geheimdiensten und verdeckten Angriffen mag das anders sein.
Nun, auch ohne direkten cachezugriff lässt sich aus seiteneffekten massiv infos gewinnen.
Ich verweise hier aus Faulheit mal auf "What could possibly go wrong with ?" vom 33c3 als "Basis"
Gesendet von meinem ZTE+A2017G mit Tapatalk
Ich verweise hier aus Faulheit mal auf "What could possibly go wrong with ?" vom 33c3 als "Basis"
Gesendet von meinem ZTE+A2017G mit Tapatalk
Zuletzt bearbeitet:
konfetti
Urgestein
Angriffe gegen ESXi mit dem Ausbruch aus dem Gast gab es zu 3.5er Zeiten - aktuell hab ich da nix mehr gehört.
Eine Workstation hat immer noch zusätzliche Dienste laufen, allein schon weil Drag+Drop möglich ist - so kommt man auch leichter aus der VM auf den Host - bei nem ESXi wird das eben schon schwieriger.
Warten wir einfach mal ein paar Statements ab
Eine Workstation hat immer noch zusätzliche Dienste laufen, allein schon weil Drag+Drop möglich ist - so kommt man auch leichter aus der VM auf den Host - bei nem ESXi wird das eben schon schwieriger.
Warten wir einfach mal ein paar Statements ab
Mal ne Einsteiger-Frage:
Habe ESXI aufgesetzt, nun möchte ich eine VM erstellen. Klappt soweit auch ganz gut.
Die VM soll von einer ISO booten, um Lubuntu zu installieren.
Habe schon fast alles ausprobiert, *.ISO statt *.iso, im BIOS Boot Reihenfolge angepasst, Boot Menue aufgerufen, Haken bei "verbinden bei einschalten" ist immer gesetzt.
Bin mit meinem Latein echt am Ende, kann mir einer von euch helfen?
Habe ESXI aufgesetzt, nun möchte ich eine VM erstellen. Klappt soweit auch ganz gut.
Die VM soll von einer ISO booten, um Lubuntu zu installieren.
Habe schon fast alles ausprobiert, *.ISO statt *.iso, im BIOS Boot Reihenfolge angepasst, Boot Menue aufgerufen, Haken bei "verbinden bei einschalten" ist immer gesetzt.
Bin mit meinem Latein echt am Ende, kann mir einer von euch helfen?
Prinzipiell ist es egal, ob die Dateierweiterung groß oder klein geschrieben wird, da wird wohl etwas anderes im Argen sein. Hast Du das ISO schon mal neu heruntergeladen bzw. geschaut, ob die Checksumme stimmt? Vielleicht ist die ja einfach defekt heruntergeladen worden.
Ja, eine andere ISO geht.
Ist eine normale Installations-ISO direkt von Lubuntu.net
Lade gerade mal eine neue ISO.
Habe im Netz etwas gelesen, dass ESXI Zicken machen kann bei Lower case.
//EDIT: Lag tatsächlich an der ISO, die neue bootet wunderbar. Danke euch
Ist eine normale Installations-ISO direkt von Lubuntu.net
Lade gerade mal eine neue ISO.
Habe im Netz etwas gelesen, dass ESXI Zicken machen kann bei Lower case.
//EDIT: Lag tatsächlich an der ISO, die neue bootet wunderbar. Danke euch
Zuletzt bearbeitet:
Mh ... ich habe die napp-it-all-in-one-OVA-vm in Betrieb genommen, kann jedoch kein Snapshot mit ESXI machen, wenn die VM läuft. Offline läuft Snapshot erstellen, löschen, konsolidieren. Online gar nichts.
Die verwendeten Tools sind mit der Version anderer VMs identisch. Ich habe mich jetzt ewig durchs Netz gewühlt, aber komme auf keinen grünen Zweig.
Hat jemand eine Idee?
ESXI 6.5, napp-it-ova-2017.01, alles auf dem aktuellen Stand.
Die verwendeten Tools sind mit der Version anderer VMs identisch. Ich habe mich jetzt ewig durchs Netz gewühlt, aber komme auf keinen grünen Zweig.
Hat jemand eine Idee?
ESXI 6.5, napp-it-ova-2017.01, alles auf dem aktuellen Stand.
Zuletzt bearbeitet:
Man kann keine Online ESXi Snaphots von VMs mit Pass-through machen.
Ist aber auch gar nicht notwendig oder sinnvoll. Die VM kann ja selber bootbare ZFS System-Snaps machen.
Im Gegensatz zu ESXi bremsen die ZFS Snaps auch das System nicht und sind auch in größerer Anzahl bis ca 30 Bootsnaps kein Problem. Bei ESXi sollte man nur einzelne Snaps für kurze Zeit halten da die Snaps alle Änderungen aufnehmen müssen und daher sehr schnell wachsen und das System langsam machen.
Ist aber auch gar nicht notwendig oder sinnvoll. Die VM kann ja selber bootbare ZFS System-Snaps machen.
Im Gegensatz zu ESXi bremsen die ZFS Snaps auch das System nicht und sind auch in größerer Anzahl bis ca 30 Bootsnaps kein Problem. Bei ESXi sollte man nur einzelne Snaps für kurze Zeit halten da die Snaps alle Änderungen aufnehmen müssen und daher sehr schnell wachsen und das System langsam machen.
Bingo ... natürlich . Die napp-it-VM ist die einzige bei mir, die mit Passthrough läuft. Danke gea.
XSIBACKUP macht "thin" backups von VMs und bedient sich ESXI Snapshots. Was natürlich in diesem Fall scheiterte. Das Programm legt ein Snapshot an, macht eine Kopie (nur in Grösse der realen Daten) und löscht danach den Snapshot. Die Kopien sind sofort produktiv nutzbar. Weshalb ich alle VMs als "Produktiv-Fallback" regelmässig auf einen zweiten Datastore wegsichere.
Mehrgenerationen-Backups mache ich jetzt aber nicht mehr mit XSIBACKUP. Da ist die job-basierte ZFS Snapshot-Funktion von napp-it ungleicher einfacher, schneller und, ganz wichtig, im zusätzlichen Datenkonsum gegen null gehend. Top.
Jetzt muss ich nur noch meinen Raspberry dazu überreden, meine APC USV nicht nur zu erkennen, sondern auch mit ihr zu kommunizieren. Und ich habe den USV NUT Server, der früher auf der Synology lief, auch noch ersetzt und kann den ESXI Server bei Stromausfall sicher herunter fahren
Hi Leute,
auf meinem ESXI (5.5) läuft meine FreeNAS-VM (9.10). Ich wollte nun auf das neue FreeNAS Corall updaten. Da ich jedoch von Problemen dabei gelesen habe, würde ich zuvor gern ein Backup der aktuellen VM anlegen, damit, wenn etwas schief läuft, ich wieder zum aktuellen Status zurück kann. Meine Frage ist nun womit kann ich dies am besten umsetzen? Ich hatte mir "Veeam Backup Free Edition" angeschaut was leider den Free ESXI nicht untersetzt, sowie einige kleinere Sachen wie bspw. "HPE-VM-Explorer" was als Webinterface etwas unsicher erscheint (oder täuscht dies?). Was würdet Ihr empfehlen (gern mit einer Online-Anleitung der Umsetzung) gern mit GUI (hatte auch GhettoBackup angeschaut was nur über die Konsole läuft).
Gruß & Danke
Sc0rc3d
auf meinem ESXI (5.5) läuft meine FreeNAS-VM (9.10). Ich wollte nun auf das neue FreeNAS Corall updaten. Da ich jedoch von Problemen dabei gelesen habe, würde ich zuvor gern ein Backup der aktuellen VM anlegen, damit, wenn etwas schief läuft, ich wieder zum aktuellen Status zurück kann. Meine Frage ist nun womit kann ich dies am besten umsetzen? Ich hatte mir "Veeam Backup Free Edition" angeschaut was leider den Free ESXI nicht untersetzt, sowie einige kleinere Sachen wie bspw. "HPE-VM-Explorer" was als Webinterface etwas unsicher erscheint (oder täuscht dies?). Was würdet Ihr empfehlen (gern mit einer Online-Anleitung der Umsetzung) gern mit GUI (hatte auch GhettoBackup angeschaut was nur über die Konsole läuft).
Gruß & Danke
Sc0rc3d
HPE-VM-Explorer ist Top.
XSIBACKUP
- Vorteil: läuft native auf ESXI, minimalster Footprint, free Version erhältlich, kopiert nur, was auch wirklich vorhanden ist (THIN), sehr gute Dokumentation beim Anbieter (siehe Blog und Videos), CRON auch in der free Version
- "Nachteil": Kommandozeile
Vorgehen:
1) Free Version herunter laden und auf ESXI bringen und entpacken
2) ggf. backup point "anlegen", bspw. Verzeichnis "your-datastore/Backup"
3) Im Verzeichnis vom xsibackup-Programm das erste Mal mit "./xsibackup" starten, um EULA zu akzeptieren
4) Im Verzeichnis vom xsibackup-Programm Backup starten mit
"./xsibackup --backup-point=/vmfs/volumes/your-datastore/Backup" --backup-type=custom --backup-vms=name-deiner-vm"
5) alternativ kannst Du als backup-point auch in ESXI gemountete nfs nehmen, und damit auf ein NAS sichern
6) damit hättest du dein temporäres Backup (entweder lokal oder auf dem NAS)
7) falls Deine Übung schief geht, kannst Du das Backup wieder zurück kopieren oder, besser, das Update gleich in der Kopie machen
Die Pro Version lieferte dann auch inkrementelle Backups und verschiedene Backup-Methoden. Kostete dann allerdings > 100 Euro. Braucht man vielleicht nicht wirklich, wenn man von Zeit zu Zeit ein eigenes Script antößt und Backups während der Nacht machen lässt.
Cheers
PS: Ich versuche hier nicht XSIBACKUP zu "verkaufen" ... nach meinen Tests mit Veema etc., wollte ich ein Programm mit minimalerem Footprint. Also nativ auf ESXI und nicht in einer eigenen VM oder auf einem anderen Rechner. GhettoBackup, eine super Alternative, fühlte sich für mich zu "komplex" an. Bei XSIBACKUP fühlte ich mich gleich wohl. That's all
Zuletzt bearbeitet:
Danke euch beiden für die Antworten! Ich habe mich dann doch für HPE-VM-Explorer entschieden, und es hat mir direkt den Arsch gerettet (musste Recovern) da meine Shellscripte gelöscht bzw. nicht übernommen wurden. Lief perfekt.
Jetzt habe ich mit einem Performance-Problem zu kämpfen, welches ich mir nicht erklären kann.
Beim Zugriff auf meine napp-it SMB oder NFS Shares, ist die Datenübertragung mit 2-4 MB/s erschreckend niedrig. Dies aber nur, wenn ich von einem ESXI VM Client aus zugreife (egal ob OSX oder Windows).
So habe ich "verkabelt":
- Meine virtuellen Clients gehen alle über den ESXI Port 01 --> ESXI vSwitch01 --> ESXI vmnic01 = physischer Netzwerkport 01 (e1000) an den physischen Switch für meine Endgeräte, Subnetz 01
- Napp-IT geht über den dedizierten ESXI Port 02 --> ESXI vSwitch02 --> ESXI vmnic02 = physischer Netzwerkport 02 (e1000) an einen anderen physischen Switch für meine Server, Subnetz 02. Die Napp-IT VM hat keine weitere Netzwerkkarte zugeordnet bekommen.
Die Subnetze werden durch eine Sophos XG gemanaged. Die Geschwindigkeit zwischen den Subnetzen ist absolut OK (bis zu 100 MB/s über 1 GB Port). Egal mit welchem anderen Gerät ich es versuche. Sobald ich aber mit einem ESXI VM Client zugreife, komme ich auf keinen grünen Zweig. Egal ob via NFS oder SMB. Ich würde erwarten, zumindest die 1 GB des Netzes ausnutzen zu können.
Alarmiert durch diese Erkenntnis habe ich, per Stoppuhr, die Performance der NFS Zugriffe durch ESXI gecheckt. Die liegen, egal ob vom VM-SSD-Pool oder vom FP-Data-Pool bei 15-20 MB/s (900 MB in 45-55 Sekunden). Auch wenig, oder?
Sonst gibt es keinen Traffic im Netz. Es laufen auch keine VMs, die gerade Traffic erzeugen. ESXI Auslastung dümpelt ebenso vor sich hin. Ich bin ein bissl ratlos.
Beim Zugriff auf meine napp-it SMB oder NFS Shares, ist die Datenübertragung mit 2-4 MB/s erschreckend niedrig. Dies aber nur, wenn ich von einem ESXI VM Client aus zugreife (egal ob OSX oder Windows).
So habe ich "verkabelt":
- Meine virtuellen Clients gehen alle über den ESXI Port 01 --> ESXI vSwitch01 --> ESXI vmnic01 = physischer Netzwerkport 01 (e1000) an den physischen Switch für meine Endgeräte, Subnetz 01
- Napp-IT geht über den dedizierten ESXI Port 02 --> ESXI vSwitch02 --> ESXI vmnic02 = physischer Netzwerkport 02 (e1000) an einen anderen physischen Switch für meine Server, Subnetz 02. Die Napp-IT VM hat keine weitere Netzwerkkarte zugeordnet bekommen.
Die Subnetze werden durch eine Sophos XG gemanaged. Die Geschwindigkeit zwischen den Subnetzen ist absolut OK (bis zu 100 MB/s über 1 GB Port). Egal mit welchem anderen Gerät ich es versuche. Sobald ich aber mit einem ESXI VM Client zugreife, komme ich auf keinen grünen Zweig. Egal ob via NFS oder SMB. Ich würde erwarten, zumindest die 1 GB des Netzes ausnutzen zu können.
Alarmiert durch diese Erkenntnis habe ich, per Stoppuhr, die Performance der NFS Zugriffe durch ESXI gecheckt. Die liegen, egal ob vom VM-SSD-Pool oder vom FP-Data-Pool bei 15-20 MB/s (900 MB in 45-55 Sekunden). Auch wenig, oder?
Sonst gibt es keinen Traffic im Netz. Es laufen auch keine VMs, die gerade Traffic erzeugen. ESXI Auslastung dümpelt ebenso vor sich hin. Ich bin ein bissl ratlos.
Was passiert, wenn Du testweise die Napp-It-VM in das Subnetz der virtuellen Clients steckst (sowohl IP-mäßig als auch an den vSwitch01)? So kannst Du ausschließen, dass es an der Sophos-Firewall liegt.
Des weiteren: Du schreibst "e1000" bei den physikalischen Netzwerkports, dieser Begriff kommt aber eigentlich aus der VMWare-Welt und bezeichnet den Typen einer virtuellen Netzwerkkarte. Was hat es damit auf sich? Wenn die VMs alle E1000-vNICs haben, gibt es da einen bestimmten Grund? E1000 ist eigentlich nur für VMs, die nicht mit den VMXNET-Netzwerkkarten umgehen können, VMXNET sollte der bevorzugte vNIC-Typ sein.
Des weiteren: Du schreibst "e1000" bei den physikalischen Netzwerkports, dieser Begriff kommt aber eigentlich aus der VMWare-Welt und bezeichnet den Typen einer virtuellen Netzwerkkarte. Was hat es damit auf sich? Wenn die VMs alle E1000-vNICs haben, gibt es da einen bestimmten Grund? E1000 ist eigentlich nur für VMs, die nicht mit den VMXNET-Netzwerkkarten umgehen können, VMXNET sollte der bevorzugte vNIC-Typ sein.
Danke Eye-Q für Dein Feedback.
ich habe mir grad doch noch mal die Sophos Firewall angeschaut. Da war an einer Stelle "High Guarantee User" angeklickt. Das habe ich auf NONE gesetzt und kam auf ähnliche Werte, wie beim Direktzugriff von ESXI auf ZFS-NFS-Shares. Also zwischen 15-20 MB/s.
Ich habe danach testweise einen VM Client (OSX) ins gleiche Subnetz, wie das NAS gestellt (entsprechenden ESXI Port ausgewählt und IP im Client angepasst). Damit ist die Performance schon deutlich besser. Kabelgebunden 45 MB/s beim Übertragen eines ISO-Files.
Dann alles wieder auf Anfang und zuerst den Windows Client, wie von Dir empfohlen, auf VMXNET umgestellt. Und siehe da >90 MB/s. Plausibel. Die selbe Datein mit OSX uliegt bei etwa 45 MB/s. Schon deutlich besser.
napp-it läuft noch mit e1000, Sophos auch ... werde ich morgen mal auf vmxnet umstellen und sehen, wo das ausgeht. Ich melde mich dann wieder mit den Ergebnissen. Wieder was gelernt.
Ich kann jetzt erst mal beruhigt schlafen gehen, denn soweit ist es mehr oder weniger plausibel
ich habe mir grad doch noch mal die Sophos Firewall angeschaut. Da war an einer Stelle "High Guarantee User" angeklickt. Das habe ich auf NONE gesetzt und kam auf ähnliche Werte, wie beim Direktzugriff von ESXI auf ZFS-NFS-Shares. Also zwischen 15-20 MB/s.
Ich habe danach testweise einen VM Client (OSX) ins gleiche Subnetz, wie das NAS gestellt (entsprechenden ESXI Port ausgewählt und IP im Client angepasst). Damit ist die Performance schon deutlich besser. Kabelgebunden 45 MB/s beim Übertragen eines ISO-Files.
Dann alles wieder auf Anfang und zuerst den Windows Client, wie von Dir empfohlen, auf VMXNET umgestellt. Und siehe da >90 MB/s. Plausibel. Die selbe Datein mit OSX uliegt bei etwa 45 MB/s. Schon deutlich besser
.napp-it läuft noch mit e1000, Sophos auch ... werde ich morgen mal auf vmxnet umstellen und sehen, wo das ausgeht. Ich melde mich dann wieder mit den Ergebnissen. Wieder was gelernt.
Ich kann jetzt erst mal beruhigt schlafen gehen, denn soweit ist es mehr oder weniger plausibel
Zuletzt bearbeitet:
So, back again
Ich habe meine napp-it-VM wie oben beschrieben, verdrahtet, also:
Napp-IT geht über EINEN dedizierten ESXI Port 02 --> ESXI vSwitch02 --> ESXI vmnic02 = physischer Netzwerkport 02 (1GBit) ins Heimnetz, alles 1GBit. Dabei habe ich als Treiber für die VM Netzwerkkarte vmxnet3 ausgewählt und in der VM eingerichtet. Es gibt keine weiteren Netzwerkkarten in der VM, ich betreibe das Ganze ja zu Hause, da reicht ein "Kanal" zum Server.
Zur Performance:
A) Die Geschwindigkeiten beim Zugriff auf den napp-it-Fileserver sind fast optimal, der 1GBit Strang wird sehr gut ausgenutzt. Alle Clients (auch OSX) lasten lan-gebunden den 1GB Strang optimal aus. Per WLAN sind es > 50 MB/s, auch nicht schlecht. Ausnahme bleibt: Die OSX VM. Mit ihr komme ich lan-gebunden auf maximal 50 MB/s. Ich vermute, dass der vmxnet3 Treiber von OSX nicht so perfekt läuft (macOS 10.12.3). Das Einrichten ist schon nicht so straight forward. Ist aber kein Beinbruch.
B) Was mich jedoch stutzig macht, ist der weiterhin "geringe" Datentransfer zwischen ESXI und napp-it-NFS. Ich habe im ESXI die napp-it-NFS Shares über die IP der napp-it Netwerkkarte gemountet und komme auf maximal 30-35 MB/s. Hier hatte ich deutlich mehr erwartet und verstehe nicht, warum das so ist? Bin für jeden Tipp dankbar.
Ich habe meine napp-it-VM wie oben beschrieben, verdrahtet, also:
Napp-IT geht über EINEN dedizierten ESXI Port 02 --> ESXI vSwitch02 --> ESXI vmnic02 = physischer Netzwerkport 02 (1GBit) ins Heimnetz, alles 1GBit. Dabei habe ich als Treiber für die VM Netzwerkkarte vmxnet3 ausgewählt und in der VM eingerichtet. Es gibt keine weiteren Netzwerkkarten in der VM, ich betreibe das Ganze ja zu Hause, da reicht ein "Kanal" zum Server.
Zur Performance:
A) Die Geschwindigkeiten beim Zugriff auf den napp-it-Fileserver sind fast optimal, der 1GBit Strang wird sehr gut ausgenutzt. Alle Clients (auch OSX) lasten lan-gebunden den 1GB Strang optimal aus. Per WLAN sind es > 50 MB/s, auch nicht schlecht. Ausnahme bleibt: Die OSX VM. Mit ihr komme ich lan-gebunden auf maximal 50 MB/s. Ich vermute, dass der vmxnet3 Treiber von OSX nicht so perfekt läuft (macOS 10.12.3). Das Einrichten ist schon nicht so straight forward. Ist aber kein Beinbruch.
B) Was mich jedoch stutzig macht, ist der weiterhin "geringe" Datentransfer zwischen ESXI und napp-it-NFS. Ich habe im ESXI die napp-it-NFS Shares über die IP der napp-it Netwerkkarte gemountet und komme auf maximal 30-35 MB/s. Hier hatte ich deutlich mehr erwartet und verstehe nicht, warum das so ist? Bin für jeden Tipp dankbar.
Ich hab mit dem Handy hier im Thread nichts dazu gefunden: nutzt hier jemand einen APC USV mit USB und fährt damit einen ESXi Host herunter?
Als Möglichkeit habe ich bisher nur die Variante gefunden, die apc an eine vm durchzureichen und dann per plink nen shutdown Befehl abzusetzen. Wozu man saß root / Administrator pw klartext in eine Datei schreiben muss. Mache ich im Notfall auch, aber vllt hat ja jemand eine elegantere Möglichkeit. Esx ist lizenziert. Vllt geht da ja auch was anderes?!
Gesendet von meinem Nexus 5X mit Tapatalk
Als Möglichkeit habe ich bisher nur die Variante gefunden, die apc an eine vm durchzureichen und dann per plink nen shutdown Befehl abzusetzen. Wozu man saß root / Administrator pw klartext in eine Datei schreiben muss. Mache ich im Notfall auch, aber vllt hat ja jemand eine elegantere Möglichkeit. Esx ist lizenziert. Vllt geht da ja auch was anderes?!
Gesendet von meinem Nexus 5X mit Tapatalk