ESX / ESXi - Hilfethread
- Ersteller XTaZY
- Erstellt am
Gibt es seitens ESXi eigentlich die Möglichkeit beim Ausfall einer Netzwerkarte sich benachrichtigen zu lassen oder das irgendwo ein Warnhinweis erscheint?
Ich habe eben mal meinem Mikrotik den Saft weggenommen und geschaut ob der Uplink auf die 1G Verbingung stattfindet. Passt, jedoch würde ich es scharmant finden wenn mich ESXi irgendwie aufmerksam macht wenn eine NIC ausfällt.
Ich habe eben mal meinem Mikrotik den Saft weggenommen und geschaut ob der Uplink auf die 1G Verbingung stattfindet. Passt, jedoch würde ich es scharmant finden wenn mich ESXi irgendwie aufmerksam macht wenn eine NIC ausfällt.
Normalerweise wird in der GUI angezeigt, dass die Uplink-Redundanz verloren gegangen ist, wenn einer von zwei Uplinks eines virtuellen Switches ausgefallen ist. Wenn Du aber z.B. zusätzlich zu 1x10 Gbit/s zwei Verbindungen á 1 Gbit/s auf dem selben virtuellen Switch hast, gibt es für den ESXi ja immer noch eine Uplink-Redundanz, deswegen gibt es da nur einen entsprechenden Eintrag im Ereignisprotokoll. Per SNMP/Syslog und der richtigen Abfrage/dem richtigen Filter dafür dürfte sich aber auch das abfangen lassen.
Thema Backup - mittlerweile gibts Veeam als Community Edition mit dem Standard Featureset für bis zu 10 VMs für Umme. Soll wohl der Nachfolger der Free sein. Wäre eigentlich ne ideale Lösung für Zuhause, da ich denke, 10 VMs dürften für ne zyklische Sicherung durchaus ausreichend sein für die Masse. Leider funktioniert der Spaß out of the box nicht ohne vCenter. Früher ging das mal, weis einer ob man das noch hinfingern kann???
Man kann wie in der Medizin das Symptom oder die Ursache bekämpfen.
Symptom ist, dass ESXi free die Möglichkeiten begrenzt,
Ursache ist lokal datastore mit seinen Einschränkungen in der Free Version.
Um die Ursache zu bekämpfen, verzichtet man darauf local datasore für VMs zu nutzen.
Die Alternativen sind ein SAN/NAS mit iSCSI oder besser NFS und am Besten NFS+ZFS.
Damit erschlägt man das Backup/Versionierungs Problem von ESXi, dazu wird backup
easy via "zfs send", man kann auf VMs via SMB und "previous Versions" zugreifen (clone/copy/backup).
Achja.
ESXi und local datastore ist langsam.
Schnell und sicher machen kann man das mit Hardware-Raid + Cache+ BBU
ZFS mit read+write caching im RAM ist schneller und mit gutem Slog auch viel sicherer.
Symptom ist, dass ESXi free die Möglichkeiten begrenzt,
Ursache ist lokal datastore mit seinen Einschränkungen in der Free Version.
Um die Ursache zu bekämpfen, verzichtet man darauf local datasore für VMs zu nutzen.
Die Alternativen sind ein SAN/NAS mit iSCSI oder besser NFS und am Besten NFS+ZFS.
Damit erschlägt man das Backup/Versionierungs Problem von ESXi, dazu wird backup
easy via "zfs send", man kann auf VMs via SMB und "previous Versions" zugreifen (clone/copy/backup).
Achja.
ESXi und local datastore ist langsam.
Schnell und sicher machen kann man das mit Hardware-Raid + Cache+ BBU
ZFS mit read+write caching im RAM ist schneller und mit gutem Slog auch viel sicherer.
Zuletzt bearbeitet:
Luckysh0t
Enthusiast
Wenn man Geas Vorschlag nicht nutzen kann oder will, empfehle ich als "Alternative" XSIBackup. Free VMWare ESXi backup solution: full featured
Wird direkt auf dem Host in ESXi installiert.
Wird direkt auf dem Host in ESXi installiert.
@gea Ich möchte das ergänzen, präzisieren. Ich bin mir sicher Du weißt das schon, aber für ESX-Neulinge ist das zum Teil verwirrend. Zumindest war es das für mich lange Zeit.
NAS mit NFS meint Dateifreigaben.
"SAN vs. NAS: Bei SANs greifen die Server über Fibre Channel auf Storage Devices im Blockverfahren zu. Ein NAS nutzen die Endanwender direkt per Ethernet, der Zugriff erfolgt auf Dateiebene. Eine 'Mischform' ist iSCSI - hier basiert der Dateizugriff auf Blockebene via Ethernet. (Quelle: Hewlett-Packard)" https://www.tecchannel.de/a/grundlagen-network-attached-storage,402522,4
What is difference between VMware VMFS and NFS datastore? - Quora Ich finde die Bilder hier zeigen es ganz gut.
Das Spannende an der Stelle ist, dass bei den Blockdatenspeichern das native vSphere Dateisystem VMFS auf dem Blockdatenspeicher verwendet werden kann. VMFS ist ein Dateisystem, welches für das Speichern von virtuellen Maschinen Dateien optimiert ist. Es wird auch immer weiter verbessert. Beispielsweise kam mit 6.0 UNMAP Unterstützung dazu.
Bei NFS hat vmWare weniger Möglichkeiten das Dateisystem den Hypervisor-Bedürfnissen anzupassen. NFS ist aber sehr beliebt, insbesondere, wenn es um günstigen Speicher geht. Daher hat vmWare den Support mit Version 5.0 hinzugefügt und immer weiter verbessert.
Für das Backup frage ich mich an der Stelle immer, wie das ZFS wissen will, ob die Daten nach oben hin konsistent sind. Also dieses Thema hier: VMware: "To Quiesce or not to Quiesce?" | Acronis Blog
Bei NFS mit ZFS würde ich bei Anwendungen mit Datenbank-Unterbau immer sicherheitshalber Datenbank-Backup-Dumps machen und dann ZFS-Snapshots.
Bei Veem, Hpe-Explorer@ Free und Iperius Backup habe ich die Erfahrung gemacht, dass sie mit klassischen Kopieroperationen über SSH arbeiten, sobald sie mit ESXi konfrontiert sind, womit man beim Backup sehr sehr langsam unterwegs ist. Hier fallen alle Optimierungen von VMFS oder NFS/ZFS weg. Wenn man eine leere Thin VMDK-Datei mit 1TB überträgt, dann überträgt man 1TB. Das geht mit iSCSI in Sekunden da VMFS entsprechende Features bietet.
XSIBackup versucht das Problem auf dem Hypervisor zu lösen. D.h. hier können dann ESXi Features wie die vmkfstools verwendet werden. Es werden auch Funktionen direkt auf dem Hypervisor nachgerüstet. Das funktioniert in der Praxis sehr gut. Hat aber auch ein Geschmäckle. Die beim Backup entstehenden Lasten werden nicht ebensogut verteilt, wie es das VADP kann. Für den Heimbereich und kleine Unternehmen halte ich das dennoch für eine gute Lösung.
Die Datastores an sich haben soweit ich weiß keinerlei Einschränkungen. Die Beschränkung liegt in dem Fehlen "VMware vSphere Storage APIs – Data Protection" kurz VADP in ESXi. Allen ESXi Nutzer fehlt da ein ganz essentielles API und die Frage beim Thema "ESXi-Backup" ist, wie kommt man ohne dieses API aus?
SAN/NAS mit iSCSI meint Blockdatenspeicher. Der kann lokal oder über das Netzwerk bereitgestellt werden. Zur Auswahl stehen iSCSI, Fibre Channel oder FCoE.
NAS mit NFS meint Dateifreigaben.
"SAN vs. NAS: Bei SANs greifen die Server über Fibre Channel auf Storage Devices im Blockverfahren zu. Ein NAS nutzen die Endanwender direkt per Ethernet, der Zugriff erfolgt auf Dateiebene. Eine 'Mischform' ist iSCSI - hier basiert der Dateizugriff auf Blockebene via Ethernet. (Quelle: Hewlett-Packard)" https://www.tecchannel.de/a/grundlagen-network-attached-storage,402522,4
What is difference between VMware VMFS and NFS datastore? - Quora Ich finde die Bilder hier zeigen es ganz gut.
Das Spannende an der Stelle ist, dass bei den Blockdatenspeichern das native vSphere Dateisystem VMFS auf dem Blockdatenspeicher verwendet werden kann. VMFS ist ein Dateisystem, welches für das Speichern von virtuellen Maschinen Dateien optimiert ist. Es wird auch immer weiter verbessert. Beispielsweise kam mit 6.0 UNMAP Unterstützung dazu.
Bei NFS hat vmWare weniger Möglichkeiten das Dateisystem den Hypervisor-Bedürfnissen anzupassen. NFS ist aber sehr beliebt, insbesondere, wenn es um günstigen Speicher geht. Daher hat vmWare den Support mit Version 5.0 hinzugefügt und immer weiter verbessert.
Aus meiner Sicht ist der Trick hier, mit dem unterhalb von NFS operierenden Dateisystem, die Schwächen die NFS gegenüber VMFS hat wieder auszugleichen. Also man verliert etwas, da kein natives VMFS und man gewinnt etwas, wegen des sehr gutes Dateisystems unterhalb von NFS.
"local datastore" gibt es in dem Sinne ja nicht. Es gibt ein Blockdevice und wenn das eine einzelne HDD ist, dann ist die so schnell wie eine einzelne HDD eben schnell ist. Wenn da ein fettes SAN dahintersteht, dann ist das Hammerschnell.
...als ohne.
Für das Backup frage ich mich an der Stelle immer, wie das ZFS wissen will, ob die Daten nach oben hin konsistent sind. Also dieses Thema hier: VMware: "To Quiesce or not to Quiesce?" | Acronis Blog
Bei NFS mit ZFS würde ich bei Anwendungen mit Datenbank-Unterbau immer sicherheitshalber Datenbank-Backup-Dumps machen und dann ZFS-Snapshots.
Bei Veem, Hpe-Explorer@ Free und Iperius Backup habe ich die Erfahrung gemacht, dass sie mit klassischen Kopieroperationen über SSH arbeiten, sobald sie mit ESXi konfrontiert sind, womit man beim Backup sehr sehr langsam unterwegs ist. Hier fallen alle Optimierungen von VMFS oder NFS/ZFS weg. Wenn man eine leere Thin VMDK-Datei mit 1TB überträgt, dann überträgt man 1TB. Das geht mit iSCSI in Sekunden da VMFS entsprechende Features bietet.
XSIBackup versucht das Problem auf dem Hypervisor zu lösen. D.h. hier können dann ESXi Features wie die vmkfstools verwendet werden. Es werden auch Funktionen direkt auf dem Hypervisor nachgerüstet. Das funktioniert in der Praxis sehr gut. Hat aber auch ein Geschmäckle. Die beim Backup entstehenden Lasten werden nicht ebensogut verteilt, wie es das VADP kann. Für den Heimbereich und kleine Unternehmen halte ich das dennoch für eine gute Lösung.
So langsam finde ich Iperius jetzt nicht. Bei uns ESXI Datastore auf NVME (VMS6) über 10 Gbit auf Sata SSD und dann normale Kopieraktion auf Sata Raid 1 Festplatten, und von da nochmal normale Kopieraktion auf 2 ten Raid 1 Festplattenverbund.
Blöd finde ich das es nicht synchron die beiden Raids bestückt sondern nacheinander. Zugriff kommt von einem Extra Windows 2019 Standard Server. Der macht auch nichts anderes.
Full Backup 6 VM @ 60-80 GB + 2 mal kopieren
Ich muss mal nachschauen wie lange das eigentlich Backup ohne die 2 extra Kopien auf die Festplatten dauert. Aber vom Speed her eigentlich okay ( erster Empfänger Sata SSD).
Zuletzt bearbeitet:
PhoenixZerodown
Neuling
- Mitglied seit
- 04.09.2018
- Beiträge
- 8
Leider nein. Früher ging das wohl unter anderem, weil in manchen ESXi Versionen die APIs, die Veeam benötigt auch nach Eingabe des ESXi Free Lizenzschlüssels nicht deaktiviert wurden. Die Free Edition von Nakivo kann aber, genauso wie Synology Active Backup for Business über ein manuell konfiguriertes CBT der VMs dies aber "umgehen".
AliManali
cpt sunday flyer
Hi
Habt Ihr mit 6.7.0 Update 3 (Build 14320388) auch das Problem, dass man die Secure Shell nach jedem Neustart aktivieren muss? Ist hier mit beiden Hosts so.
Habt Ihr mit 6.7.0 Update 3 (Build 14320388) auch das Problem, dass man die Secure Shell nach jedem Neustart aktivieren muss? Ist hier mit beiden Hosts so.
Trambahner
Urgestein
Bleibt an bei mir. Aktiviert über das DCUI btw.
Elektromat
Experte
Hallo Zusammen,
aktuell habe ich folgende Problematik. Ich hoffe mal ich bin hier zumindest halbwegs richtig. Wenn nicht bitte Info.
Ich musste aus diversen anlässen meinen ESXi und meinen Solaris Filer neu aufsetzen.
Die ZFS Pools hab ich problemlos Importiert, und diese stehen ohne Probleme bereit (NFS Share für den ESXI und SMB Shares).
So weit so gut.
Nun habe ich allerdings die Problematik das wenn ich meine VMs aus dem NFS Mount im ESXI wiederherstelle, das wenn ich die Ubuntu 18.4.3 LTS VM starte, das vermutlich diverse mountpoints nur noch ReadOnly eingehängt werden.
Nach dem Login in der ESXI Konsole kommt folgende Meldung:
Einen Snapshot Restore meines VMStores hab ich bereits versucht, leider ohne Erfolg. Nach restore meiner VM bleiben die Fehlermeldungen bestehend.
Folgenden Link habe ich hierzu gefunden:
https://askubuntu.com/questions/197459/how-to-fix-sudo-unable-to-open-read-only-file-system
Bringt mir:
sudo: unable to resolve host ...: Resource temporarily unavailable
Hatte jemand schon jemand selbige Probleme mit Ubuntu VMs nach einem Restore, und ggf. ne passende lösung?
Danke.
Grüße
Elektromat
aktuell habe ich folgende Problematik. Ich hoffe mal ich bin hier zumindest halbwegs richtig. Wenn nicht bitte Info.
Ich musste aus diversen anlässen meinen ESXi und meinen Solaris Filer neu aufsetzen.
Die ZFS Pools hab ich problemlos Importiert, und diese stehen ohne Probleme bereit (NFS Share für den ESXI und SMB Shares).
So weit so gut.
Nun habe ich allerdings die Problematik das wenn ich meine VMs aus dem NFS Mount im ESXI wiederherstelle, das wenn ich die Ubuntu 18.4.3 LTS VM starte, das vermutlich diverse mountpoints nur noch ReadOnly eingehängt werden.
Nach dem Login in der ESXI Konsole kommt folgende Meldung:
Einen Snapshot Restore meines VMStores hab ich bereits versucht, leider ohne Erfolg. Nach restore meiner VM bleiben die Fehlermeldungen bestehend.
Folgenden Link habe ich hierzu gefunden:
https://askubuntu.com/questions/197459/how-to-fix-sudo-unable-to-open-read-only-file-system
Code:
sudo mount -o remount,rw /sudo: unable to resolve host ...: Resource temporarily unavailable
Hatte jemand schon jemand selbige Probleme mit Ubuntu VMs nach einem Restore, und ggf. ne passende lösung?
Danke.
Grüße
Elektromat
Klingt nach einem Rechteproblem.
Wenn das Dateisystem selber r/w ist und auch für NFS keine Einschränkungen gesetzt wurden:
Ich würde das Dateisystem rechtemäßig rekursiv auf everyone=full oder modify setzen.
Entweder perl CLI und /usr/bin/chmod, per SMB und Windows (als root) oder napp-it unter Dateisysteme > ACL on folder
Wenn das Dateisystem selber r/w ist und auch für NFS keine Einschränkungen gesetzt wurden:
Ich würde das Dateisystem rechtemäßig rekursiv auf everyone=full oder modify setzen.
Entweder perl CLI und /usr/bin/chmod, per SMB und Windows (als root) oder napp-it unter Dateisysteme > ACL on folder
Elektromat
Experte
Danke für deine Rückmeldung.
So ist die ACL on Folder Konfig zum VMStore aus Napp-it:
könnte es daran schon liegen? Leider kenn ich mich mit dem Thema berechigungen im Solaris nicht wirklich gut aus.
NFS steht nur auf on wie so weit ich mich erinner vorher auch.
Im ESXI ist der Pool nur eingehängt, hier war keine Einstellmöglichkeit zu RW oder RO.
So ist die ACL on Folder Konfig zum VMStore aus Napp-it:
könnte es daran schon liegen? Leider kenn ich mich mit dem Thema berechigungen im Solaris nicht wirklich gut aus.
NFS steht nur auf on wie so weit ich mich erinner vorher auch.
Im ESXI ist der Pool nur eingehängt, hier war keine Einstellmöglichkeit zu RW oder RO.
Zuletzt bearbeitet:
Elektromat
Experte
- - - Updated - - -
Ich habe mal weiter getestet. Die berechtigungen sind bzw. habe ich recursiv gesetzt.
Ebenfalls habe ich in diesem Atemzug das Mainboard Bios und die FW auf aktuellen stand gebracht (nen Reset der BIOS konfig hab ich noch nicht versucht).
Die Problematik betrifft jede Ubuntu VM, auch neu Installationen, und auch auf jedem Laufwerk welches dem ESXI bereit steht. Interne wie auch extere NFS mounts. Ich werde das ganze noch einmal erneut aufsetzen, in der Hoffnung das der Fehler dann weg ist.
Sehr merkwürdig.
Ich habe mal weiter getestet. Die berechtigungen sind bzw. habe ich recursiv gesetzt.
Ebenfalls habe ich in diesem Atemzug das Mainboard Bios und die FW auf aktuellen stand gebracht (nen Reset der BIOS konfig hab ich noch nicht versucht).
Die Problematik betrifft jede Ubuntu VM, auch neu Installationen, und auch auf jedem Laufwerk welches dem ESXI bereit steht. Interne wie auch extere NFS mounts. Ich werde das ganze noch einmal erneut aufsetzen, in der Hoffnung das der Fehler dann weg ist.
Sehr merkwürdig.
Zuletzt bearbeitet:
Elektromat
Experte
Ich hab den fehler gefunden. Lag am ubuntu selbst. Die ACLs waren es nicht.
Ist zwar etwas Off topic aber wen es interssiert.
Dateisystem bereinigen mit sudo fsck.ext4 -f /dev/sda2 hat den/die fehler behoben.
Ist zwar etwas Off topic aber wen es interssiert.
Dateisystem bereinigen mit sudo fsck.ext4 -f /dev/sda2 hat den/die fehler behoben.
Hallo,
ich hab eine grundlegende Frage zum Passthrough von onboard Chips.
Ich habe zwei SATA Controller Marvell 9230 einer rev A0 (onboard) einer A1 PCIE Karte.
Die Karte kann durchgereicht werden ohne Probleme die läuft problemlos, der Onboard Controller macht auch erstmal keine Probleme aber im System sind nur Ports 1 und 3 nutzbar.
Der Onboard Controller ist ins UEFI eingebettet und zeigt beim Systemstart nichts an, er ist erreichbar durch das UEFI.
Kann es sein, dass er deswegen nicht richtig initialisiert wird beim Passthrough?
MfG Basti
ich hab eine grundlegende Frage zum Passthrough von onboard Chips.
Ich habe zwei SATA Controller Marvell 9230 einer rev A0 (onboard) einer A1 PCIE Karte.
Die Karte kann durchgereicht werden ohne Probleme die läuft problemlos, der Onboard Controller macht auch erstmal keine Probleme aber im System sind nur Ports 1 und 3 nutzbar.
Der Onboard Controller ist ins UEFI eingebettet und zeigt beim Systemstart nichts an, er ist erreichbar durch das UEFI.
Kann es sein, dass er deswegen nicht richtig initialisiert wird beim Passthrough?
MfG Basti
Elektromat
Experte
Servus,
mein vSphere Client protokolliert mir aktuell zwei Fehler:
Fehler 1 betrifft nur meine Solaris VM, da ich in den Einstellungen definiert habe, das er den komplettem zugewiesenen RAM verwenden soll.
Fehler 2 betrifft meinen Server (HOST siehe Signatur). Hier im genauen FAN4. Folgend die Werte aus dem IPMITOOL zu FAN4:
Folgend der Auszug aus den Sensor Readings
Hier sind alle Fans grün. Somit frag ich mich, warum der Fehler überhaupt Protokolliert wird.
Jemand ne idee wie ich die Fehler entfernt bekomme?
Also bei Fehler 1 die Fehlermeldung für nur die Solaris VM zu deaktivieren?
Bei Fehler 2 den FAN 4 dazu zu bringen ohne Fehler angezeigt zu werden im ESXi.
Grüße
Elektromat
mein vSphere Client protokolliert mir aktuell zwei Fehler:
Fehler 1 betrifft nur meine Solaris VM, da ich in den Einstellungen definiert habe, das er den komplettem zugewiesenen RAM verwenden soll.
Fehler 2 betrifft meinen Server (HOST siehe Signatur). Hier im genauen FAN4. Folgend die Werte aus dem IPMITOOL zu FAN4:
Folgend der Auszug aus den Sensor Readings
Hier sind alle Fans grün. Somit frag ich mich, warum der Fehler überhaupt Protokolliert wird.
Jemand ne idee wie ich die Fehler entfernt bekomme?
Also bei Fehler 1 die Fehlermeldung für nur die Solaris VM zu deaktivieren?
Bei Fehler 2 den FAN 4 dazu zu bringen ohne Fehler angezeigt zu werden im ESXi.
Grüße
Elektromat
Zuletzt bearbeitet:
Fehler 1 ist kein Fehler sondern ein aus ESXi Sicht unerwartetes Verhalten. Eine VM die allen zugewiesenen Speicher weitgehend komplett und dauerhaft nutzt (als ZFS Cache) ist "verdächtig". ESXi unterscheidet da leider nicht ob der Speicher fest zugewiesen wurde oder wie bei normalen VMs variabel zugewiesen wird (wo die Fehlermeldung ja Sinn hätte).
Ich habe die Meldung auch in Vsphere, habe aber noch nicht geschaut ob man nur die Meldung deaktivieren kann.
Ich habe die Meldung auch in Vsphere, habe aber noch nicht geschaut ob man nur die Meldung deaktivieren kann.
Elektromat
Experte
Klar, es liegt an der im Standard definierten Alarm-Regel. Ich könnte mich einfach innerhalb der folgenden Regel bezüglich der VM Speichervergabe bewegen, aber dann habe ich im schlimmsten Falle 15% nicht fix vergebenen Speicher dieser VM. Nicht genutzter RAM ist schlechter RAM. Die Meldung ist nicht dramatisch, aber es wäre schon super wenn man die Meldung irgendwie weg bekommen könnte. Im besten falle als Ausnahme für bestimmte VMs.
Wenn doch in der VM Konfig die Einstellung möglich ist, das der komplette der VM zugewiesene Speicher verwendet wird, muss es doch eine Lösung geben. Oder ist mein Denkansatz hier falsch.
Mein Gedanke dazu ist halt, das wenn wirklich mal ein Fehler aufkommt man diesen im schlimmsten Falle nicht sofort wahrnimmt, wenn in bestimmten anwendungsfällen falsche Fehler ausgegeben werden.
Zuletzt bearbeitet:
Trambahner
Urgestein
Weniger Frage, mehr eine Erfolgsmeldung. Ich hab heute mal meinen alten i7-3770 (uralte Win7-Installation, natürlich mit allen möglichen alten Intel-Treibern drin) nach 6.7U3 auf meinen 1920X@X399D8A mittels Converter virtualisiert.
Ein paar Reboots, Vmwaretools dannach installiert, die VMXNET3 entsprechend meinen Vorstellungen eingestellt. Läuft alles stabil.
Hab dann drauf noch den Chipsatzkram und ausgeblendete Geräte entfernt.
Einzig Windows wollte neu aktiviert werden (wollte via Telefonbot ne neue Install-ID), was aber kein Problem war.
Ein paar Reboots, Vmwaretools dannach installiert, die VMXNET3 entsprechend meinen Vorstellungen eingestellt. Läuft alles stabil.
Hab dann drauf noch den Chipsatzkram und ausgeblendete Geräte entfernt.Einzig Windows wollte neu aktiviert werden (wollte via Telefonbot ne neue Install-ID), was aber kein Problem war.
Hier der offizielle VMware KB Artikel dazu:
Memory usage alarm triggers for certain types of Virtual Machines in ESXi 6.x (2149787)
JohnnyBGoode
Enthusiast
- Mitglied seit
- 29.01.2010
- Beiträge
- 1.122
Wollte um Rat für eine vörübergehende NAS-Lösung fragen:
Eigentlich wollte ich schon seit Monaten ein ESXi-NAS mit Oracle Solaris + napp-it Pro verwenden, um über 40 GbE-Netzwerk nach und nach Daten von "alten" LSI-Hardware-RAID-Volumes nach ZFS zu überführen.
Leider bekommt es ASRock Rack beim X470D4U nicht auf die Reihe, ein BIOS für Ryzen 3000 mit AGESA 1.0.0.3 ABB oder neuer zu veröffentlichen, so dass bei dieser Kombination RDRAND noch kaputt ist und ESXi beim Booten abstürzt (aktueller Stand BIOS 3.20, BMC 1.60). Das IPMI ist bug-mäßig auch ziemlicher Mist (lässt sich nach gut einer Woche nicht mehr erreichen, BMC muss einen Reset machen, damit es wieder eine Weile funktioniert).
Windows 10 läuft dagegen absolut stabil, wenn man das Board wie ein Desktop-System betreibt.
Kann ich mittels VMware Workstation (Lizenz vorhanden) eine Oracle Solaris-VM mit napp-it Pro (Privatlizenz vorhanden) unter Windows laufen lassen und dieser VM dann die Datenträger, die die VM später via PCIe-Passthrough des HBAs bekommt, mit der VMware-"Datenträger-Durchreichen"-Funktion, die es auch unter Windows/VMware Workstation gibt, einrichten und schonmal zumindest mit eingeschränkter Performance nutzen?
Mir geht es auch darum, dass ich diese dann bereits aktiv verwendeten Datenträger später im ordentlichen ESXi-NAS-Betrieb "sicher" einfach weiterverwenden kann, ohne XX TB wieder neu kopieren zu müssen.
Vielen Dank für die Anregungen!
(Bin bei dem Thema mittlerweile ziemlich frustriert da ich noch nie so schlechten BIOS-Support erlebt habe)
Eigentlich wollte ich schon seit Monaten ein ESXi-NAS mit Oracle Solaris + napp-it Pro verwenden, um über 40 GbE-Netzwerk nach und nach Daten von "alten" LSI-Hardware-RAID-Volumes nach ZFS zu überführen.
Leider bekommt es ASRock Rack beim X470D4U nicht auf die Reihe, ein BIOS für Ryzen 3000 mit AGESA 1.0.0.3 ABB oder neuer zu veröffentlichen, so dass bei dieser Kombination RDRAND noch kaputt ist und ESXi beim Booten abstürzt (aktueller Stand BIOS 3.20, BMC 1.60). Das IPMI ist bug-mäßig auch ziemlicher Mist (lässt sich nach gut einer Woche nicht mehr erreichen, BMC muss einen Reset machen, damit es wieder eine Weile funktioniert).
Windows 10 läuft dagegen absolut stabil, wenn man das Board wie ein Desktop-System betreibt.
Kann ich mittels VMware Workstation (Lizenz vorhanden) eine Oracle Solaris-VM mit napp-it Pro (Privatlizenz vorhanden) unter Windows laufen lassen und dieser VM dann die Datenträger, die die VM später via PCIe-Passthrough des HBAs bekommt, mit der VMware-"Datenträger-Durchreichen"-Funktion, die es auch unter Windows/VMware Workstation gibt, einrichten und schonmal zumindest mit eingeschränkter Performance nutzen?
Mir geht es auch darum, dass ich diese dann bereits aktiv verwendeten Datenträger später im ordentlichen ESXi-NAS-Betrieb "sicher" einfach weiterverwenden kann, ohne XX TB wieder neu kopieren zu müssen.
Vielen Dank für die Anregungen!
(Bin bei dem Thema mittlerweile ziemlich frustriert da ich noch nie so schlechten BIOS-Support erlebt habe)
Vmware Workstation ist untauglich (kein pass-through) und langsam da es als normales Programm unter Windows läuft.
IPMI ist nicht unbedingt nötig. Da kann man auf eine neue Version warten. Speicher ist natürlich kritisch. Manchmal kann man aber im Bios was machen indem man Spannung höhersetzt oder Takt reduziert. Man kann auch mal die eine Hälfte des RAM probieren, dann die andere, falls der RAM Probleme macht.
ps
Wenn ESXi wegen RAM abstürzt, wird Windows das auch tun wenn man was macht was den Speicher braucht.
IPMI ist nicht unbedingt nötig. Da kann man auf eine neue Version warten. Speicher ist natürlich kritisch. Manchmal kann man aber im Bios was machen indem man Spannung höhersetzt oder Takt reduziert. Man kann auch mal die eine Hälfte des RAM probieren, dann die andere, falls der RAM Probleme macht.
ps
Wenn ESXi wegen RAM abstürzt, wird Windows das auch tun wenn man was macht was den Speicher braucht.
JohnnyBGoode
Enthusiast
- Mitglied seit
- 29.01.2010
- Beiträge
- 1.122
RDRAND hat nichts mit RAM zu tun (die 128 GB UDIMM ECC laufen einwandfrei), sondern der Hardware-Zufallszahlengenerator. Bei Ryzen 3000/Zen 2 ist dieser defekt, wenn ein BIOS mit AMDs AGESA älter als 1.0.0.3 ABB verwendet wird. Die Geschichte ist eigentlich seit Ende Juli/Anfang August mit einem Update gefixt, ASRock Rack ist jedoch bislang nicht in der Lage, ein entsprechendes neues BIOS herauszubringen.
ESXi benutzt dies leider (wie auch beispielsweise Fedora 30 in der vanilla Release-Version) und stürzt dann beim Booten ab.
Dass Workstation langsamer ist als normal ist klar, es hat jedoch so etwas wie RDM ohne Passthrough, was ich verwenden wollte.
ESXi benutzt dies leider (wie auch beispielsweise Fedora 30 in der vanilla Release-Version) und stürzt dann beim Booten ab.
Dass Workstation langsamer ist als normal ist klar, es hat jedoch so etwas wie RDM ohne Passthrough, was ich verwenden wollte.
Zuletzt bearbeitet:
besterino
Legende
@JohnnyBGoode: bevor du da mit vm Workstation rumhantierst, würde ich eher versuchen solaris + napp-it mal auf's Blech zu installieren. Damit kannst Du jedenfalls dann den neuen Pool schon einmal anlegen.
JohnnyBGoode
Enthusiast
- Mitglied seit
- 29.01.2010
- Beiträge
- 1.122
Ja, mit dem direkt auf's Blech habe ich auch schon geliebäugelt.
Vielleicht etwas seltsame aber ernstgemeinte Frage, eventuell nehme ich dann ein anderes System her, bis es ASRock Rack auf die Reihe bekommt: Kann Solaris mit Intel Thunderbolt (3) bzw. dessen "Ethernet Bridge"-Funktion umgehen? Wenn man beispielsweise ein Laptop mit TB mit einem anderen Computer mit TB verbindet, erscheint eine virtuelle 20/40 GbE-Intel-Netzwerkkarte und entsprechend flott kann man Daten übertragen
Vielleicht etwas seltsame aber ernstgemeinte Frage, eventuell nehme ich dann ein anderes System her, bis es ASRock Rack auf die Reihe bekommt: Kann Solaris mit Intel Thunderbolt (3) bzw. dessen "Ethernet Bridge"-Funktion umgehen? Wenn man beispielsweise ein Laptop mit TB mit einem anderen Computer mit TB verbindet, erscheint eine virtuelle 20/40 GbE-Intel-Netzwerkkarte und entsprechend flott kann man Daten übertragen
besterino
Legende
Äh... keine Ahnung aber ich behaupte mal „nein“. Desktop-Gedöns und Fummelei geht in der Regel (mangels Treibern) eher nicht.