[Sammelthread] ZFS Stammtisch

[L0rD_LuCk]

Guten Abend,

ich noch mal. Bin jetzt dabei die Daten von den Clients und dem alten Server auf den neuen Solaris Server zu überspielen. Dabei ist mir aufgefallen, dass beim empfangen von Daten alle 70 Sekunden der Traffic auf 0 MiB/s abfällt (siehe Bild)

Woran kann das liegen? Zum Test habe ich auch mal von zwei Rechnern parallel auf den Solaris Server kopiert, aber es hat sich nichts geändert. Der drop kommt genau alle 70 Sekunden?

Vielen Dank und viele Grüße
L0rD_LuCk

 

[gea]

Ich muss auf die Replikations-Jobs nochmals zurück kommen, da ich ungern jetzt nach dem Update meine Sicherungen verlieren möchte.

AIO=Source
Ripley= Target

Auf AIO hab ich 3 zugehörige Snaps, auf Ripley sind es über 250 Snaps. ==> für mich ist es so OK, so kann ich bis zum 01.10.2015 zurückgehen.
In den Job-Parametern ist aber zu sehen, dass keep und hold so belegt sind:
keep=
hold=30
Nach deinen beiden Posts vom 11.12. dürften aber nur die 30 jüngsten (Tages-)Snaps auf dem Target-System sein.
Meine Vermutung ist, dass es bei der v0.9 noch nicht optimal so gelaufen ist und dadurch die ältesten 230 Snaps nicht gemäß Einstellungen gelöscht wurden - kann das sein?

Muss ich, um die 250 Target-Snaps zu behalten in keep einen . Punkt eintragen und Variable hold leer lassen?
Die Anzahl der Repli-Snaps auf dem Source-System ist von dir per hardcoded auf 3 Stk. festgelegt?

Bi den Keep Einstellungen für einen Replikationsjob kann man einen Punkt setzen. Dann werden aber alle alten und künftige Snaps behalten. Das werden dann ganz schnell sehr viele. Da sollte man dann wenigstens ab und zu ein Snapshot-Mass-Delete laufen lassen, z.B. mit lösche alle Snaps älter als 30 Tage inkl. Replikationssnaps - behalte aber immer den ersten des Monats der Woche oder des Tags.

Die Alternative um einzelne ältere Snaps zu halten wäre diese umzubenennen, auch könnte man die Job-id und die beiden aktuellen Snaps entsprechend umbenennen. Das würde alle älteren Snaps aus der Automatik herausnehmen. Alternativ eine neue Replikation anlegen. Damit bliebe das alte Filesystem komplett erhalten.


Auf dem Quellsystem bleiben immer die letzten drei Snaps. Wenn man da mehr braucht: Autosnap aktivieren. Das beißt sich mit den Replikationssnaps allenfalls wenn man da die delzero Funktion aktiviert. Das könnte Probleme geben wenn der letzte Replikationssnap und der darauf folgende Autosnap =0 wäre.

- - - Updated - - -

Guten Abend,

ich noch mal. Bin jetzt dabei die Daten von den Clients und dem alten Server auf den neuen Solaris Server zu überspielen. Dabei ist mir aufgefallen, dass beim empfangen von Daten alle 70 Sekunden der Traffic auf 0 MiB/s abfällt (siehe Bild)
Anhang anzeigen 385095
Woran kann das liegen? Zum Test habe ich auch mal von zwei Rechnern parallel auf den Solaris Server kopiert, aber es hat sich nichts geändert. Der drop kommt genau alle 70 Sekunden?

Vielen Dank und viele Grüße
L0rD_LuCk

Die CPU Kurve zeigt die gepulste Aktivität durch den Schreibcache (alle 5s), für den Netzwerk-Einbruch alle 70s habe ich keine Erklärung. Ich würde mal die tcp-Buffer erhöhen, z.B. auf (Napp-it System- > Tuning oder CLI Befehl)

max_buf=4097152 tcp
send_buf=2048576 tcp
recv_buf=2048576 tcp

Alternativ einen deutlich schnelleren Pool (z.B. SSD Pool) vergleichen. Evenuell kommen ja übers Netz mehr Daten als der Pool iops mäßig kann.

 

[bogomil22]

@gea:
Da sich aus meiner Sicht ZoL (speziell Proxmox) als fast schon bessere Alternative als VMware-AIO für den Home-Bereich entwickelt, wollte ich mal fragen ob Napp-It auf Proxmox/Debian/Linux lauffähig ist bzw. welche Einschränkungen z.Z. vorhanden sind ?

 

[gea]

Es gibt hier ja drei Aspekte

1. Eignung als Virtualisierungsumgebung
2. Eignung als (ZFS) Storage
3. Eignung als AiO System das beides kann

zu 1.
Von der Virtualisierungsseite ist ESXi als Typ-1 Syste ein Minimalsystem, eigentlich eher eine Bioserweiterung.
Wenn es darum geht ein beliebiges vollwertiges OS zu virtualisieren, gerne auch mit Hardware Pass-through so ist ESXi schlicht unschlagbar. Auch die Wiederherstellung von ESXi und laufenden VMs ist unschlagbar schnell und einfach.

Nachteil
- HA Funktionen oder zentrales Management kostet richtig Geld
- nur Vollvirtualisierung, kein lightweight wie Linux Container/ Linux VMs mit Docker

Speziell in diesen Fragen punktet Proxmox (oder andere Lightweight Containerlösungen wie LX/Linux Zones auf SmartOS oder OmniOS)

Virtualisierung innerhalb eines Full Featured OS hat auch den Vorteil, dass man weitere Dienste (Mediaserver, Webserver) etc direkt auf dem Basis-OS laufen lassen kann. Für mich aber ein Nachteil. Damit wird die Einrichtung komplex und man muss sich um Backup und Updates Gedanken machen. Würde ich immer vermeiden. Eine "nur Storage VM" ist in 2 Minuten wieder aus einem Template aufgesetzt

zu 2.
Hier ist es zunächst eine OS Frage und da ist für mich klar dass Solaris schon immer und immer noch die absolut beste ZFS Integration in das OS hat. Wenn es Solaris nicht mehr gäbe würde ich zu BSD wechseln. Gäbe es das nicht würde ich in den sauren Apfel beißen und einen der vielen Linux-Fischertechnik Baukästen wählen.

Es zählt aber nicht nur das ZFS Dateisystem. Den Komfort, den eine ZFS Storage Appliance wie NexentaStor oder Solaris/OmniOS + napp-it oder FreeNAS/Nas4Free unter BSD bietet, gibts schlicht unter Linux nicht und wird es wohl auch nie geben, da ZFS hier nur eins von vielen Dateisystemen ist und so viel anders tickt als ext4/LVM. Auch napp-it unter Linux oder meinetwegen OMV+ZFS ist da nichts dagegen.


zu 3.
Hier kommts auf den Mix an und vor allem darauf wie wichtig die Linux Containerlösungen wie Docker sind.
Ansonsten sehe ich ESXi + ZFS Storage VM mit pass-through + sonstige VMs als konkurrenzlos, vor allem wenn es nicht nur um Linux VMs geht und eine vollwertige Storage Appliance gewünscht ist.

 

[Trambahner]

Ich würd ja von BSD auf Solarish + napp-it umsteigen, wenn man unter ESXI ne NVMe-SSDs (sprich ne Intel 750er oder DC P3600 / P3700 ) durchreichen könnte; dat klappt noch nicht.

 

[Bib]

Ich habe derzeit FreeNAS 9.10 installiert. Dort kann man die HDDs nicht schlafen legen, weil irgend ein System Dataset auf den Platten liegt und daher die HDDs nie in Standby gehen. Gut, kann man irgendwie verschieben, aber wenn das Dataset weg ist, dann sind wohl auch die Daten irgendwie weg?


OMV hat das "Problem" anscheinend nicht, da gibts sowas wohl einfach nicht?

Wie sieht es denn hier mit Solaris / napp-it aus? Gibts da sowas oder könnte man hier die HDDs problemlos schlafen legen?



Über den Sinn von "HDD Standby" (erhöhter Verschleiss usw) möchte ich hier nicht diskutieren, mir gehts nur um das ob, wie und warum...

 

[Trambahner]

Bei Nas4free gehts; auch an SAS-Adaptern. Zumindest bei 10.3 hatte ich das so in Nutzung. Nachdem ich auf 11.0 umgestellt hab, habe ichs noch nicht getestet/konfiguriert.

 

[Bib]

Also ist das System Dataset auf den jeweiligen HDDs dann eine Eigenart von FreeNAS?


Ich habe: ESXI auf USB-Stick, dann die VMs auf einer SSD (unter anderem auch FreeNAS) und dann HDDs über einen durchgereichten Controller direkt in FreeNAS.

 

[gea]

ESXi + OmniOS + NVMe Pass-through

Da gabs eine Diskussion mit Frank Ende Oktober 2016 (ist ab und an auch hier im Forum) in der Illumos-Discuss Mailliste dazu. Es ist wohl auch inzwischen klar, wo das Problem liegt. Ich habe jedoch noch kein Update des Treibers gesehen. Ich hoffe dass das bald gefixt wird. NVMe als L2ARC oder Slog unter ESXi ist wünschenswert. Mit ausreichend RAM und SSD only Pools ist beides aber obsolet.

https://www.mail-archive.com/discuss@lists.illumos.org/msg02675.html

zu Sleep
Ich habe auch schon gelesen, dass Sleep mit FreeNAS auch geht.
Unter OmniOS funktioniert sleep. Man muss halt darauf schauen, dass kein Prozess regelmäßig zugreift - auch nicht der Solaris Fault Management Service fmd (deaktivieren).

Systempool/Rpool wird aber nicht schlafen. Da das bei Solarish aber immer eine eigene Platte/ SSD/ USB Stick ist, ist das kein Problem für die Platten des Datenpools.

- - - Updated - - -

Also ist das System Dataset auf den jeweiligen HDDs dann eine Eigenart von FreeNAS?

Bei Solarish ist die Systemplatte schon immer ein ZFS Dateisystem auf einem Basis oder Mirror vdev, Man könnte da auch Dateisysteme z.B. für SMB anlegen, das ist aber extrem unüblich. Datenpools sind praktisch immer extra Pools auf eigenen Platten.

FreeNAS/BSD arbeitet da nicht anders.
Man kann aber bei BSD auch von einem Raid-Z Pool oder einer nicht-ZFS Platte booten was OmniOS noch nicht kann (Illumos portiert aber gerade wegen der Raid-Z Option den BSD Bootloader). Diese Option ist aber nur für einfachsten Heimeinsatz sinnvoll da man damit die Bootplatte sparen kann, ansonst ein NoGo und Platten schlafen geht dann auch nicht.

 

[Bib]

Hilft mir das jetzt bei meiner Frage weiter? Das einzige was ich jetzt rauslesen konnte, ist dass napp-it also auch die system dataset anlegt.

Ich habe eine einzelne HDD, auf welcher die Aufnahmen des Sat-Receivers gespeichert werden (kein RAID notwendig, keine Sicherung). Dann noch ein Raid 1 für die ganzen "wichtigen" Dateien, also Fotos, Dokumente usw - das RAID bekommt aber regelmäßig ein Backup.

Meine Systemplatte von FreeNAS ist ja eine von ESXi bereit gestellte Partition meiner SSD. Die ist auch einzeln, ohne RAID.


Meine HDDs werden äusserst selten genutzt. Die ganzen Dinge laufen auf unterschiedlichen VMs auf der SSD ab. Damit die HDDs jetzt nicht auch 24/7 online sind, wollte ich die schlafen legen. Ich mach vielleicht 1 Aufnahme in der Woche und schaue am Wochende ein wenig Filme davon an. Die sonstigen Daten auf dem RAID werden vielleicht auch 1x die Woche genutzt. Aber der ESXi muss aufgrund der ganzen VMs 24/7 laufen.


Also wohin dann mit dem system dataset???

 

[gea]

Hilft mir das jetzt bei meiner Frage weiter? Das einzige was ich jetzt rauslesen konnte, ist dass napp-it also auch die system dataset anlegt.

Jedes Betriebssystem braucht eine Festplatte (physikalisch als Platte oder USB Stick
oder als virtuelle Platte) mit einem Dateisystem und den Systemdateien zum Booten.

Ein Dataset ist einfach eine Bezeichnung für ein ZFS Dateisystem - beim Bootsystem mit dem Betriebssystem darauf.

Also wohin dann mit dem system dataset???

Da auf diesem Dateisystem das NAS-OS liegt, muss das unter ESXi verfügbar sein, also auf einem lokalen ESXi Dateisystem z.B. der ESXi Bootplatte liegen.

Das NAS OS (napp-it oder auch FreeNAS) greift auf die Storage Platten und den Storage Controller per pass-through mit eigenen Treiber zu, legt darauf einen oder mehrere Pools mit ZFS Dateisystemen (datasets) an. Diese werden für SMB Filerdienste oder shared NFS Storage für weitere ESXi VMs genutzt. Diese Platten und nur diese könnte man schlafen legen.

Das ist meine Idee von AiO die ich schon vor 7 Jahren vorgestellt habe.

 

[Bib]

Also kann ich jetzt das System Dataset meiner HDD auf die SSD schieben? Also auf das FreeNAS Bootlaufwerk, das ja eigentlich von ESXi kommt? Weil ich ja da kein RAID habe. Auch wird das Laufwerk nicht gesichert. Nur die Konfigurationsdateien.


Was wäre, wenn dann das Laufwerk verloren wäre? Kann ich dann die ZFS HDDs trotzdem noch auslesen mit einer frischen FreeNAS Installation oder sind die Daten dann weg, wenn das System-Dataset verloren ist?

 

[LichtiF]

ZFS ist noch da aber schau dir mal im Freenas Handbuch an was dort alles ins System Dataset geschrieben wird.

5. System — FreeNAS User Guide 9.10 Table of Contents

Wenn du davon nichts brauchst kannst du das System Dataset verschieben aber ob man das außerhalb eines Pools verschieben kann keine Ahnung ich habe kein Freenas im Einsatz aber kann Google bedienen

Im Freenas Forum wurde schon öfters mal dazu was geschrieben die meisten haben wohl eine kleine SSD oder 2,5 Zoll Platte genommen und die als einzeln Pool angelegt und dann dort hin verschoben.

 

[layerbreak]

ESXi + OmniOS + NVMe Pass-through

Kürzlich ist ja ESXi 6.5 freigegeben worden. Funktioniert die 6.5 free ohne Probleme für AIO?
Den vSphere Client gibt es ja gar nicht mehr, sondern es gibt nur noch den Browser. Wie gehen bei 6.5 die Updates?

Unter OmniOS funktioniert sleep. Man muss halt darauf schauen, dass kein Prozess regelmäßig zugreift - auch nicht der Solaris Fault Management Service fmd (deaktivieren).

Systempool/Rpool wird aber nicht schlafen. Da das bei Solarish aber immer eine eigene Platte/ SSD/ USB Stick ist, ist das kein Problem für die Platten des Datenpools.

Hast du ein HowTo oder Quellen hierzu?

 

[gea]

Kürzlich ist ja ESXi 6.5 freigegeben worden. Funktioniert die 6.5 free ohne Probleme für AIO?
Den vSphere Client gibt es ja gar nicht mehr, sondern es gibt nur noch den Browser. Wie gehen bei 6.5 die Updates?

Ich habe eine Testinstallation ESXi 6.5 + OmniOS 151020 + openvmtools aus OmniOS 151020 am Laufen, bisher keine Probleme.

Update wird wohl so gehen wie bisher, Patches via Putty und größere Updates indem man den ESXi Installer von USB oder DVD startet und updated.

Sleep,.. Hast du ein HowTo oder Quellen hierzu?

Ich habe noch nie sleep benutzt und werde das auch nicht tun.
Prinzipielll aber siehe napp-it Menü System > Power Management
eventuell fmd Service deaktivieren

prinzipiell hat sich seit
OpenSolaris Home Server Scripting 2: Setting Up Power Management
nichts grundlegendes geändert.

 

[pumuckel]

sleep ... im serverbereich ... ehrlich

die Sau muss arbeiten ^^

 

[layerbreak]

Ich habe eine Testinstallation ESXi 6.5 + OmniOS 151020 + openvmtools aus OmniOS 151020 am Laufen, bisher keine Probleme.
Update wird wohl so gehen wie bisher, Patches via Putty und größere Updates indem man den ESXi Installer von USB oder DVD startet und updated.

Das hört sich doch richtig gut an. Auch keine Probleme mit VMXNet3-Treiber und einem NFS-datastore - da war doch mal was mit einer vorherigen Version?

Ich habe noch nie sleep benutzt und werde das auch nicht tun.
Prinzipielll aber siehe napp-it Menü System > Power Management
eventuell fmd Service deaktivieren

prinzipiell hat sich seit
OpenSolaris Home Server Scripting 2: Setting Up Power Management
nichts grundlegendes geändert.

Ich geb dir Recht, für einen AIO macht das keinen Sinn, außer man hat verschiedene Pools. Aber z.B. für meinen Backup-Server sehe ich das schon für sinnvoll an, da ich den händisch anwerfe, die Repli-Jobs starte und dann oftmals ihn vergesse auszumachen, weil ich nicht immer weis wie lange er für das Backup braucht.

Wenn fmd deaktiviert wird, wie stellt dann das BS fest, ob noch alles gesund ist? Eventl. über Jobs/Other fmd alle x Stunden aktivieren und nach 15 Minuten wieder deaktivieren?

 

[gea]

Wenn fmd deaktiviert wird, wie stellt dann das BS fest, ob noch alles gesund ist? Eventl. über Jobs/Other fmd alle x Stunden aktivieren und nach 15 Minuten wieder deaktivieren?

Einen Poolfehler beim Zugriff wird das OS auch so bemerken.
Andere Probleme oder gar das automatische Einbinden eines Hotfix Laufwerks - wird eher nicht mehr funktionieren.

 

[automatenraum]

Das hört sich doch richtig gut an. Auch keine Probleme mit VMXNet3-Treiber und einem NFS-datastore - da war doch mal was mit einer vorherigen Version?

Habe zwar noch 6.0 statt 6.5 am laufen, aber bei mir ist auch OmniOS 151020 + openvmtools aus OmniOS 151020 im Einsatz. Bei alten OmniOS Versionen mit vmxnet3 hatte ich immer Probleme und ich habe die Verbindung zum NFS Datastore verloren. Mit der neuen Vesion und openvmtools ist das wieder stabil, bisher keine Probleme (seit die 151020 raus ist im Einsatz). Vorher war ich auf einer ganz alten OmniOS Version weil die Versionen danach bei mir irgendwie immer Probleme gemacht hatten.

 

[Digi-Quick]

NVMe als L2ARC oder Slog unter ESXi ist wünschenswert. Mit ausreichend RAM und SSD only Pools ist beides aber obsolet.

Ich verweise hier nochmal auf die unterirdische Schreibperformance eines SSD-Only-Pools welcher als NFS Freigabe für den VM Datastore unter ESXi läuft.
http://www.hardwareluxx.de/community/f101/zfs-stammtisch-570052-290.html#post25130662 und folgende

Mit 6,5 MB/s sequentiell ist ein ZFS-Mirror als NFS Freigabe mit aktiviertem Sync Write (standard) langsamer als vor einigen Jahren ein Raid 5 aus 5 HDDs (a' 500 GByte) mit deaktiviertem HDD-Schreibcache und und einem auf Write Through gestelltem Controllercache (der aber trotzdem Batteriegepuffert war).
Erst nachdem ich Sync Write ausgeschaltet habe (ohne zusätzlichen Slog und L2ARC) habe ich jetzt eine normal zu nennende Performance der VMs.

Die Samsung 850 Pro gelten im allgemeinen nicht als langsame SSDs.

 

[gea]

Egal on NFS, SMB oder iSCSI, sync write ist je nach Pool iops viel langsamer als normales gepuffertes Schreiben. 5-10 MB/s sind bei einem langsamen Pool durchaus nicht ungewöhnlich. Warum wie hier ein SSD Pool so langsam ist, kann ich nicht sagen, ist aber nicht ZFS spezifisch.

Insgesamt ist aber sync write bei VM Storage eigentlich ein Muss und ist üblicherweise mit guten SSDs sehr schnell und auch sehr verbreitet bei professionellem Storage so im Einsatz. Natürlich könnte eine zusätzliche NVMe noch eine kleine aber keine gravierende Verbesserung bringen.

 

[fdiskc2000]

Moin, über nacht ist mein rpool auf "degraded" gesprungen. Fehlerspeicher löschen bringt nichts, die kommen leider wieder:

  pool: rpool
 state: DEGRADED
status: One or more devices has experienced an error resulting in data
	corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
	entire pool from backup.
   see: http://illumos.org/msg/ZFS-8000-8A
  scan: scrub in progress since Fri Dec 23 07:29:54 2016
    1.51G scanned out of 4.78G at 103M/s, 0h0m to go
    9K repaired, 31.57% done
config:

	NAME        STATE     READ WRITE CKSUM
	rpool       DEGRADED     0     0     3
	  c2t0d0s0  DEGRADED     0     0    20  too many errors  (repairing)

errors: Permanent errors have been detected in the following files:

        :<0x90>
        rpool/ROOT/omnios-1:<0x0>
        //var/svc/log/network-smb-server:default.log
        rpool/ROOT/omnios-1:<0x19062>
        //var/fm/fmd/errlog-
        //etc/devices
        //var/fm/fmd/infolog_hival-
        rpool/ROOT/omnios-1:<0x111c6>

Es geht dabei um den ML10v2 auf meiner Signatur. Es ist also ein virtualisiertes Napp-IT. Wie kann soetwas passieren und vor allem: was ist zu tun um das zu beheben (ausser neu installieren?)
Wenn ich das richtig sehe, handelt es sich hierbei um Log-Dateien, oder?

 

[gea]

Die Meldung kriegt man weg, wenn man die defekten Dateien mit Prüfsummenfehlern löscht.
Die Ursache wird wohl eine defekte ESXi Platte (auf der napp-it liegt) oder Kabelprobleme sein.

Ich würde die napp-it settings (/var/web-gui/_log) wegsichern, Steckkontakte und Kabel kontrollieren und mich darauf vorbereiten diese Platte zu tauschen.

worst case
- ESXi neu installieren
- napp-it VM bereitstellen
- napp-it /var/web-gui/_log/* wiederherstellen (WinSCP)
geht auch mit BackupJob und User > restore
- VMs neu importieren (ESXi Dateibrowser, Maus Rechtsklick auf .vmx)

Zeitaufwand: Kompett ca 30 Minuten, Komplexität: niedrig

Falls man es als NAS nutzt, user mit gleicher uid wiederherstellen.
Optional: Konfigurierte napp-it VM als Template wegsichern und wiederherstellen (wenn lesen noch geht)

 

[fdiskc2000]

Danke Dir @gea:
also wohl doch die Platte, die SMART-Werte per ESXI sind da leider unbrauchbar wie es scheint.
Da der ESXI auf einem USB-Stick liegt und problemlos läuft, werde ich wohl einfach die napp-it VM umziehen auf eine neue SSD.

Neuinstallation / Backup zurückspielen habe ich mehrfach getestet in der Vergangenheit und auch wenn es nur die 30 Minuten sind war für mich eher interessant woran das liegt.

 

[layerbreak]

Da der ESXI auf einem USB-Stick liegt und problemlos läuft, ...

Auf einem USB-Stick

Welcher USB-Stick ist da zum Empfehlen bitte?

 

[Luckysh0t]

Da soweit ich weis nur beim Booten vom Stick gelesen wird ist das in der Hinsicht wohl eher nebensächlich ( läuft dann aus dem RAM, und ggf Schreibzugriffe auf dem Stick für änderungen am ESXi selbst. Scratchpartition ist bei der Lösung auf einer Ramdisk - deswegen hat man ca 512 MB weniger RAM für die VM - wenn man es nicht nachträglich ändert.Bei einem NUC oder anderen Lösungen wo es an dem Port eher sehr warm wird empfiehlt sich ggf eine kleine Verlängerung als "Wärmeisolator" um den Stick nicht als bald über den Jordan zu schicken.


Soweit mein Stand.

Edit

Die Funktion VMware VMDirectPath zum Durchreichen von PCI Karten kann bei der Installation vom ESXi auf einen USB Stick nicht genutzt werden. VMDirectPath schreibt die Konfiguration in das /etc/ Verzeichnis.[2] Das Verzeichnis /etc/ bleibt bei einer Installation von ESXi auf einen USB Stick jedoch nicht permanent erhalten.

https://www.thomas-krenn.com/de/wiki/ESXi_5.0_auf_USB_Stick_installieren


Ist das noch so ? Ist ja für den einen oder anderen gut zu wissen.

 

[fdiskc2000]

Beim ESXI ist der USB-Stick laut diversen Beiträgen in der Tat nur beim Bootvorgang beteiligt. Anders als bei FreeNAS oder ähnlichen Systemen. Und zur Not: das Image des Sticks habe ich gesichert und wenn der mal hin sein sollte mache ich einen neuen draus. Finde das Konzept recht praktisch, zumal man damit auch das Problem der Boot-Folge bei einigen Servern einfach umgehen kann.

 

[layerbreak]

Beim ESXI ist der USB-Stick laut diversen Beiträgen in der Tat nur beim Bootvorgang beteiligt. Anders als bei FreeNAS oder ähnlichen Systemen. Und zur Not: das Image des Sticks habe ich gesichert und wenn der mal hin sein sollte mache ich einen neuen draus. Finde das Konzept recht praktisch, zumal man damit auch das Problem der Boot-Folge bei einigen Servern einfach umgehen kann.

Wenn ich es richtig gelesen habe, scheint ESXi beim Booten alles in den Hauptspeicher zu laden, nur die Logs werden ständig geschrieben. Also sollten die Logs auf eine SSD/HDD schreiben bzw. umgebogen werden.

Was für einen Stick hast du da genommen?
USB2 oder USB3, und wie groß?

Edit:
Mit welchem Tool stellst du das USB-Image her?

 

[fdiskc2000]

Habe da jeweils einen Sandisc Cruzer 8GB USB2.0 drin. WinISO für den Rest. Bisher halten die Sticks seit >6 Monaten. Mal schauen wie lange.

 

[layerbreak]

Habe da jeweils einen Sandisc Cruzer 8GB USB2.0 drin. WinISO für den Rest. Bisher halten die Sticks seit >6 Monaten. Mal schauen wie lange.

Das ist ja ein 0815 Stick. Das mein ich jetzt nicht negativ, offensichtlich stört es ESXi nicht, was für ein Speichermedium genutzt wird. OK mein Board hat onboard einen USB3-Steckplatz dann nimm ich einen aus meiner Grabbelkiste.
WinISO-Alternative könnte dann usb-image-tool sein.