[Sammelthread] ZFS Stammtisch

Wenn der Solarish Fehler Management Dienst fmd ein Device als fehlerhaft einstuft wird das gesperrt damit z.B. ein amoklaufender Plattenkontroller den Pool nicht schrotten kann.

Bei Hochfahren kommt dann auch eine Meldung über ein "retited device".
Das gesperrte Device muss man dann als "repariert" kennzeichnen damit es wieder tut

vgl Napp-it Menü
System > Faults > Repair

oder

Resolving Faulty Devices - Managing Devices in Oracle® Solaris 11.2

A device retirement mechanism isolates a device that is flagged as faulty by the fault management framework (FMA). This feature allows faulty devices to be safely...
docs.oracle.com
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ja, das hatte ich heute noch mehrfach, in Kombination mit nicht mehr reagierender Web-GUI. Zwischenzeitlich dachte ich, die zusätzliche Platte sei geschrottet. Ein Test an einem anderen Rechner zeigte dann, dass das nicht der Fall ist. Nach mehreren Neustarts, Reparaturanzeigen usw. ist mein Data Pool wieder online und auch die zusätzliche Platte läuft jetzt. Hat Zeit und Nerven gekostet. Keine Ahnung, woran das lag, die Platte hängt jetzt in einem anderen Einschub (hatte ja vier freie...).

Jetzt wird erst mal fleißig auf verschlüsselte Dateisysteme repliziert, das hätte schon den ganzen Tag laufen sollen...

Vielleicht hast Du hier noch einen Hinweis für mich: ich realisiere gerade ein Offsite Backup. Das Zielsystem (auch Napp-It) wird per VPN erreicht werden, die Filesysteme sollen gecryptet sein. Einmal pro Woche soll das Backup per zfs send|recv auf den Backup Server übermittelt werden, die Filesysteme sollen zwischenzeitlich verriegelt werden. Frage: wo sinnvollerweise die Passphrase für den Backupserver unterbringen? Ein USB-Stick am Backupserver würde ich eher ausschließen wollen. Ich denke, die Filesysteme werden scriptgesteuert entriegelt und gemountet.
 
Warum willst du am Backup System überhaupt entriegeln und mounten? Ich sende einfach per raw send die verschlüsselten Blöcke ans Backup. Der Key ist damit der selbe wie am Quellsystem, den brauche ich nur für den Fall, das ich aufs Backup zurückgreifen muss.
 
VPN + ZFS send ist eine Idee.
Ich würde aber auch das verschlüsselte Dateisystem "raw" übertragen. Es bleibt dabei verschlüsselt und kann bei Bedarf mit dem Originalkey entschlüsselt werden.

Alternative: Auf dem napp-it Zielsystem Amzon S3 Dienste mit minIO aktivieren und verschlüsselt per rclone senden. Wenn man kein VPN nutzt (und nur den S3 Port per Firewall freigibt oder durchreicht) auch ohne VPN sehr sicher, http://www.napp-it.org/doc/downloads/cloudsync.pdf
 
Danke noch für Eure Rückmeldung! Mit Raw Übertragung hatte ich mich noch gar nicht beschäftigt. Auch diemS3 Eschichte schaue ich mir mal noch an. Raw Übertragung setzt natürlich voraus, dass das Quellsystem verschlüsselt ist, das kommt bei mir gerade noch. Zunächst verschlüssle ich mal die Daten, die auf dem Backup System landen (da bin ich nahezu fertig), das ist aus zeitlichen Gründen gerade wichtiger. VPN weglassen zu können, wenn die Daten eh schon verschlüsselt sind, hätte natürlich den Vorteil, dass die Performance höher sein dürfte, da ZFS-Entschlüsseln, VPN-Ver- und Entschlüsseln ud anschließendes ZFS-Verschlüsseln sicher Zeit benötigen und das bei größeren Datenmengen spürbar sein könnte.
Bzgl. der S3 Lösung bin ich noch unsicher, ob ich da von Napp-It (lokal) zu Napp-It (remote / Backup) sichern kann. Wenn ich das richtig verstanden habe, ist das der Job von minIO, richtig? Dort hätte man die Übertragung verschlüsselter Daten per https, auch richtig? Dann müsste auf dem Zielsystem zu dem Zeitpunkt das verschlüsselte Filesystem schon entriegelt sein. Ich denke, da würde mir die Raw Übertragung besser gefallen, weil da auf dem Backup Server gar nicht entriegelt werden muss.

Danke für‘s Zuhören bei meinem lauten Nachdenken... 😂
 
zum Thema Cloudbackup via S3

Einen S3 Server wie minIO kann man per http oder https betreiben. Bei https ist die Übertragung verschlüsselt. Das Syncronisieren eines lokalen Ordners mit einem Cloud S3 Ordner passiert z.B. mit rclone (rsync for Cloud).

Wenn man die Daten verschlüsselt ablegen möchte, hat man mit rclone zwei Optionen. Man kann erstens als Backupziel ein verschlüsseltes ZFS Dateiystem (status unlocked) nehmen das man nach dem Backup verriegelt. Man kann aber auch auf ein ganz normales ZFS Dateisystem sichern und die Daten in rclone vor der Übertragung mit einem Schlüssel verschlüsseln. Entschlüsseln kann man das dann beim Lesen ausschließlich via rclone.


siehe pdf Nr 5f

napp-it // webbased ZFS NAS/SAN appliance for OmniOS, OpenIndiana and Solaris : Manual

napp-it.org - ZFS NAS SAN Server mit einer durch den Benutzer anpassbaren Weboberfläche // All In One server = virtualisierter lauffähiger ZFS-Server
napp-it.org napp-it.org
 
minIO läuft aber (unter OmniOS/napp-IT Installation) nur als http und nicht als https Server - wie würde man das denn umstellen? Wäre da nicht generell eine Option im napp-IT Setup / Installationsmenü hilfreich?

Oder muss man nur die certificates am geeigneten Ort hinterlegen?
 
Hallo,

ich muss mal was Altes von mir hoch holen (s.u.), da ich mich nach längerer Zeit wieder an das Thema schaltbare Steckdosenleiste gemacht habe. Die Steckdosenleiste wird mit sispmctl über USB geschaltet. sispmctl läuft aktuell auf einem Pi, ic möche das aber lieber in meiner Napp-It VM laufen lassen. Das Kompilieren schlägt leider fehl. Zustand: libusb 0.1.12 über pkgin installiert, liegt unter /opt/local/lib. ./configure konnte ich inzwischen erfolgreich ausführen, aber make schlägt fehl. An anderer Stelle habe ich gelesen, dass gmake empfohlen wird, leider keine Änderung.

Code: 
root@san:~# export LD_LIBRARY_PATH='/opt/local/lib/'
root@san:~# cd sispmctl-4.7-1/
root@san:~/sispmctl-4.7-1# gmake
gmake  all-recursive
gmake[1]: Entering directory '/root/sispmctl-4.7-1'
Making all in src
gmake[2]: Entering directory '/root/sispmctl-4.7-1/src'
/bin/sh ../libtool  --tag=CC   --mode=link gcc -Wall -DBINDADDR="\"\"" -DDATADIR="\"/usr/local/share/doc/sispmctl/skin\"" -g -O2 -I/opt/local/include/   -o sispmctl main.o libsispmctl.la -lsocket  -L/opt/local/lib/
libtool: link: gcc -Wall "-DBINDADDR=\"\"" "-DDATADIR=\"/usr/local/share/doc/sispmctl/skin\"" -g -O2 -I/opt/local/include/ -o .libs/sispmctl main.o  ./.libs/libsispmctl.so -L/opt/local/lib/ -lsocket -R/usr/local/lib
Undefined                       first referenced
symbol                             in file
usb_control_msg                     ./.libs/libsispmctl.so
usb_claim_interface                 ./.libs/libsispmctl.so
usb_busses                          main.o
usb_device                          ./.libs/libsispmctl.so
usb_set_altinterface                ./.libs/libsispmctl.so
usb_close                           main.o
usb_init                            main.o
usb_open                            ./.libs/libsispmctl.so
usb_strerror                        ./.libs/libsispmctl.so
usb_find_busses                     main.o
usb_set_configuration               ./.libs/libsispmctl.so
usb_find_devices                    main.o
ld: fatal: symbol referencing errors. No output written to .libs/sispmctl
collect2: error: ld returned 1 exit status
gmake[2]: *** [Makefile:516: sispmctl] Error 1
gmake[2]: Leaving directory '/root/sispmctl-4.7-1/src'
gmake[1]: *** [Makefile:493: all-recursive] Error 1
gmake[1]: Leaving directory '/root/sispmctl-4.7-1'
gmake: *** [Makefile:383: all] Error 2

@gea: Du hattest damals geschrieben, dass es zumeist scheitere, wenn die Libs in /opt liegen. Ich meine, dass ich das in die PATH Variablen eingefügt hätte. Hast Du noch einen Tipp, wo der Fehler liegen könnte?

Edit:
Noch ein Thema: Die o.g. Steckdosenleiste soll eine USB Platte zum Backup ein- und danach wieder ausschalten. Beimder Platte handelt es sich um eine Seagate Expansion Desktop 8TB, die über USB3.0 angebunden ist. In ESXi habe ich sie als USB Device an die Napp-It VM durchgereicht, dort wurde sie erkannt und ZFS Pool angelegt. Jetzt ziehe ich das erste Backup auf die Platte (zfs send|rcv) und muss feststellen, dass das seeeehr langsam von statten geht. In den Amazn Rezensionen war mehrfach die Rede davon, dass die Plate mit dem Originakabel nur auf 25-30MB/Sec. kommt und dass die Performance mit anderen Kabeln auf übliche ca. 130MB/Sec. steigt. Also anderes Kabel bestellt, das mit bis zu 5GBit/Sec. beworben wird. Ich muss aber feststellen, dass das nix gebracht hat. Nach anfänglichen 300MB/Sec. in den ersten paar Sekunden (Cache) pendelt sich das bei 10 MB/Sec. ein. Ich würde behaupten, dass es nicht am Kabel liegt (gleiches Verhalten bei 3 Kabeln). Auf dem Mainboard nutze ich definitiv einen USB3.0 Anschluss und die Platte kann mit Sicherheit mehr als die 10MB/Sec. Hat noch jemand einen Tip? Ist in ESXi noch was einzustellen? Unterstützt Omnios/Napp-It USB3.0?

Danke und Gruß! Kandamir


kandamir schrieb:
Danke, hatte ich sogar gesehen, war aber mit dem ISO nicht weiter gekommen...



Ich habe jetzt diesen Weg weiter verfolgt und pkgin installiert. Damit bekomme ich auch drei verschiedene libusb Pakete angezeigt, zwei davon habe ich installiert:

Code: 
libusb1-1.0.21 =     USB Access Library (version 1)
libusb-0.1.12nb5 =   USB access library (version 0)
*libusb-compat-0.1.6rc2  USB access library version 0 compatibility layer on top of version 1

Das dritte hat einen Konflikt mit dem zweiten Paket...

Was mich nun wundert: ./configure bemängelt immer noch dass kein passendes libusb da sei:

Code: 
configure: error: Package requirements (libusb >= 0.1.11) were not met:

No package 'libusb' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables LIBUSB_CFLAGS
and LIBUSB_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.

Dabei habe ich ja nun über pkgin libusb-0.1.12 installiert, aber trotzdem werden die Libs nicht gefunden... Das sind die Momente, an denen man sich ein gut gepflegtes Debian Repository wünscht, weil man sich dort mit solchen Problemen selten herumschlagen muss. Wenn mir bitte nochmal jemand unter die Arme greifen würde... ;)
Zum Vergrößern anklicken....

gea schrieb:
Nunja, OmniOS CE ist bewußter Minimalismus.

Die beiden Firmen aus der Schweiz und UK die im Wesentlichen hinter OmniOS CE stehen nutzen das kommerziell intern als Storageplattform und unterstützen nur das nötigste um damit einen FC/iSCSI, NFS und SMB Storageserver aufzubauen (inkl. kommerzieller Supportoption). In deren Repo ist noch nichtmal Apache oder Samba enthalten. Dafür beste Stabilität, stable und long term stable Distributionen.

Pgkgin von SmartOS (wie OmniOS basiert das auch auf Illumos) ist ein sehr gut gepflegtes Repository das nicht nur Illumos sondern auch BSD, OSX und Linux unterstützt. Teil dieser Plattformunabhängigkeit ist es, dass alles in /opt installiert wird und daher das jeweilige System weitgehend unverändert läßt. Das ist auch nötig, da SmartOS primär eine VM/ Cloudplatform ist bei dem man alles systemunabhängig in Zonen laufen lassen möchte. Wird alles via pkgin installiert klappt auch meist das Zusammenspiel.

Wird zusätzlich selbst was kompiliert und etwas nicht gefunden, so liegt das meist daran dass es in /opt liegt.


PS
Man könnte auch einfach einen Steckdosentimer für ein paar Euro einsetzen und für 15 Minuten Strom auf die USB Platte geben und in dieser Zeit eine Replikation laufen lassen. Die braucht meist eh nur wenige Sekunden für inkrementellen Lauf. Das tut sicher, macht keinen Ärger und man muss sich nicht darum kümmern ob irgendein Fremdtreiber die Stabilität beeinträchtigt.

Ich würde das aber eh so vermeiden da ein Disaster (Blitzschlag, Diebstahl etc) auch das Backuplaufwerk betrifft (verbunden via USB). Ein Backup muss extern und separat sein. Daher also nach dem Backup wechselweise Laufwerke abstecken und davor anstecken.
Zum Vergrößern anklicken....
 
Zuletzt bearbeitet:
Soweit ich mich entsinne, behandelte der ESXi lokal angeschlossene USB-HW nur Stiefmütterlich. Für Dongle reichte es aus, aber für mehr damals mit USB2.0 eher nicht. Das mag sich in neueren ESXi-Versionen und mit USB3.x geändert haben, ich habe das jedoch nie selber getestet. Sämtliche USB-HW reiche ich per Device-Server (Silex etc) rein.

Auf der anderen Seite ist die SMR-Problematik nicht von der Hand zu weisen und wenn ich nach " Seagate Expansion Desktop 8TB SMR" suche, wird mir aktives SMR angezeigt.
 
ESXi ermöglicht es auch, einen USB3.1 Controller in einer VM anzulegen, bei Napp-It warn aber gleich, dass das vom Guest-OS nicht unterstützt würde. Hab‘s bislang auch noch nicht hinbekommen...

SMR mag ja sein, aber Heise hat die Platte im Vergleichstest auch gemessen und da hat sie a) ziemlich passabel abgeschnitten und b) belegen einige Rezensionen bei Amazn auch, dass die Platte rund 130MB/Sec. schafft, und nicht nur kümmerliche 10MB, was ja wohl sowas wie USB1.1 wäre und nicht mal USB 2.0. ich erwarte bei einer Backup Platte auch keine Top-Speed, aber 10MB/Sec. und weniger?! Wenn also doch noch jemand sachdienliche Hinweise hat... ;-)
 
SMR Platten haben erheblich zugelegt durch einen großen RAM Cache und durch einen Mediacache. Da werden Daten zunächst ohne MSR geschrieben um die verzögert auf den MSR Bereich zu schreiben. Eine gewisse Zeitlang (Benchmark) sind MSR Platten damit genauso schnell wie herkömmliche.

Wehe man schreibt aber dauerhaft. Dann bricht die Performance massivst ein. MSR sind damit extrem ungeeignet für dauerhafteres Schreiben (Backup/NAS/RAID). Baut man z.B. ein Raid aus MSR Platten und eine Platte fällt aus, so dauert ein Raid Recovery ein Vielfaches der Zeit, im Extremfall wird die Platte sogar als fehlerhaft aus dem Raid geworfen.

Servethehome hat dazu eine ganze Serie von Artikeln, z.B. https://www.servethehome.com/wd-red-dm-smr-update-3-vendors-bail-and-wd-knew-of-zfs-issues/

Finger Weg von MSR im NAS oder im Raid, nicht nur bei ZFS. Auch Synology bezeichnet die als untauglich für ihr NAS. Ich würde sie nicht mal für ein Single Disk Backup nehmen. Einfach nur Schrott da sie ja neben allen Nachteilen nichtmal billig genug sind um die Nachteile zu rechtferigen.
 
MinIO kann sehr viel. Neben der Clustering Option (Redundanz, Performance) auch noch Nutzerverwaltung und jetzt Versionierung.

Da wird es aber schnell aufwändig bzw man muss die CLI Befehle bemühen. Zusammen mit ZFS kann man es aber auch einfach so halten dass ZFS die Redundanz und Versionierung bereitstellt (per gleichzeitigem SMB Share und Windows vorherige Version wenn man es ganz einfach möchte). Für wenige Nutzer kann man auch ein ZFS Dateisystem/minIO Share je User bereitstellen und muss so garnichts einstellen, nur das Share aktivieren.
 
Ich bin auf Arbeit erstmalig über die Notwendigkeit gestolpert, auf einen NFS Mount einer NetApp in ESXi eine Disk ThickProvisioned anzulegen. Soweit ich gelesen habe, soll das möglich sein, wenn VAAI auf dem Storage unterstützt und das entsprechend Plugin in ESXi installiert wird. Alternative wäre sonst wohl nur iSCSI.

Das Arbeitsthema mal außen vor (ist eh nicht meine Baustelle), habe ich mir das auf meinem OmniOS NFS Mount in ESXi mal angesehen und festgestellt, dass auch dort nur ThinProvisioning möglich ist.
Nach kurzer Recherche finde ich zwar viele (auch alte) Beiträge zu dieser Kombination OmniOS/VAAI, aber es scheint bis heute nicht unterstützt zu sein. Ist das so korrekt und sind Planungen hierzu bekannt?

Viele Grüße
Martin
 
gea schrieb:
...
Finger Weg von MSR im NAS oder im Raid, nicht nur bei ZFS. Auch Synology bezeichnet die als untauglich für ihr NAS. Ich würde sie nicht mal für ein Single Disk Backup nehmen. Einfach nur Schrott da sie ja neben allen Nachteilen nichtmal billig genug sind um die Nachteile zu rechtferigen.
Zum Vergrößern anklicken....

Danke, @gea und @Stangensellerie! Ich denke, dann werde ich die Platte wohl wieder ausmustern und eine Nicht-SMR-Platte kaufen. So ist das jedenfalls nicht tragbar.

@gea: Hast Du vielleicht noch einen Hinweis zu meinem Compilerproblem von sispmctl? Gerne auch jemand anderes. Danke vorab!(y)

Edit: Werde vermulich eine Seagate Barracuda Pro 10TB (ST10000DM0004) nehmen, da CMR und gutes Preis-Leistungsverhältnis in dem Bereich (die 10TB Platte ist sogar günstiger als die 8TB Version und hat mehr Performance). Spricht aus Eurer Sicht was gegen dieses Modell? Die Platte soll in ein externes USB3.0 Gehäuse (irgendwelche Vorschläge?) und 1 bis 7x pro Woche ein- und wieder ausgeschaltet werden (siehe auch mein Compilerproblem mit sispmctl unter OmniOS).
 
Zuletzt bearbeitet:
Die abschließenden Worte im STH-Artikel sind sehr eindeutig.

[edit]
Für mich entsteht genau dieselbe Konfusion. Da hat man die Red-Line, die teilweise 2TB-6TB DM-SMR ist und ab 8TB wieder CMR und dann noch die Red-Plus-Line mit CMR. Das hätte WD besser lösen müssen und ich bin gespannt, wie das weitergeht.
 
gea schrieb:
Ich wurde gerade darauf hingewiesen, es gibt bald auch eine WD RED PLUS für "heavy workloads like ZFS": https://blog.westerndigital.com/wd-red-nas-drives/ Soll da die einfache WD red ohne was dann MSR bleiben (für die im Tal der "Ahnungslosen")?

zum Compilerproblem mit sispmctl kann ich nichts beitragen.
Zum Vergrößern anklicken....

Okay, schade, aber trotzdem Danke. Danke auch für den Link zu WD, aber ich denke, ich werde bei der o.g. Seagate bleiben.

Nochmal kurz zum Thema USB. Ich hatte oben geschrieben, dass ESXi (bei mir 7.0) bei mir eine Warnung anzeigt, wenn man in den VM Eigenschaften meiner Napp-It VM einen USB3.1 Controller einbinden möchte. Das sei vom Guest OS nicht unterstützt. Als Guest OS ist Solaris 11 64 Bit angegeben. Gibt es diese Einschränkung tatsächlich? Denn USB2.0 Geschwindigkeit ist ja auch nicht das, was man bei einer modernen Platte im USB3.0 Gehäuse haben will...

Edit: Okay, mich deucht, es lieg an der Hardware-Version der VM, die müsste ich wohl auf eine ESXi 7.0 VM upgraden (=Hardware Version 17). Werde ich später mal machen.
 
Zuletzt bearbeitet:
@kandamir
Die v.HW-Version hochziehen würde ich nur dann machen, wenn ich beim 7.0 ESXi bleiben will. Ansonsten mußt du das manuell wieder zurückdrehen, wenn die VM nachher auch unter 6.x laufen soll...

In USB-Konfiguration von einem ESXi-Host zu einer virtuellen Maschine wird nix von Solarish erwähnt. Ich würde daher nicht davon ausgehen, daß dir die v.HW-Version 7 etwas bringt. Unterstützt Solarish überhaupt USB3 vollständig?
 
@Stangensellerie: Ich plane eigentlich schon, bei ESXi 7.0 zu bleiben. Vor dem Upgrade auf HW Version 17 habe ich aber sicherheitshalber die VM geklont (.vmdk geklont, Rest Kopie erstellt). Aber wie Du schon angedeutet hattest, hat das alleine noch nix gebracht. Es kommt weiter die Meldung, dass das Guest-OS den Controller nicht unterstützt. Allerdings gibt es für OmniOS ab r151014 Unterstützung von USB3.0, was mir ja reichen würde. Und ESXi subsummiert nach meinem Verständnis USB3.0 ebenfalls unter USB3.1. Insofern ist mir nicht klar, woran es hängt...
 
USB hat nicht die Performance und Problemfreiheit von Sata/SAS. Ein Hotplug Wechselplatteneinschub an Sata/SAS für 30 Euro (oder eine Backplane für die Platten) würde das USB Problem komplett umgehen.
 
Eine Backplane ist ja vorhanden, @gea. Ich wollte die Backup Platte aber nicht dauerhaft laufen lassen, sondern wirklich auch gezielt abschalten können, wenn kein Backup läuft. Wobei hot plugging bei mir bislang auch noch nie geklappt hat. Hat immer zu Seiteneffekten geführt, die mich dan dazu bewogen haben, die VM neu zu starten. Aber auch das dürfte vermutlich lösbar sein. Ich frage mich aber tatsächlich, ob der von mir angestrebte Weg tatsächlich so fernab der Praxisrelevanz sein sollte, dass er in dieser Konstellation (ESXi, Napp-It) schlicht nicht vorgesehen ist. Ich weiß, dass ich kein professionelles Rechenzentrum betreibe. Aber ein USB3.0 Laufwerk nicht mit USB3.0 Performance betreiben zu können, wo das doch offiziell von OmniOS unterstützt wird?

Über sispmctl brauchen wir nicht diskutieren, das ist sicher kein üblicher Anwendungsfall im Profibereich, aber USB3.0, ich weiß ja nicht... Sorry, ist nicht nböse von mir gemeint, @gea. Und ich schätze Deine Rückmeldungen auch sehr. Aber in dem Punkt bin ich etwas ratlos...
 
Dann wäre die sauberste Lösung ein USB-Device-Server wie den Silex DS-600. Damit hat in jedem Fall der Gast die Macht angeschlossene Geräte.
 
Ich überlege gerade, ob ich nicht einfach noch einen USB3.1 Controller spendieren soll und den komplett in die Napp-It VM durchreiche. Sowas gibt‘s ab 30 Euro. Gibt es da Chipsätze, die man bevorzugen sollte? Könnte natürlich auch den USB 3.0 Controller vom Supermicro versuchen durchzuschleifen...
Die ca. 135 Euro für die Silex Box find ich offen gestanden etwas heftig.

Edit: Hätte ich ja auch mal früher machen können. Ich habe den Onboard USB 3.0 Controller an die Napp-It VM durchgereicht. Da komme ich dann zumindest mal auf Transferraten beim Schreiben von 60 bis 80 MB/Sec. Das ist immer noch nicht der Hit mit der Seagate Expansion Desktop, aber schonmal deutlich über den 2 bis 10 MB/Sec., wenn die Platte von ESXi als USB Gerät durchgereicht wird. Das jetzt mal mit ner vernünftigen CMR Platte probieren...
 
Zuletzt bearbeitet:
Ich hab dafür eine USB-Karte durchgereicht. Hab mit den Renesas-Chipsätzen ganz gute Erfahrungen gemacht, sowohl für passthrough an Windows- wie auch Solaris-VMs. Allerdings alles noch ESXi 6.5 und 6.7. Mit 7.0 habe ich noch keine eigenen Erfahrungswerte.

Von VIA rate ich ab (hab eine, nur Mist), und auch von diesen 4in1 (also 4 Host-Chips auf einer Karte) ebenfalls - selbst mit Renesas (hab ich auch eine, lief auch nicht überall problemlos).
 
Zuletzt bearbeitet:
Anmelden, um zu antworten.

Ähnliche Themen

G
Wieviel ZFS steckt in Qnap ZFS ??
Antworten
5
Aufrufe
979
gea
G
Shihatsu
ZFS Pool "verschicken"
Antworten
9
Aufrufe
648
sandreas
S
AG1M
[Kaufberatung] Neuer ZFS Homeserver
Antworten
16
Aufrufe
766
pwnbert
pwnbert
thor17
Ceph Node auf bestehenden ZFS Pools
Antworten
3
Aufrufe
576
gea
G
G
[Übersicht] napp-it cs, Web-GUI für fast jeden ZFS Server oder Servergruppen
4 5 6
Antworten
158
Aufrufe
9K
gea
G
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