[Sammelthread] ZFS Stammtisch

[effemmess]

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

Das technische Problem liegt beim Interrupt-Handling beim Passthrough. Soweit ich das verstanden habe, gibt es diese Problematik mit sämtlichen PCIe-Geräten beim Passthrough mit allen Typ-1-Hypervisor´n in allen Betriebssystemen. Hier kommt es also drauf an, wie der jeweilige Treiber des Betriebssystems das so handhabt...
Und hier sind sich wohl die Jungs (vielleicht auch ein paar Mädels) von OmniOS/Illumos noch nicht einig, ob der vom Programmierer vorgeschlagene Weg grundsätzlich so sein soll. Daher hat wohl die Lösung noch keinen Einzug in die Releases gehalten. Warum das aber nichtmal ins letzte bloody-Release Einzug gehalten hat, versteh ich auch nicht.
Jedenfalls ich hab einen funktionierenden Treiber! ...den ich allerdings seit einiger Zeit nicht nutze, da meine NVMe´s in Testservern stecken und ich zuletzt keine Zeit weder für Tests noch für den Umbau in meine Produktivsysteme hatte.
Meine damaligen intensiven Tests waren aber alle erfolgreich. Ich hatte die Nutzung als Dataset und als L2ARC, nicht aber als SLOG auf einem X10DRi-T4+ und in einem HP G6 getestet.

Im Gespräch mit dem Programmierer meinte er, das Interesse an der Passthrough-Unterstützung dieses Treibers sei wohl nicht so groß, daher hat das Thema evtl. nicht die oberste Priorität. Ich bin da anderer Meinung und denke, dass das für viele äußerst interessant ist oder sein wird, da NVMe sicher ein wichtiger Trend 2017 sein wird...
Also bekundet euer Interesse in o.g. Maillist!

- - - Updated - - -

Das ist ja ein 0815 Stick. Das mein ich jetzt nicht negativ, offensichtlich stört es ESXi nicht...
...dann nimm ich einen aus meiner Grabbelkiste.

Grabbelkiste ist nicht so gut... Die absoluten Billigteile fliegen gerne raus aus dem System und man kann seine letzten Änderungen an der ESXi-Konfiguration nicht mehr speichern. Ein Neustart ist nötig...
Ich hab die letzten Jahre gern Sandisk Extreme 3.0 genommen, jetzt nehme ich immer Sandisk Ultrafit 32GB. Die sind zwar viel zu groß (von der Kapazität) - aber von der Baugröße schön klein. Was solls...
Unbedingt wie schon grad irgendo erwähnt auf die Hitze am Stick achten!


Euch allen wünsche ich schöne Weihnachten!
...und falls ihr Frau, Mann und/oder Kinder habt, vergesst diese nicht - bei all den vielen Technikgeschenken, die ihr euch bestimmt selbst gemacht habt...

 

[MisterY]

Ich plane mein Proxmox auf ZFS zu setzen. Proxmox und die VMs sind auf einer ssd, würde aber gerne mirroring nutzen. Istdie Frage, ob ZFS ala Raid1 reicht? Wie sieht es mit der Leistung aus? Habe einen opteron 3280 und 16 gb ecc ram. Muss ich da was anpassen? Die 1TB Daten-HDD soll auch in raid 1 - soll ich hier auch auf ufs setzen, oder reicht hier normales raid1 (per software)?

 

[gea]

Das technische Problem liegt beim Interrupt-Handling beim Passthrough. Soweit ich das verstanden habe, gibt es diese Problematik mit sämtlichen PCIe-Geräten beim Passthrough mit allen Typ-1-Hypervisor´n in allen Betriebssystemen. Hier kommt es also drauf an, wie der jeweilige Treiber des Betriebssystems das so handhabt...
Und hier sind sich wohl die Jungs (vielleicht auch ein paar Mädels) von OmniOS/Illumos noch nicht einig, ob der vom Programmierer vorgeschlagene Weg grundsätzlich so sein soll. Daher hat wohl die Lösung noch keinen Einzug in die Releases gehalten. Warum das aber nichtmal ins letzte bloody-Release Einzug gehalten hat, versteh ich auch nicht.

Also bekundet euer Interesse in o.g. Maillist!

...

Ich habe auch nochmal eine Frage zum aktuellen Stand bei illumos-discuss gestellt.
https://www.mail-archive.com/discuss@lists.illumos.org/msg02742.html

mal sehen..

 

[Trambahner]

Danke.
D.h., da es NVMe-bedingt ist, dürfte das bei der Samsung 950/960 das gleiche Problem sein wie bei den Intels. Aber z.B. mit einem Raidz2 aus 8*850pro oder S3610 an einem durchgereichten 9207-8i (in einem, PCIe 3.0-Slot natürlich) würde ich vollen Durchsatz bekommen, also bis rund ~3Gb/s, bekommen? (Soviel verfügbare SSDs hab ich leider nit zum Testen )

 

[gea]

NVMe oder Sata Express ist die Zukunft.

Bei Storage kommt es aber auf iops an und da sind Enterprise Sata mit bis zu 80k iops ausreichend. Sequentiell bringt NVMe etwa soviel wie 2-3 gestripte Sata SSDs. Ein Raid-Z1 ab 3 SSDs ist auch da bereits schneller als 10G Netzwerke.

Als besonders schnelles L2ARC oder Slog macht NVMe aber Sinn.

 

[MaxRink]

NVMe oder Sata Express ist die Zukunft.

Bei Storage kommt es aber auf iops an und da sind Enterprise Sata mit bis zu 80k iops ausreichend. Sequentiell bringt NVMe etwa soviel wie 2-3 gestripte Sata SSDs. Ein Raid-Z1 ab 3 SSDs ist auch da bereits schneller als 10G Netzwerke.

Als besonders schnelles L2ARC oder Slog macht NVMe aber Sinn.

NVMe hat auch deutlich weniger wasted registerzugriffe, was die CPU entlastet. Mit dem besseren Queue Handling zusammen springen auch mehr iops raus

Gesendet von meinem ZTE A2017G mit Tapatalk

 

[layerbreak]

Grabbelkiste ist nicht so gut... Die absoluten Billigteile fliegen gerne raus aus dem System und man kann seine letzten Änderungen an der ESXi-Konfiguration nicht mehr speichern. Ein Neustart ist nötig...
Ich hab die letzten Jahre gern Sandisk Extreme 3.0 genommen, jetzt nehme ich immer Sandisk Ultrafit 32GB. Die sind zwar viel zu groß (von der Kapazität) - aber von der Baugröße schön klein. Was solls...
Unbedingt wie schon grad irgendo erwähnt auf die Hitze am Stick achten!

Ich hab den Ultrafit mit 16GB genommen.
Das negative mit der Hitzeentwicklung bei diesem Stick hab ich auch auf der Amazon-Seite gelesen. Es war jetzt aber der einzig vernünftige USB3-Stick den ich noch hatte. Werde aber in jedem Falle mit "USB Image Tool" ein Image zeitnah erstellen.
Hab jetzt auf ESXi 6.5 umgestellt - oh Mann ist das eine Umstellung. Der Client läuft jetzt im Browser und ist komplett anderster zu bedienen. Momentan muss ich die VMs nach einander von Hand starten, da ich noch nicht die Möglichkeit gefunden habe, wie die Startreihenfolge geändert wird. Die passthrough DD-Karte hat mich richtig Probleme und Zeit gekostet.
AIO auch dann gleich neu installiert und so Probleme mit der LSI vermieden.

Euch allen wünsche ich schöne Weihnachten!
...und falls ihr Frau, Mann und/oder Kinder habt, vergesst diese nicht - bei all den vielen Technikgeschenken, die ihr euch bestimmt selbst gemacht habt...

Vielen Dank.
Ja und ich wünsche Allen auch noch nachträglich ein schönes Weihnachtsfest.

 

[layerbreak]

Bei einer Neuanlage von Snaps besteht die Möglichkeit bei Hours 8-10-12-14-16-18 auszuwählen, bei Replicate auch bei Hours dafür 7;13;19
Beim Ändern wiederum nur 7;13;19

Was ist der Unterschied zwischen "-" und ";"?
Und ist es möglich, über die *.par-Datei aus "every-BC" "every-BCD" zu machen und napp-it wird dann von 6-23 Uhr tätig?

 

[gea]

Bei einer Neuanlage von Snaps besteht die Möglichkeit bei Hours 8-10-12-14-16-18 auszuwählen, bei Replicate auch bei Hours dafür 7;13;19
Beim Ändern wiederum nur 7;13;19

Was ist der Unterschied zwischen "-" und ";"?
Und ist es möglich, über die *.par-Datei aus "every-BC" "every-BCD" zu machen und napp-it wird dann von 6-23 Uhr tätig?

- ob man 7-8-9 oder 7;8;9 schreibt ist egal
- ja, man kann die Job-Parameterdatei manuell editieren, um Zeiten einzustellen die im Menü nicht angeboten werden.

 

[layerbreak]

@gea danke für die schnelle Antwort.

du hast geschrieben, dass du auf einem Testsystem ESXi6.5 bereits installiert hast. Funktioniert bei dir der automatische Start der VMs und zwar in der Reihenfolge wie du es brauchst?

 

[L0rD_LuCk]

Guten Abend,

Danke@gea für die Hilfe.
Ich hab jetzt alle Daten vom alten Debian-Server auf den neuen Solaris-Server mit folgendem Befehl übertragen:

root@Debian:~# zfs send -R tank/Backup@snapback | ssh root@XXX.XXX.XXX.XXX /sbin/zfs receive -Fdvu tank
Password:
receiving full stream of tank/Backup@snapback into tank/Backup@snapback
received 6,55TB stream in 119137 seconds (57,7MB/sec)

Ich war doch sehr verwundert über die geringe Geschwindigkeit, die anderen Dateisysteme wurde auch nicht schneller übers GBit/s Netz geschoben.
Ich vermute der Grund ist auf den Füllstand des alten Debian-Servers zurück zu führen. Ab 85% wurde die Kiste spürbar langsamer.
Komischer Weise lief der scrub immer noch mit über 300M/s durch.
Jetzt auf dem neuen Solaris-Server habe ich beim scrub 1G/s (siehe Bild).

Heißt das jetzt, dass ich mit dem neuen Server auch eine 10Gbit NIC auslasten könnte?

zu den Einstellungen
max_buf=4097152 tcp
send_buf=2048576 tcp
recv_buf=2048576 tcp
bin ich noch nicht gekommen, mir ist aber aufgefallen, dass der Drop nicht zeitabhängig sondern Volumen abhängig ist. Genau alle 4 GiB ist der Traffic auf 0 Bytes/s eingebrochen. Hat da zufällig einer eine Idee?

Vielen Dank und freundliche Grüße
L0rD_LuCk

 

[gea]

@gea danke für die schnelle Antwort.

du hast geschrieben, dass du auf einem Testsystem ESXi6.5 bereits installiert hast. Funktioniert bei dir der automatische Start der VMs und zwar in der Reihenfolge wie du es brauchst?

Ich habe das noch nicht getestet (will nicht alles herunterfahren) aber kurz nachgeschaut, man kann es in ESXi 6.5 im neuen Webmenü einstellen und zwar
- Im linken Navigator Menü auf Virtual Machines klicken
Man sieht eine Liste aller VMs, die letzte Spalte rechts zeigt "Autostart Order"

Jetzt mit der rechten Maustaste auf die VM klicken die als erste starten soll (napp-it SAN) und Autostart > increase priority wählen (=1).
Dann auf die nächste VM und increase priority wählen (=2) und so fort.

Ist aber in der Tat noch verbesserungswürdig, wenn man das anschliessend ändern möchte,
geht nur über vorheriges decrease priority.

- - - Updated - - -

Guten Abend,

Danke@gea für die Hilfe.
Ich hab jetzt alle Daten vom alten Debian-Server auf den neuen Solaris-Server mit folgendem Befehl übertragen:

root@Debian:~# zfs send -R tank/Backup@snapback | ssh root@XXX.XXX.XXX.XXX /sbin/zfs receive -Fdvu tank
Password:
receiving full stream of tank/Backup@snapback into tank/Backup@snapback
received 6,55TB stream in 119137 seconds (57,7MB/sec)

Ich war doch sehr verwundert über die geringe Geschwindigkeit, die anderen Dateisysteme wurde auch nicht schneller übers GBit/s Netz geschoben.
Ich vermute der Grund ist auf den Füllstand des alten Debian-Servers zurück zu führen. Ab 85% wurde die Kiste spürbar langsamer.
Komischer Weise lief der scrub immer noch mit über 300M/s durch.
Jetzt auf dem neuen Solaris-Server habe ich beim scrub 1G/s (siehe Bild).

Heißt das jetzt, dass ich mit dem neuen Server auch eine 10Gbit NIC auslasten könnte?

Die geringe Replikations-Performance liegt an ssh. Das ist sehr sicher aber auch sehr langsam. Ich nehme daher in napp-it gepuffertes netcat. Das geht bis an die Netzwerk/ Poolperformance.

Zu 10G
Da sollte man an die Einstellungen optimieren (tcp Einstellungen und andere) um Richtung 1000MByte/s heranzukommen,
siehe http://napp-it.org/doc/downloads/performance_smb2.pdf

 

[Trambahner]

via SSH bekomm ich mit Zfs Send/Receive durchaus 400 Mb/s über die 10G-Leitung; netcat geht dann bei großen Files bis an die mögliche Obergrenze des Durchsatzes (~800 mb/s) der Pools. Beide Maschinen sind virtualisierte FreeBSD 11 mit Haswell E3-Xeons und 12GB zugewiesenem Ram. Diverse Paramter sind, wie gea schon geschrieben hat, für 10G angepasst (braucht auch FreeBSD 11 noch)).

Regelmässige Einbrüche bekomm ich da nicht; es hängt nur von der Filegröße und wie das Zeug im Pool physikalisch verteilt gepeichert ist ab.

 

[fdiskc2000]

Moin,
ich versuche gerade einen defekte Platte zu ersetzen.
Habe das Sytem runtergefahren
die alte gegen die neue Platte ersetzt (gleiches Modell von Toshiba)
System hochgefahren und in Napp-it Platte -> ersetzen gewählt.
Dachte das ist alles ganz einfach Bekomme aber leider jetzt folgenden Fehler: cannot replace c15t500003965BA01C1Ed0 with c15t500003965BA01C1Ad0: devices have different sector alignment

Wie zum Geier denn das bei eig. gleichem Modell? Wie verfährt man denn damit?

 

[gea]

Das ist ein Problem mit der Sektoranzahl der Platten.
Da gibt es ja 512B (alt), 4k (ganz neu) und 4k Platten die 512B emulieren können.

Fällt jetzt eine Platte aus, gibt es folgende Möglichkeiten
512B -> 512B Platte: kein Problem
4k Platte -> 4K Platte (je auch mit Emulationsmodus): kein Problem, ZFS nutzt 512E immer als 4k

512B Platte in vdev mit ashift 12 (4k Modus) -> 4k Platte: kein Problem

512B Platte in vdev mit ashift 9 (512B Modus) -> 4k Platte: keine Chance
4k Platte in vdev mit ashift 12 (4k Modus) -> 512B Platte: keine Chance

Es gibt jetzt folgende Möglichkeit
- Die alte 512B Platte steckt in einem ashift=9 vdev, die neue ist 4k (unwahrscheinlich): keine Chance
- Die alte 512B Platte steckt in einem ashift=12 vdev, die neue ist 512B): Replace könnte klappen,
wenn man das System überredet, sie als 4k zu sehen, geht über eine Anpassung der sd.conf

Dazu in Napp-it im Menü Pools auf den Poolnamen klicken, es werden alle Pool Properties inkl vdev ashift gezeigt dann ds.conf anpassen (Napp-it Menü Disks > Details), siehe https://wiki.illumos.org/display/illumos/ZFS+and+Advanced+Format+disks

 

[fdiskc2000]

Ok, wir kommen der Sache näher: also der Pool steht auf ashift = 9 und besteht aus 4 x 4TB und 3 unterschiedlichen HDD
1x WD Green
2x Seagate Desktop
1x Toshiba TOSHIBA MD04ACA4 welche in den diskinfos auf target=12 steht.

Das heisst doch also beim Erstellen des Pools damals wurde die baugleiche (und jetzt defekte HDD) Toshiba für den ashift=9 pool aktzeptiert, aber bei einem replace habe ich, wenn ich Dich oben richtig verstehe, keine Chance die neue Toshiba wieder in das vdev mit ashift=9 zu integrieren?

Einzige Chance wäre dann, den pool neu aufzubauen?

 

[gea]

Wenn das vdev mit der defekten Platte tatsächlich ashift=9 hat (klingt zunächst sehr unwahrscheinlich, 4TB Platten sind normalerweise physical 4k und damit ashift=12) dann sieht es wohl schlecht aus ohne den Pool neu anzulegen (dann aber alles mit ashift=12). Achtung: ashift ist keine Pool sondern eine vdev Eigenschaft. Für maximales Chaos kann man das im Pool sogar mischen.

ps
Target=12 hat nichts mit der Anzahl Sektoren je Platte zu tun, das ist ein Controller-Port.

 

[fdiskc2000]

Danke Dir für die Erklärung.
Das VDEV ist in der Tat ashift = 9.

Im anderen Rechner ist das VDEV aus 4 x 4TB WD RED ashift = 12
das VDEV aus 4x 480GB Samsung SM863 SSD ist ebenfalls ashift = 9

Ich habe das nie wissentlich eingestellt, scheint also eine autom. Auswahl bei der Erstellung des Pools anhand von irgendwelchen Kriterien zu sein?! Schon merkwürdig.

Umstellen kann man ein VDEV ja nachträglich auch nicht mehr, oder?

 

[gea]

Ashift wird beim Anlegen des vdevs festgelegt. ZFS liest dazu die Anzahl der physikalischen Sektoren aus den Platten aus. Wird da eine Platte mit 4k physical sectorsize (4k oder 512E) erkannt, so ist das vdev automatisch ashift=12. SSD melden sich oft als 512B. Der Pool ist dann entsprechend ashift=9.

Erzwingen kann man ashift=12 unter Solarish indem man die Eigenschaften der Platte in der sd.conf überschreibt oder wenn sich eine 4k/512E Platte im neuen vdev befindet. Andere OS lassen ashift als Eigenschaft beim Erstellen des vdevs zu. Wenn wie hier ashift=9 vorliegt, so könnte es sein dass der Pool ursprünglich mit kleineren 512B Platten angelegt wurde und die Platten dann nachträglich durch größere (4k Platten mit 512E Emulation) ersetzt wurden.

Ich würde den Pool neu anlegen (mit ashift=12).

 

[layerbreak]

Ich habe das noch nicht getestet (will nicht alles herunterfahren) aber kurz nachgeschaut, man kann es in ESXi 6.5 im neuen Webmenü einstellen und zwar
- Im linken Navigator Menü auf Virtual Machines klicken
Man sieht eine Liste aller VMs, die letzte Spalte rechts zeigt "Autostart Order"

Jetzt mit der rechten Maustaste auf die VM klicken die als erste starten soll (napp-it SAN) und Autostart > increase priority wählen (=1).
Dann auf die nächste VM und increase priority wählen (=2) und so fort.

Ist aber in der Tat noch verbesserungswürdig, wenn man das anschliessend ändern möchte,
geht nur über vorheriges decrease priority.

Mit welchem Browser hast du das getestet? Denn bei mir geht zwar die erste VM als 1 zu markieren, jede weitere aber funktioniert es nicht mehr.
Ich hatte im ESXi Thread ja geschrieben, dass ich die Reihenfolge dann mit dem VShere Client eingestellt hatte, aber ESXi hält sich nicht an die festgelegte Reihenfolge, sondern versucht die VMs zu starten, die auf dem AIO liegen.

 

[AG1M]

Abend,

ich wollte OmniOS aktualisieren (derzeit r151008 stable) auf die Stable r151020, aber ich komme nicht weiter.

Folgende Schritte habe ich bisher gemacht:

pkg set-publisher -G '*' -g http://pkg.omniti.com/omnios/r151020/ omnios

pkg refresh --full

pkg update -v --be-name=omnios-r151020 entire

Da kommt aber nur diese Meldung:

root@ZFSSERVER:~# /usr/bin/pkg update --be-name=omnios-r151020
No updates available for this image.

Habe ich etwas übersehen oder vergessen?

 

[gea]

Ein OmniOS update bedeutet normalerweise

- altes Omnios Repository abmelden
- neues Repository anmelden
- pkg update aufrufen

beim Sprung auf 151020 kommt aber hinzu, dass in 151018 SunSSH durch OpenSSH ersetzt wurde.
Ein normales Update klappt daher erst über 151018, auch geht das Update auf 151020 generell erst ab 151014
https://omnios.omniti.com/wiki.php/Upgrade_to_r151020


Ich würde es so machen (Putty als root anmelden und Befehl kopieren und mit Maus-Rechtsklick in Putty einfügen)

1. Update auf 151018
pkg unset-publisher omnios
pkg set-publisher -P --set-property signature-policy=require-signatures -g http://pkg.omniti.com/omnios/r151018/ omnios
pkg update

dann reboot in 151018

2. Update auf 151020
pkg install --no-backup-be --reject pkg:/network/ssh --reject pkg:/network/ssh/ssh-key --reject pkg:/service/network/ssh --reject pkg:/service/network/ssh-common pkg:/network/openssh pkg:/network/openssh-server

pkg unset-publisher omnios
pkg set-publisher -P --set-property signature-policy=require-signatures -g http://pkg.omniti.com/omnios/r151020/ omnios
pkg update

reboot

siehe
http://napp-it.org/downloads/omnios-update.html

- - - Updated - - -

Mit welchem Browser hast du das getestet? Denn bei mir geht zwar die erste VM als 1 zu markieren, jede weitere aber funktioniert es nicht mehr..

Firefox

 

[AG1M]

Danke @gea wie immer schnell und kompetent geholfen funktioniert wunderbar, guten Rutsch wünsche ich dir.

 

[L0rD_LuCk]

Hallo und ein frohes und gesundes Jahr 2017 an alle!

Ich hab da noch mal eine Frage, meine Festplatten heißen normalerweise immer c2t0d0 c2t1d0 oder c4t0d0 c4t1d0 etc. Jetzt hab ich noch ein paar Platten eingebaut über einen M1015 im IT Mode und die Platten heißen jetzt c0t5000AE345EFB02CDd0 c0t500034345EFB0242d0 etc. Das sieht irgendwie komisch aus, und ich weiß nicht ob das normal ist, oder ob da was schief gegangen ist. Die Platten sind nicht Tau frisch wurden aber alle Low Level Formatiert. Kann man den Namen irgendwie anpassen?

Vielen Dank und freundliche Grüße
L0rD_LuCk

 

[gea]

C4t1do bedeutet dass die Platte am 1.Anschluß/Port des 4. Controllers hängt.
Für einfache Setups ist das prima da man einfach die Platte identifizieren kann.

Höngt man aber die Platte an einen anderen Port des gleichen oder anderen Rechners, wird die Platte nicht mehr gefunden. Erst ein Pool export/import behebt das Problem.

Für größere Installationen isr das unbrauchbar. Daher gibt es die WWN identifizierung wie c0t5000AE345EFB02CDd0 . Das ist eine Nummer die der Hersteller der Platte vergibt. Wenn man so eine Platte woanders anschliesst, wird sie automatisch als Teil des ZFSPools erkannt. Man braucht halt zusätzliche Tools für die Zuordnung WWN -> Backplane Einschub.

LSI Controller mit IT mode benutzen diese moderne Art der Identifizierung (wüsste gar nicht wie ich ohne das auskäme)


btw.
aus omnios-discuss
"Updates have been published for the following versions of OmniOS:

r151014 (LTS)
r151018 (Previous Stable)
r151020 (Current Stable)
r151021 (Bloody)

These updates provide minor security updates in tmpfs and procfs, and also adds support for NICs using the Chelsio Terminator 5 10/40Gb ASIC in the cxgbe driver. As these are updates to the kernel, they do require a reboot in order for the new BE to become active.

Per the usual, the new packages may be applied using: 'pkg update'

On behalf of the OmniOS team and OmniTI, I wish you a happy New Year!
/dale"

und napp-it 2017.01:
Neuerung: vereinfachte Codestruktur:
- Umstellung der Menüs von Javascript auf css
- Es wird nur noch mini-httpd benutzt (ohne Mojolicious websocketserver und Perl Framework)

 

[AG1M]

Btw. mein Update von r151008 (mit Zwischenschritt auf r151018) auf r151020 hatte am Ende nur ein Problem, aus mir unbekannten Gründen hat NetBIOS nicht mehr funktioniert, sprich bei mir eine einfache Arbeitungsgruppen Umgebung, Eingabe der IP Adresse > kein Problem mit dem SMB Zugriff, Eingabe vom NetBIOS Namen > kein Zugriff (mehr) möglich. Im CLI (via PuTTY) mit sharectl set -p netbios_enable=true smb Problem gelöst. In app-it habe ich zuvor bei Services > SMB > Properties geschaut da stand (warum auch immer) netbios_enable=false.

 

[gea]

Nexenta hat seine Verbesserungen aus NexentaStor insbesondere SMB2.1 in den SMB Server von Illumos eingebracht. Der ist seit OmniOS 151018 dabei. Die Voreinstellung ist nun halt netbios_enable=false

 

[AG1M]

Ja ich war echt total irritiert warum ich auf einmal nicht mehr per Namesauflösung darauf zugreifen konnte, da ich normal nicht über die IP Adresse zugreife, SMB Dienste liefen wunderbar, Hosts und andere Config Dateien waren auch alle ordentlich, hab echt lange im Dunkeln gestanden, wollte es nur erwähnen falls jemand mal das gleiche Problem haben sollte.

 

[MisterY]

Ich plane mein Proxmox auf ZFS zu setzen. Proxmox und die VMs sind auf einer ssd, würde aber gerne mirroring nutzen. Istdie Frage, ob ZFS ala Raid1 reicht? Wie sieht es mit der Leistung aus? Habe einen opteron 3280 und 16 gb ecc ram. Muss ich da was anpassen? Die 1TB Daten-HDD soll auch in raid 1 - soll ich hier auch auf ufs setzen, oder reicht hier normales raid1 (per software)?

*push*

 

[gea]

Das technische Problem liegt beim Interrupt-Handling beim Passthrough. Soweit ich das verstanden habe, gibt es diese Problematik mit sämtlichen PCIe-Geräten beim Passthrough mit allen Typ-1-Hypervisor´n in allen Betriebssystemen. Hier kommt es also drauf an, wie der jeweilige Treiber des Betriebssystems das so handhabt...
Und hier sind sich wohl die Jungs (vielleicht auch ein paar Mädels) von OmniOS/Illumos noch nicht einig, ob der vom Programmierer vorgeschlagene Weg grundsätzlich so sein soll. Daher hat wohl die Lösung noch keinen Einzug in die Releases gehalten. Warum das aber nichtmal ins letzte bloody-Release Einzug gehalten hat, versteh ich auch nicht.
Jedenfalls ich hab einen funktionierenden Treiber! ...den ich allerdings seit einiger Zeit nicht nutze, da meine NVMe´s in Testservern stecken und ich zuletzt keine Zeit weder für Tests noch für den Umbau in meine Produktivsysteme hatte.
Meine damaligen intensiven Tests waren aber alle erfolgreich. Ich hatte die Nutzung als Dataset und als L2ARC, nicht aber als SLOG auf einem X10DRi-T4+ und in einem HP G6 getestet.

Im Gespräch mit dem Programmierer meinte er, das Interesse an der Passthrough-Unterstützung dieses Treibers sei wohl nicht so groß, daher hat das Thema evtl. nicht die oberste Priorität. Ich bin da anderer Meinung und denke, dass das für viele äußerst interessant ist oder sein wird, da NVMe sicher ein wichtiger Trend 2017 sein wird...
Also bekundet euer Interesse in o.g. Maillist!

Tut sich gerade was.
Nexenta hat den NVMe Treiber nachgebessert.

https://www.listbox.com/member/arch...3103744:8FBB4C0C-D1CA-11E6-A873-F6C0C0E74B80/