[Sammelthread] ZFS Stammtisch

Hallo Leute,

ich besitze einen hp microserver gen8 mit 16gb Arbeitsspeicher 2*4 TB WD Green Festplatten und einer 128gb SSD. Ich frage mich ob napp-it das richtige System ist.
Meine erste Frage ist ihr redet hier von esxi und vmware. Lasst ihr euer ZFS System in einer virtuellen Maschine laufen? Ich dachte das ist das schlimmste was man einem ZFS System antun kann?
Baut Napp-it auf Linux Betriebssysteme auf?
Ich möchte mein System gerne als reines Backup System aller Clients (Windows, Linux, Android) nutzen. Das System soll herunterfahren wenn kein Client online ist und keine Datenüberprüfung stattfindet oder ein bestimmter Netztraffic nicht überschritten wird.
Die WD Green Platten sollen als Raidz1 verbunden werden. Zusätzlich will ich bei meinen Eltern ein zweites System aufbauen (N54L, 8 GB Ram, 2*4TB WD Green). Dort befinden sich auch Clients die ihre Daten auf dem N54L ablegen.
Es soll 1mal wöchentlich ein bidirektionales Backup zwischen den beiden System stattfinden. Damit es keine Konflikte gibt, bekommt jeder Nutzer schreibrechte auf ein eigenes Dataset. Beispielsweise bekommt mein Vater ein persönliches Dataset auf dem er seine Daten bei sich zu Hause ablegen kann und ich schreibe bei mir auf mein Dataset. Bei dem bidirektionalen Backup wird sein Dataset auf mein System gesichert und mein Dataset auf sein System. Er hat keinen Zugriff auf mein Dataset und ich nicht auf seins. Außerdem sollen die Daten regelmäßig versioniert werden und ich muss mit Windows und Linux auf dem Client jederzeit die Möglichkeit haben mir einen Versionstand einer bestimmten Datei zu ziehen.
Ist sowas stabil und auch für normale User mit napp-it umsetzbar? Haltet ihr meine Sicherungsstrategie für sinnvoll und sicher?

Vielen Dank im Voraus.

Mfg
Ironcurtain
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ich versuche mal das aus Entwicklersicht zu beantworten

Ironcurtain86 schrieb:
Hallo Leute,

ich besitze einen hp microserver gen8 mit 16gb Arbeitsspeicher 2*4 TB WD Green Festplatten und einer 128gb SSD. Ich frage mich ob napp-it das richtige System ist.
Meine erste Frage ist ihr redet hier von esxi und vmware. Lasst ihr euer ZFS System in einer virtuellen Maschine laufen? Ich dachte das ist das schlimmste was man einem ZFS System antun kann?
Zum Vergrößern anklicken....

Als ich vor ca 6 Jahren mit der Idee kam Storage zu virtualisieren war das die vorherrschende Meinung. Heutzutage ist das Gang und Gäbe. Man darf nur nicht den Fehler machen Storage zu virtualisieren (Platten und Controller). Das Storage OS als VM ist ok.

Baut Napp-it auf Linux Betriebssysteme auf?
Zum Vergrößern anklicken....

Im Gegensatz zu geschlossenen Systemen wie FreeNAS, Nexentastor oder OMV ist napp-it ein "Nasifier". Es nutzt eine Reihe von Betriebssystemen um darauf ein ready to use NAS/SAN zu erstellen. Hauptplattform ist Oracle Solaris und die freien Forks OmniOS oder OpenIndiana. Dabei handelt es sich um Unix. Es gibt auch eine Version für Linux die aber nur Basisfunktionen abdeckt.

Ich möchte mein System gerne als reines Backup System aller Clients (Windows, Linux, Android) nutzen. Das System soll herunterfahren wenn kein Client online ist und keine Datenüberprüfung stattfindet oder ein bestimmter Netztraffic nicht überschritten wird.
Zum Vergrößern anklicken....

Server never sleep. Es gibt zwar Stromsparfunktionen (Platten gehen schlafen). Dennoch ist Solaris nicht für Heimuser entwickelt worden sondern für Datacenter. Am einfachsten nutzt man einen Job der den Rechner abends ausschaltet.

Die WD Green Platten sollen als Raidz1 verbunden werden. Zusätzlich will ich bei meinen Eltern ein zweites System aufbauen (N54L, 8 GB Ram, 2*4TB WD Green). Dort befinden sich auch Clients die ihre Daten auf dem N54L ablegen.
Es soll 1mal wöchentlich ein bidirektionales Backup zwischen den beiden System stattfinden. Damit es keine Konflikte gibt, bekommt jeder Nutzer schreibrechte auf ein eigenes Dataset. Beispielsweise bekommt mein Vater ein persönliches Dataset auf dem er seine Daten bei sich zu Hause ablegen kann und ich schreibe bei mir auf mein Dataset. Bei dem bidirektionalen Backup wird sein Dataset auf mein System gesichert und mein Dataset auf sein System. Er hat keinen Zugriff auf mein Dataset und ich nicht auf seins. Außerdem sollen die Daten regelmäßig versioniert werden und ich muss mit Windows und Linux auf dem Client jederzeit die Möglichkeit haben mir einen Versionstand einer bestimmten Datei zu ziehen.
Zum Vergrößern anklicken....

Prinzipiell alles kein Problem. Der bidirektionelle Backup wird per sync (zfs send, rsync oder robocopy) erreicht. Versionen durch ZFS snaps. Unter Windows geht der Zugriff mit "Eigenschaft > vorherige Version". Unter Linux per Zugriff auf das Snap-Verzeichnis.

Ist sowas stabil und auch für normale User mit napp-it umsetzbar? Haltet ihr meine Sicherungsstrategie für sinnvoll und sicher?
Zum Vergrößern anklicken....

Solaris und ZFS ist ultra stabil und mit das Beste was Datensicherheit angeht. Umsetzbar, keine Frage. Für typische Homeanwendungen mag sowas wie Xpenology fertige Module bieten. Dafür ist ZFS deutlich zuverlässiger und bietet Versionierung und Datensicherheit durch Prüfsummen.
 
Zuletzt bearbeitet:
gea schrieb:
Als ich vor ca 6 Jahren mit der Idee kam Storage zu virtualisieren war das die vorherrschende Meinung. Heutzutage ist das Gang und Gäbe. Man darf nur nicht den Fehler machen Storage zu virtualisieren (Platten und Controller). Das Storage OS als VM ist ok.
Zum Vergrößern anklicken....
Das virtualisierte Storage OS braucht doch Zugriff auf die Platten und den Controller *konfus*
Oder meinst du damit, daß Controller und Platten exklusiv (Vt-d bzw. IOMMU) an das StorageOS durchgereicht werden sollten - also gar nicht vom Host-OS / Hypervisor verwaltet werden!

@Ironcurtain
Wozu willst du überhaupt Virtualisieren? Sollen da weitere VMs für ganz andere Dinge drauf laufen, oder war das nur eine generelle Verständnisfrage?
Zu deinem Vorhaben:
Prinzipiell kann man das so machen. wie praktikabel das ganze sein wird entscheidet sich anhand der verfügbaren Bandbreiten vor Ort (vor allem der Upload ist interessant) und den jeweils zu übertragenden Datenmengen.
Die initiale Synchronistaion würde ich auf jeden Fall lokal machen!

Ansonsten solltest du dir Gedanken über einen - möglicherweise permanenten - VPN Tunnel machen.

Warum WD-Green?
1. sind das keine NAS Platten, sind weder für 24/7 noch für den Stapelbetrieb (also mehr als 2 Stück in einem Gehäuse) freigegeben.
2. sind die vergleichsweise langsam

Alternativen
HGST-NAS (7200 U/min - dürften daher deutlich "schneller" sein als die anderen.)*
WD-Red
Seagate NAS

*Schneller bedeutet hier höhere sequentielle Transferrate, kürzere Zugriffszeit und höhere IOPs.
 
Zuletzt bearbeitet:
Digi-Quick schrieb:
Das virtualisierte Storage OS braucht doch Zugriff auf die Platten und den Controller *konfus*
Oder meinst du damit, daß Controller und Platten exklusiv (Vt-d bzw. IOMMU) an das StorageOS durchgereicht werden sollten - also gar nicht vom Host-OS / Hypervisor verwaltet werden!
Zum Vergrößern anklicken....

Genau so und nicht anders.
Für eine normale Server VM sind virtualisierte Controller und Platten ok, nicht aber wenn man Storage haben möchte, der vergleichbare Leistung haben soll wie ein Storageserver der direkt auf Hardware laufen soll.

Wenn die CPU nicht am Anschlag läuft und man in beiden Fällen gleichviel RAM für den Storageserver nutzt, ist die Performance und Sicherheit vergleichbar.
 
Digi-Quick schrieb:
Das virtualisierte Storage OS braucht doch Zugriff auf die Platten und den Controller *konfus*
Oder meinst du damit, daß Controller und Platten exklusiv (Vt-d bzw. IOMMU) an das StorageOS durchgereicht werden sollten - also gar nicht vom Host-OS / Hypervisor verwaltet werden!

@Ironcurtain
Wozu willst du überhaupt Virtualisieren? Sollen da weitere VMs für ganz andere Dinge drauf laufen, oder war das nur eine generelle Verständnisfrage?
Zu deinem Vorhaben:
Prinzipiell kann man das so machen. wie praktikabel das ganze sein wird entscheidet sich anhand der verfügbaren Bandbreiten vor Ort (vor allem der Upload ist interessant) und den jeweils zu übertragenden Datenmengen.
Die initiale Synchronistaion würde ich auf jeden Fall lokal machen!

Ansonsten solltest du dir Gedanken über einen - möglicherweise permanenten - VPN Tunnel machen.

Warum WD-Green?
1. sind das keine NAS Platten, sind weder für 24/7 noch für den Stapelbetrieb (also mehr als 2 Stück in einem Gehäuse) freigegeben.
2. sind die vergleichsweise langsam

Alternativen
HGST-NAS (7200 U/min - dürften daher deutlich "schneller" sein als die anderen.)*
WD-Red
Seagate NAS

*Schneller bedeutet hier höhere sequentielle Transferrate, kürzere Zugriffszeit und höhere IOPs.
Zum Vergrößern anklicken....

Meine Frage wegen dem virtualisieren war erstmal nur generell. Weil ich bisher in Verbindung mit Freenas, Nas4free etc. immer nur gehört habe das gehört nicht virtualisiert. Also gibt es unter ESXI die Möglichkeit Omnios in einer vm laufen zu lassen und die Platten direkt an das OS durchzuschleifen. Sodass ich Omnisos jederzeit woanders direkt installieren kann und die Platten mit allen Datasets importieren kann?
Das Thema virtualisieren ist insofern interessant weil mein Gen8 mit einem XEON Prozessor ausgestattet ist und 16 GB Arbeitsspeicher hat und er dadurch auch noch andere Aufgaben in weiteren vm's erledigen könnte als die reine Datenbereitstellung.

Das die WD Green Platten nicht für 24/7 ausgelegt sind ist mir klar. Allerdings sollen meine Server auch nicht rund um die Uhr halten und ich packe da auch nicht alles mit Platten voll.

Dann werde ich mich mal al napp-it ran wagen. Kann man sicherlich in virtualbox oder vmware erstmal mit rum spielen.
 
Ironcurtain86 schrieb:
Dann werde ich mich mal al napp-it ran wagen. Kann man sicherlich in virtualbox oder vmware erstmal mit rum spielen.
Zum Vergrößern anklicken....

Am Besten ESXi free installieren (5.5U2 oder neueste 6.0), dann das ZFS Server OVA Template mit OmniOS herunterladen und in ESXi importieren. Wenn schon ein HBA (z.B. LSI 9207 o.ä.) vorhanden ist, den in ESXi auf pass-through stellen und OmniOS zuweisen.

Storagemanagement dann per Browser und http://omnios-ip:81
http://www.napp-it.org/doc/downloads/napp-in-one.pdf
 
Hallo,

habe einen halbvollen Mirrorpool mit weiteren Mirror-vdevs vergrößert. Keine weiteren Schreiboperationen auf dem Pool.
Weniger Minuten später wurde bei einem der neuen Mirror-vdevs eine Platte durch eine andere Platte ersetzt. (nappit - Disk -> replace).
Laut meinem Verständnis für ZFS, sollte das sehr schnell gehen, da keine/wenige Nutzdaten auf diesem vdev liegen.
Des weiteren steht es immer geschrieben, das beim Resilvern eines Mirrors nur von den Platten des betroffenen vdevs gelesen wird.

Bei meinem Experiment waren aber beim Resilvern der Festplatte ALLE Platten des gesamten Mirror-Pools beteiligt. Das ganze dauerte 15 Minuten.
Was lief da falsch, bzw. was habe ich nicht richtig verstanden?
 
Ganz exakt könnte das nur ein ZFS Entwickler beantworten. Klar ist aber

- 15 Minuten ist sehr schnell
- Resilver kopiert weder die Platte 1:1 noch werden einfach belegte Datenblöcke einer Platte lediglich umkopiert sondern es wird der Datenbestand insgesamt durchsucht und die Blöcke die sich auf der einen Platte befunden haben dann umkopiert.

Es werden also alle Platten für das Suchen benötigt, das kostet die Zeit, kopiert wird aber nur das was auf der Platte war hier also praktisch nichts.

Gute Erläuterung dazu
https://blogs.oracle.com/roch/entry/sequential_resilvering
 
Hallo Gea,

danke für Deine Erläuterungen. Da hatte ich die Vorgehensweise beim Resilvern eines mirror-vdevs missverstanden.
Jetzt ist alles klar und erklärbar, was ich gesehen habe.
 
Zuletzt bearbeitet:
gea schrieb:
Am Besten ESXi free installieren (5.5U2 oder neueste 6.0), dann das ZFS Server OVA Template mit OmniOS herunterladen und in ESXi importieren. Wenn schon ein HBA (z.B. LSI 9207 o.ä.) vorhanden ist, den in ESXi auf pass-through stellen und OmniOS zuweisen.

Storagemanagement dann per Browser und http://omnios-ip:81
http://www.napp-it.org/doc/downloads/napp-in-one.pdf
Zum Vergrößern anklicken....

Bedeutet das ich brauche einen Raid Controller? Die Platten im Gen8 mit dem Standard SAS-Port weiterleiten ist nicht möglich oder keine gute Idee?
 
Für ESXi gilt
- booten kann man ESXi von einem USB Stick oder einem unterstützten Controller mit Festplatte.
Man kann allerdings auf USB Sticks keine VMs ablegen.
Üblicherweise nimmt man also einen Onboard Controller, meist Sata/AHCI zum Booten von ESXI und zum Ablegen der Storage VM.

Für das Storage gibt es jetzt drei Optionen
- ESXi Virtual disks: für ZFS highend Storage nicht geeignet.
- Physical RAW Disk Mapping: Einzelne Festplatten werden per ESXi Controller verwaltet und durchgereicht.
Ok, aber nur wenn echtes pass-through nicht verfügbar ist.
- pass-through, Controller und Platten werden von ESXi nicht verwaltet sondern direkt vom Mainboard an eine VM durchgereicht. Das ist die professionellste und schnellste Variante.

Man braucht also idealerweise zwei unabhängige Controller, einen zum Booten von ESXi + Storage VM und einen für das Storage mit pass-through. Ich habe nur einen HP G7 der das nicht kann, mit dem G8 sollt es aber möglich sein von Onboard Sata zu booten und den Controller im Sata mode an die Storage VM durchzureichen. Vielleicht hat das das ein G8 User schon mal gemacht und kann das kommentieren.

Der Storage Controller darf aber kein Raid anbieten sondern nuss für ZFS die einzelnen Platten bereitstellen (HBA oder Sata/AHCI mode).
 
gea schrieb:
Für ESXi gilt
- booten kann man ESXi von einem USB Stick oder einem unterstützten Controller mit Festplatte.
Man kann allerdings auf USB Sticks keine VMs ablegen.
Üblicherweise nimmt man also einen Onboard Controller, meist Sata/AHCI zum Booten von ESXI und zum Ablegen der Storage VM.

Für das Storage gibt es jetzt drei Optionen
- ESXi Virtual disks: für ZFS highend Storage nicht geeignet.
- Physical RAW Disk Mapping: Einzelne Festplatten werden per ESXi Controller verwaltet und durchgereicht.
Ok, aber nur wenn echtes pass-through nicht verfügbar ist.
- pass-through, Controller und Platten werden von ESXi nicht verwaltet sondern direkt vom Mainboard an eine VM durchgereicht. Das ist die professionellste und schnellste Variante.

Man braucht also idealerweise zwei unabhängige Controller, einen zum Booten von ESXi + Storage VM und einen für das Storage mit pass-through. Ich habe nur einen HP G7 der das nicht kann, mit dem G8 sollt es aber möglich sein von Onboard Sata zu booten und den Controller im Sata mode an die Storage VM durchzureichen. Vielleicht hat das das ein G8 User schon mal gemacht und kann das kommentieren.

Der Storage Controller darf aber kein Raid anbieten sondern nuss für ZFS die einzelnen Platten bereitstellen (HBA oder Sata/AHCI mode).
Zum Vergrößern anklicken....

Ich besitze den hp proliant gen8 und habe dort die G1610T CPU gegen einen Intel Xeon E3-1230 v2 ausgetauscht. Das Mainboard bietet 1x MiniSAS SFF-8087 auf 4-fach SATA Backplane und 1x SATAII an. An den MiniSas sollen die Storage Festplatten und an den 1x SATAII eine 128gb SSD mit ESXI und allen VM's. Wäre gut, wenn jemand eine Rückinfo geben kann, ob das Vorhaben damit sinnvoll ist oder ob man da jetzt einen Raid Controller benötigt. Bei Freenas und Nas4free wurde ZFS immer ohne raid controller aufgebaut. Es wurde sogar davon abgeraten, weil der raid controller die Platten vorberereitet zur Verfügung stellt und man keine Chance hat an die Daten zu kommen, wenn der Raid Controller sich verabschiedet hat.
 
Ironcurtain86: eine Möglichkeit (so habe ich es gelöst) ist in den PCI-E Slot einen S-ATA Controller zu stecken, dort eine SSD/HD dran für das Datastorage. Den onboard Controller reichst du per Passthrough direkt an die ZFS VM durch. Bei meinem ML310E ging das. Man muss darauf achten das der Controller ESXi kompatibel ist. Ich habe diese Karte genommen: http://www.amazon.de/gp/product/B00E0M2MW8 - Evtl. muss man noch ein Treiberpaket installieren wenn man direkt auf 5.5U2/6.0 installiert hat: https://tinkertry.com/for-esxi-6-0-...nics-still-seem-to-be-working-but-unsupported
 
Ich muss leider sagen, dass ich immer noch nicht verstehe, warum es nicht sinnvoll ist die SSD mit ESXI und den VM's an den SATA Port vom Mainboard zu stecken und die Storage Platten ganz normal in das 4er Bay im Proliant Gen8 Microserver, dass per SAS mit dem Mainboard verbunden ist. Warum brauche ich zusätzlich so eine SATA Controller Karte?
 
Ganz einfach wenn du den b120i an die vm durchreichen willst wäre auch der SATA Port weg da auch er an dem onboard Controller hängt.

Du brauchst einen controller mit einer Platte + storage VM und einen Controller zum durchreichen wenn du Zfs sinnvoll nutzen willst.

Gesendet von meinem HTC EVO 3D X515m mit der Hardwareluxx App
 
Jetzt habe ich es verstanden. Man leitet sogesehen den ganzen controller weiter und weil der onboard Sata Port am gleichen Controller hängt funktioniert das nicht. Funktioniert die Controllerkarte bei meinem Server, die Opticum verlinkt hat? Im Anfangspost vom Gen8 Microserver Threat ist sie nicht aufgeführt.
 
Ironcurtain86: die wird zu 99% funktionieren. Wie angegeben musst ggf. die Treiber nachinstallieren.
 
Hallo zusammen,

ich habe in meinem FreeNAS folgenden S.M.A.R.T. Error:

Device: /dev/ada1, 363 Currently unreadable (pending) sectors

Ist es möglich die unlesbaren Sektoren zu reparieren?
 
Nein. Die Platte wird früher oder später (eher früher) komplett den Geist aufgeben.
 
Sehr wohl "reparierbar" (den Sektor verlierst du halt, wird dann gegen Reserve getauscht), aber a) kein ZFS-spezifisches Problem, b) wie Futureman schon sagt ist das ein Ausfallindikator für die Platte (ich hatte das letztens mit 2 Sektoren und hab die Platte ersetzt - bei deinen 363 defekten Sektoren steht der Exitus unmittelbar bevor), und c) kommts zur Behebung drauf an, an welches System du die Platte anklemmst. Ich habs unter Ubuntu mit hdparm gemacht.

Die Empfehlung muss lauten: ASAP Ersatzplatte besorgen und tauschen, solange es noch geht. Wenn sichs vermeiden lässt, kein Weiterbetrieb bis der Tausch durch ist.
 
gea schrieb:
a.) ist sehr konservativ und sollte keine Probleme bereiten.
b.) und c.) sollte man unter Last testen ob die NFS Freigabe stabil ist (Sowohl Vmware wie auch Illumos haben an NFS Änderungen vorgenommen). Es gibt aber bei jeder Variante einzelne Problemberichte.

Da Probleme oft von der jeweiligen Hardware abhängen, würde ich immer eine gewisse Testphase bei neuer Software vorsehen. Insgesamt würde ich erst einen Test mit den aktuellen Versionen machen. Mögliche Probleme liegen in Verbindungsabbrüchen von ESXi zu NFS unter Last.
Zum Vergrößern anklicken....

Vielen Dank gea, ich bin jetzt mit folgender Konfiguration ins Rennen gegangen:

ESXi 5.5 U3 + vmware tools ESXi 5.5 + OmniOS 151014 f090f73 LTS September
 
Es gibt doch seit gestern einen Patch dafür steht ja auch in dem Artikel.
 
Bei mir läuft jetzt ESXi5.5U2 noch mit der napp-it-15b-Appliance und ich habe kleine Probleme damit. Als Plattenanschluß fungiert der per VT-d durchgereichte und mit IT-Firmware (v20) versehener H200-Controller aus meiner Sig. Die Appliance habe ich RAM-technisch erstmal auf den 3GB belassen und lediglich 2 kleine WD5003RE-Platten als Mirror drangepappt.
Das ich damit keine grossen Sprünge machen kann, ist mir klar und wenn ich per SMB Ordner und Dateien draufkopiere, ist die gefühlte Performance absolut brauchbar. Die Appliance sollte eigentlich testweise auch als NFS-Datastore genutzt werden. Leider ist der NFS-Datastore nicht wirklich nutzbar. Selbst der Start einer kleinen Lubuntu-VM mit 1GB vRAM und 8GB vDISK dauert fast eine halbe Stunde. ESXi-technisch sollte es mit NFS eigentlich keine Probleme geben und der 5.5U2 wurde ja so auch von "gea" empfohlen.
Wo kann ich da jetzt ansetzen?
 
Danke für den Tipp.
Ich habe jetzt gerade nochmal mit und ohne Sync probiert und was soll ich sagen, es ist jetzt mit beiden Settings deutlich schneller als vor 4 Wochen. Ich kappier grad überhaupt nichts mehr, denn nach der Umstellung habe ich weder die Appliance noch den ESXi neu gestartet und der ESXi selbst läuft auch schon wieder gut 14 Tage.

Kopieren von 27GB an VMDKs startet mit Sync bei allem was Gig-Ethernet hergibt, geht zwischenzeitlich mal zurück bis auf ~80MB/s und steigt dann wieder fast bis auf 90MB/s. Dafür werden 4min30 veranschlagt und das kommt so mit etwas über 5min auch fast hin. Kopiere ich denselben VMDK-Ordner ohne Sync startet das Kopieren ebenfalls bei Gig-Ethernet und fällt dann nur noch auf ~95MB/s zurück. Als Zeitbedarf wird hier ebenfalls wieder 4min30 veranschlagt und irgendwo zwischen beiden Zeiten wird das Kopieren fertig. Da der ESXi noch andere VMs in einem SSD-DS ausführt, geht das komplett in Ordnung. In beiden Fällen ist die Performance deutlich besser, als es der H200-Controller mit IR-FW dank fehlendem WB-Cache jemals schaffen könnte.
 
Anmelden, um zu antworten.

Ähnliche Themen

G
Wieviel ZFS steckt in Qnap ZFS ??
Antworten
5
Aufrufe
880
gea
G
Shihatsu
ZFS Pool "verschicken"
Antworten
9
Aufrufe
592
sandreas
S
thor17
Ceph Node auf bestehenden ZFS Pools
Antworten
3
Aufrufe
533
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
AliManali
*erledigt* Perc H310 flashen
Antworten
2
Aufrufe
309
AliManali
AliManali
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