[Sammelthread] ZFS Stammtisch

...
ich habe mein system leider geupdatet und nun funktioniert mein zfs nicht mehr. ich finde aber irgendwie die lösung nicht im netz. die freigaben
sind nicht mehr zu sehen und die daten auch nicht...
...
Deine zpool status Meldung sieht doch völlig in Ordnung aus. Schau mal nach ob deine Pools überhaupt gemountet sind mit df -h und lass dir mal den Pfad anzeigen mit ls -al /t3st/musik . Wenn nicht gibt es unter Ubuntu dafür ein extra paket namens mountall. Mach mal mountall, siehe:
https://github.com/zfsonlinux/pkg-zfs/wiki/Ubuntu-ZFS-mountall-FAQ-and-troubleshooting
Wenn alles gemountet ist und du in der Konsole auf die Daten kommst liegt das Problem wo anders, wahrscheinlich beim NFS oder Samba Server, je nach dem was du mit "Freigaben" meinst.
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
das passiert bei mountall...
Code:
root@david-linux:/home/david# mountall
/bin/sh: 1: gvfsd-fuse: not found
mountall: mount /run/user/1000/gvfs [5124] brach mit dem Status 127 ab
swapon: /dev/disk/by-uuid/a270bc3b-6ba7-42f0-b977-8441acb3e88e: swapon failed: Das Gerät oder die Ressource ist belegt
mountall: swapon /dev/disk/by-uuid/a270bc3b-6ba7-42f0-b977-8441acb3e88e [5130] brach mit dem Status 255 ab
mountall: Problem beim Aktivieren des Swap: /dev/disk/by-uuid/a270bc3b-6ba7-42f0-b977-8441acb3e88e
 
Und wenn das dann noch ein Problem darstellt, kommen wir zu den Postings mit dem angewärmten Öl weiter oben zurück.
 
damit geht es wieder, nur beim nächsten start muss ich es erneut eingeben.

EDIT: das ist kein problem(behoben durch editieren der /etc/default/zfs)

Dafür gibt es ja extra das angepasst mountall was ich dir bereits verlinkt habe, das sollte man unter Ubuntu auch so machen, denn das ist der richtige Weg. Ein Eintrag in /etc/default/zfs ist falsch und nur für Debian richtig.

https://github.com/zfsonlinux/pkg-zfs/wiki/Ubuntu-ZFS-mountall-FAQ-and-troubleshooting schrieb:
3.0 Frequent Mistakes
....
Do not set ZFS_MOUNTALL=y in the /etc/default/zfs file.
....
Den Link hättest du dir mal besser gleich durchgelesen, es hat schon seinen Grund warum man dafür ein extra das mountall Package angepasst hat... ;)
 
Zuletzt bearbeitet:
Hat jemand von Euch schon mal mit den EONNAS Systemen auf ZFS Basis Erfahrung gesammelt? Es gibt diese Systeme ja sogar mit 10GBit Interface, nur frage ich mich, ob da die Hardware überhaupt mitspielt? Meine folgendes Model: Infortrend EonNAS Pro Series 850-2
 
Mit 5.5 und e1000 gabs extrem schlechte Performance und Stabilität bis hin zum Einfrieren.
Ich hatte aber noch nicht die Zeit um das neue 5.5U1 zu testen (samt Update auf die darin enthaltenen VMware tools)

Hintergrund meiner Frage ist, dass ich massive Probleme habe, weitere VMs, welche auf dem Omnios-datastore liegen zu starten. Auch ist der Datendurchsatz unter aller Kanone.

Installiert ist bei mir ESXi5.5U1 und in kernel/drv/1000g.conf steht bereits
Code:
#tcp segmentation offload disable
tx_hcksum_enable=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0;
lso_enable=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0;

OK, dies scheint VMWare bei 5.5U1 geändert zu haben.

Ferner bin ich mir ganz sicher, dass ich Omnios als Solaris 10 64 bit VM angelegt habe - mir aber im SphereClient Solaris 11 64 bit angezeigt wird.
Wobei ich mir nicht sicher bin, ob Sphere erst nach Installation der Tools ein Solaris 11 daraus gemacht hat, wenn dem so wäre müsste es doch an dem Bug im Perl-Script liegen?

Was ist jetzt besser - auf ESXi 5.1 zurück zu gehen oder die vnic e1000 zu löschen?
 
Die Frage ist, ob 5.5U1 nach Installation der darin enthaltenen vmware tools ohne meine Änderungen in der /kernel/drv/1000g.conf stabil läuft. Wenn nicht dann würde ich vmxnet3 unter Last testen.

Ansonsten war die letzte 5.1 mit e1000 ultrastabil hatte aber das 32 GB RAM Limit (zumindest in der Free). Das ist ja der Hauptvorteil der 5.5.
 
Die Frage ist, ob 5.5U1 nach Installation der darin enthaltenen vmware tools ohne meine Änderungen in der /kernel/drv/1000g.conf stabil läuft. Wenn nicht dann würde ich vmxnet3 unter Last testen.

Das versteh ich jetzt nicht ganz, was du meinst.

Dieses obige Codefragment ist ja jetzt bei 5.5U1 enthalten. Ich habe es nicht hinzugefügt.
Der Blogger hat ja hier Solaris 11.1 getestet und noch einen Bug im Perl Script gefunden. Jetzt weis ich aber nicht, wie sich Omnios bei ESXi meldet. Denn offensichtlich scheint es ja so zu sein, dass mit der Installation der Tools ESXi die installierte Version verändert.

Der VM hab ich eine vnic mit e1000 und eine mit vmxnet3 zugewiesen. Dann müsste es doch reichen, wenn ich die e1000 vor dem Start aus den Einstellungen lösche? Oder gleich 2 vmxnet3 draus machen?
Tools deinstallieren und nochmals neu installieren?

Ansonsten war die letzte 5.1 mit e1000 ultrastabil hatte aber das 32 GB RAM Limit (zumindest in der Free). Das ist ja der Hauptvorteil der 5.5.
Ausgerechnet in der Kiste hab ich jetzt 32GB RAM drinne, aber mehr werden es denk ich auch nicht werden.

Apropo RAM, du hast mal einen Link zu Kingston hier eingestellt. Inzwischen gibt es aber von Kingston keine 8 GB Riegel mehr für mein Board. Ist dir da was bekannt?
 
Obige Änderung habe ich Oktober letzten Jahres in meine ESXi Appliance Distribution eingefügt damit e1000 damit funktioniert .

http://napp-it.org/downloads/index.html
ESXi 5.5/5.1 + ZFS/OmniOS/napp-it All-IN-ONE VM - VMs & Appliances - VMware Forum

oder handelt es sich um eine Neuinstallation?
E1000 löschen oder deaktivieren reicht aber bei Problemen.

Ansonsten sollte Oracle Solaris 11.1 und Solaris10-64 die gleichen Tools installieren. Es ist nur eine Solaris ISO in ESXi enthalten. siehe napp-it // webbased ZFS NAS/SAN appliance for OmniOS, OpenIndiana, Solaris and Linux downloads Punkt 10.

Zum RAM kann ich nichts sagen, ansonsten mal hier suchen (oder SM HCL):
Speichersuche | Kingston
 
Zuletzt bearbeitet:
Moin,

bin auch mal wieder hier! :hail:

Da hier grad die ESX-e1000-Diskussion läuft wollte ich mal meinen Senf dazu beitragen:
Letzte Woche hat nach einem halben Jahr Dauereinsatz meine OmiOS-Installation unter ESX 5.1.0, 1157734 erstmalig Probleme gemacht - dafür aber gleich richtig!
Gleich 4 meiner 9 HDDs sind völlig aus dem Ruder gelaufen und haben mir meinen Pool zerstört. Entsprechend sind natürlich alle VMs die hierüber (NFS) bereitgestellt wurden abgeschmiert. Glücklicherweise konnte ich den Pool dennoch reparieren - ein Backup hätte ich natürlich auch gehabt...
Nun aber das eigenartige: seitdem lief NFS über e1000 nicht mehr stabil - das Starten einer VM ging bis 95%, dann war der NFS-Datastore verschwunden. Ich hab mir nun nicht die Mühe gemacht und nach der genauen Ursache geforscht, ich hab einfach die e1000 gegen eine vmxnet3 eingetauscht - und siehe da: alles wieder stabil!
Ergo: auch unter ESX 5.1 gibts Probleme mit e1000!

Grüße
effemmess
 
Hi,

weiß jemand ob man an den internen SATA Ports des Supermicro X7DBE (Intel ESB2 SATA 3.0Gbps Controller) Platten größer als 2 TB benutzen kann unter Omnios?
 
Oder zuvor als mal wieder das Thema Encryption kam wo irgendwelche Leute mit ihren Vermutung kamen dass native ZFS-Crypto ja schneller als LUKS/geli sei weil es ja der "kompliziertere Aufbau" sei oder so ähnlich. Das verschlüsselte Blockdevices unter ZFS zwar in der Praxis enorm schneller und ressourcensparender sind als die native Solaris-ZFS-Crypto (performancetechnisch der letzte Scheiß) haben die Herren wohl noch nicht bemerkt.

Stützt du deine Aussagen auf irgendwelche veralteten Benches der Solaris ZFS Crypto als es noch keine AES-NI Unterstützung seitens Solaris gab? Oder woran machst du fest dass es jetzt (=2014) immer noch performancetechnisch "der letzte scheiß" ist?
 
Ich habe bei mir auch noch die 5.1 mit e1000 laufen und Null Probleme, bei anderen Konstellationen hatte ich auch massive Probleme, weil der ESXi immer die Verbindung zu den per NFS angebundenen VM Pools verloren hatte. Hab mich allerdings (unter anderem auch aus Zeitmangel) nicht getraut mal die neue ESXi Version diesbezüglich anzutesten.

Würde mich aber auch mal interessieren, wie das bei der aktuellen Version jetzt aussieht...
 
oder handelt es sich um eine Neuinstallation?
Ich selbst habe ESXi5.5 neu installiert und auch Omnios 151008j neu installiert.

Ansonsten sollte Oracle Solaris 11.1 und Solaris10-64 die gleichen Tools installieren. Es ist nur eine Solaris ISO in ESXi enthalten. siehe napp-it // webbased ZFS NAS/SAN appliance for OmniOS, OpenIndiana, Solaris and Linux downloads Punkt 10.

Die gleichen Tools mag sein, aber nicht die gleichen Treiber - zumindest so habe ich es in dem Blog verstanden.
...
As my next step I was planning on running some dtrace commands, and accidentally noticed that the drivers I have installed are the Solaris 10 version and not the Solaris 11 version.
...
bis--> Now we have the correct version installed.

Deshalb hatte ich gestern ja gefragt wie sich Omnios bei ESXi meldet - als Solaris 10-64 oder Oracle Solaris 11-64. Wie aber zur perl-script-laufzeit '$minor' abgefragt werden kann - da müssen die Profis ran, ich hab da keine Ahnung. :wink:
Denn Omnios habe ich als Solaris 10 64 bit VM angelegt mir wird aber im SphereClient Solaris 11 64 bit angezeigt.
Code:
root@aio:~# find /kernel/drv/ -ls |grep vmxnet3
 86890    2 -rw-r--r--   1 root     root         1071 Mär 28 13:15 /kernel/drv/vmxnet3s.conf
 86892   34 -rw-r--r--   1 root     root        [COLOR="#FF0000"]33888 [/COLOR]Mär 28 13:15 /kernel/drv/amd64/vmxnet3s
 86891   25 -rw-r--r--   1 root     root        [COLOR="#FF0000"]24336 [/COLOR]Mär 28 13:15 /kernel/drv/vmxnet3s
root@aio:~# find . -ls |grep vmxnet3
 86204   34 -rw-r--r--   1 root     root        34072 Feb 11 11:31 ./vmware-tools-distrib/lib/modules/binary/2009.06_64/vmxnet3s
 86209   35 -rw-r--r--   1 root     root        35088 Feb 11 11:31 ./vmware-tools-distrib/lib/modules/binary/11_64/vmxnet3s
 86182   34 -rw-r--r--   1 root     root        [COLOR="#FF0000"]33888 [/COLOR]Feb 11 11:31 ./vmware-tools-distrib/lib/modules/binary/10_64/vmxnet3s
 86187    2 -rw-r--r--   1 root     root         1071 Feb 11 11:31 ./vmware-tools-distrib/lib/modules/binary/10/vmxnet3s.conf
 86190   25 -rw-r--r--   1 root     root        [COLOR="#FF0000"]24336 [/COLOR]Feb 11 11:31 ./vmware-tools-distrib/lib/modules/binary/10/vmxnet3s
 86177   25 -rw-r--r--   1 root     root        24424 Feb 11 11:31 ./vmware-tools-distrib/lib/modules/binary/2009.06/vmxnet3s
 86176    2 -rw-r--r--   1 root     root         1071 Feb 11 11:31 ./vmware-tools-distrib/lib/modules/binary/2009.06/vmxnet3s.conf
 86200   25 -rw-r--r--   1 root     root        24568 Feb 11 11:31 ./vmware-tools-distrib/lib/modules/binary/11/vmxnet3s
 86195    2 -rw-r--r--   1 root     root         1071 Feb 11 11:31 ./vmware-tools-distrib/lib/modules/binary/11/vmxnet3s.conf
root@aio:~#
Treiber wiederum scheinen von Solaris 10_64 zu sein.

Dieser anscheinende Bug ist aber in 5.5 immer noch enthalten:
For Solaris 11.1, $minor is 11, which forces $osDir to be Solaris 10. Bug ?
Either way it's very easy to fix - just change "<" to ">":

if ($minor > $currentMinor) {

Entsprechend sind natürlich alle VMs die hierüber (NFS) bereitgestellt wurden abgeschmiert.
Nun aber das eigenartige: seitdem lief NFS über e1000 nicht mehr stabil - das Starten einer VM ging bis 95%, dann war der NFS-Datastore verschwunden.

Gleiches Verhalten bei mir auch. Leider nicht replizierbar, weil mal bleibt die VM gleich kurz nach dem Start hängen oder auch erst bei 95%. Der verschwundene NFS-datastore ist nach ein paar Minuten aber wieder da. Keine Einträge in den logs zu finden.
Ich hab mir nun nicht die Mühe gemacht und nach der genauen Ursache geforscht, ich hab einfach die e1000 gegen eine vmxnet3 eingetauscht - und siehe da: alles wieder stabil!
Ergo: auch unter ESX 5.1 gibts Probleme mit e1000!

Danke, für den Hinweis. Dann versuch erstmal gar nicht mit 5.1 sondern bleibe bei 5.5 und nur vmxnet3 Treibern.
Jetzt muss ich mir nur noch überlegen, wie ich das rpool_customize.pl bei der Installation drauf bekomme.
USB wäre ein Möglichkeit. Hab aber an einer anderen Kiste einen USB-Stick onboard gesteckt, Omnios bzw. napp-it zeigt mir aber gleich 'removed' an.
Irgendwie funzt das automounten nicht oder nicht richtig oder ich bekomms mangels Wissen nicht hin. :heul:

Ich habe bei mir auch noch die 5.1 mit e1000 laufen und Null Probleme, bei anderen Konstellationen hatte ich auch massive Probleme, weil der ESXi immer die Verbindung zu den per NFS angebundenen VM Pools verloren hatte. Hab mich allerdings (unter anderem auch aus Zeitmangel) nicht getraut mal die neue ESXi Version diesbezüglich anzutesten.

Würde mich aber auch mal interessieren, wie das bei der aktuellen Version jetzt aussieht...

Die anderen Konstellationen und massive Probleme beziehen sich jetzt aber hoffentlich nicht auf vmxnet3???
Wir reden ja von der aktuellen Version ESXi5.5 und Omnios 151008j und den massiven Probleme mit e1000.

Morgen kann ich dir hoffentlich mehr sagen, denn da werde ich eine Neuinstallation mit 2 x vmxnet3 machen.
 
Zuletzt bearbeitet:
Die anderen Konstellationen und massive Probleme beziehen sich jetzt aber hoffentlich nicht auf vmxnet3???
Wir reden ja von der aktuellen Version ESXi5.5 und Omnios 151008j und den massiven Probleme mit e1000.

Doch das bezog sich auf vmxnet3 unter 5.1, ich bin ja erst auf e1000 gewechselt nachdem vmxnet massiv Probleme verursacht hatte.

Ich finde die Diskussion sollte sich nicht nur auf einen Adaptertyp beschränken, da wohl jeder je nach Hardware unterschiedliche Probleme zu haben scheint.

Damals hat gea noch vmxnet3 unter 5.1 empfohlen, welcher hingegen bei mir Ausfälle verursachte.
 
Stützt du deine Aussagen auf irgendwelche veralteten Benches der Solaris ZFS Crypto als es noch keine AES-NI Unterstützung seitens Solaris gab? Oder woran machst du fest dass es jetzt (=2014) immer noch performancetechnisch "der letzte scheiß" ist?

Die "veralteten" Benches aus dem März 2013 (ein Jahr, veraltet, ernsthaft?) die ich zuletzt verlinkt haben waren bereits mit AES-NI Support, steht sogar direkt im ersten Satz des Oracle Blogposts.
https://blogs.oracle.com/BestPerf/entry/20130326_sparc_t5_2_zfscrypto
Das heißt die miserablen Werte sind bereits MIT AES-NI Support!
Schau doch einfach mal zwei CPUs im Wert von 3500€ bei AES-256-CCM CM Encryption: 3 Concurrent Sequential Writes machen! 3868MB/s unverschlüsselt aber nur 1566MB/s verschlüsselt, das sind ca. 60% weniger Leistung! Unter Windows/Linux/FreeBSD mit verschlüsselten Blockdevices hat man 1 bis 15% weniger Leistung!
Es gibt natürlich auch noch ältere Bechmarks die ich mal verlinkt habe, ist aber dort alles das selbe, auch die hatten bereits AES-NI-Support.

Wenn man natürlich Sparc verwendet und kein x86 ist die Verschlüsselung genau so performant wie sie sein sollte: Man verliert nur ein paar Prozentpunkte und hat etwas höhere CPU-Last. Genau so muss es sein, so ist es auch unter anderen Betriebssystemen mit verschlüsselten Blockdevices auf x86-Hardware.
Aber wer hat hier schon Sparc? Von Oracle kaufe ich bestimmt keine Hardware. Früher zu Sun-Zeiten hätte ich noch mal drüber nachgedacht. ;)

Benchmarks hin oder her, kann man eh immer schlecht 1:1 vergleichen, viel interessanter ist folgendes:
Bis zu meinem letzten Test mit Solaris 11.1 und allen Updates im Dezember 2013 hat sich daran rein gar nichts geändert. Moderne CPUs stehen weiterhin dauerhaft zwischen 85 und 100% Last, die Datenraten sind miserabel, sind nicht wirklich konstant, manchmal nur 25% der unverschlüsselten Performance, manchmal etwas mehr, manchmal etwas weniger. Mit dmcrypt/LUKS unter Linux weiterhin 15 bis 30% CPU-Last bei fast nativer Datenrate, man verliert je nach Art der Raid-Konfiguration etwas an Performance, je nach Raidkonfiguration etwa zwischen 5 und 15%.
Alle Zahlen grobe Richtwerte, ich habe mir nicht die Mühe gemacht großartig Benchmarks zu machen, cp/rsync sowie prstat/iostat/top reichen dafür schon aus.

Und nein, es macht keinen Unterschied ob AMD oder Intel. Getestet auf einem Xeon E5-1620 und auf einem Dual-CPU System mit 2x Opteron 6344. Server-Hardware von Supermicro mit Hitachi Ultrastar 7K4000 (SAS) und HGST Deskstar 7K4000 (SATA) an LSI-SAS-HBAs.

Da ich gerne zum nativen ZFS unter Solaris wechseln würde habe ich die native ZFS-Crypto seit Release nun bereits mehrfach über die Jahre getestet. Ich werde das zum nächsten größeren Solaris Update wieder testen, da sich hier wohl kaum noch etwas tun wird, Verbesserungen würden große Änderungen am Code erfordern. Das kommt wenn wohl erst mit Solaris 11.2, wann das kommt steht wohl aktuell noch in den Sternen. Und ob sie überhaupt irgendetwas daran machen ist auch noch fraglich.

Anstatt ständig indirekt das Gegenteil zu behaupten fordere ich euch einfach mal auf SELBER Tests zu machen und hier zu berichten! Ich habe dazu schon mehrfach aufgefordert, gemacht hat es bisher keiner.
Dafür reicht schon ein Test auf ganz normaler Desktop-Hardware und 4-5 Stunden Zeit für Installation/Einrichtung/Befüllung der Platten, bevor hier jemand kommt und sagt er hätte die Hardware nicht zur Verfügung.
 
Zuletzt bearbeitet:
Bei mir meldet sich übrigens OmniOS als "anderes 32 Bit" Gastsystem und ich habe den Fehler im Script bei der Installation der Tools damals korrigiert.
Mir ist auch aufgefallen, dass je nachdem welche ESXi Version man verwendet die Anzeige unterschiedlich ist, genauso Standalone ESXi versus verschiedene VCenter Server Versionen, es wird immer was anderes angezeigt.
 
Ich hab jetzt die e1000 entfernt und danach eine neue vmxnet3 der VM zugewiesen - also jetzt wieder 2 vnics.
Nics konfiguriert alles scheint ok zu sein.

Danach hab ich vom Backup-Server ein Replicate gestartet um den aio-pool zu sichern. Backup läuft bis 73% ohne murren durch.
Dann ein Kernel Crash:
kernelcrash.PNG


Hier Anhang anzeigen messages.txt der komplette Log vom Crash.
Der Kernel-Crash ist vom Typ Defect - ich finde aber keinen Hinweis dazu was defekt sein soll.

Spaßeshalber kopiere ich von meiner Windows Dose auf den aio_pool jetzt schon mehrere 100Gb am Stück und hier crasht er nicht, auch der Kopier-Durchsatz ist ok.
Liegt es eventl. gar nicht an ESXi oder Omnios?

Kann mir bitte jemand weiterhelfen??
 
Hast du das fmdump mal gemacht, was unten steht? So ansich steht in der Meldung nichts, was man irgendwie verwerten könnte.
 
Hast du das fmdump mal gemacht, was unten steht? So ansich steht in der Meldung nichts, was man irgendwie verwerten könnte.

Für mich nichts leserliches. :-(

Code:
root@aio:~# fmdump -Vp -u 1630fc26-9694-e811-803c-956e16302b39
TIME                           UUID                                 SUNW-MSG-ID
Apr 02 2014 12:19:42.085291000 1630fc26-9694-e811-803c-956e16302b39 SUNOS-8000-KL

  TIME                 CLASS                                 ENA
  Apr 02 12:19:42.0809 ireport.os.sunos.panic.dump_available 0x0000000000000000
  Apr 02 12:20:24.9371 ireport.os.sunos.panic.dump_pending_on_device 0x0000000000000000

nvlist version: 0
        version = 0x0
        class = list.suspect
        uuid = 1630fc26-9694-e811-803c-956e16302b39
        code = SUNOS-8000-KL
        diag-time = 1396433982 81733
        de = fmd:///module/software-diagnosis
        fault-list-sz = 0x1
        fault-list = (array of embedded nvlists)
        (start fault-list[0])
        nvlist version: 0
                version = 0x0
                class = defect.sunos.kernel.panic
                certainty = 0x64
                asru = sw:///:path=/var/crash/unknown/.1630fc26-9694-e811-803c-956e16302b39
                resource = sw:///:path=/var/crash/unknown/.1630fc26-9694-e811-803c-956e16302b39
                savecore-succcess = 1
                dump-dir = /var/crash/unknown
                dump-files = vmdump.1
                os-instance-uuid = 1630fc26-9694-e811-803c-956e16302b39
                panicstr = BAD TRAP: type=e (#pf Page fault) rp=ffffff001f591630 addr=ffffff04f8e08b88
                panicstack = unix:real_mode_stop_cpu_stage2_end+9de3 () | unix:trap+db3 () | unix:cmntrap+e6 () | genunix:as_segcompar+10 () | genunix:avl_find+72 () | genunix:as_segat+3d () | genunix:as_fault+27a () | unix:pagefault+96 () | unix:trap+d23 () | unix:cmntrap+e6 () | unix:bcopy_altentry+55a () | genunix:uiomove+f8 () | fifofs:fifo_read+192 () | genunix:fop_read+5b () | genunix:read+2a7 () | genunix:read32+1e () | unix:brand_sys_sysenter+1c9 () |
                crashtime = 1396433985
                panic-time =  2. April 2014 12:19:45 CEST CEST
        (end fault-list[0])

        fault-status = 0x1
        severity = Major
        __ttl = 0x1
        __tod = 0x533be43e 0x5156ff8

root@aio:~#
 
panicstr = BAD TRAP: type=e (#pf Page fault) rp=ffffff001f591630 addr=ffffff04f8e08b88
panicstack = unix:real_mode_stop_cpu_stage2_end+9de3 () | unix:trap+db3 () | unix:cmntrap+e6 () | genunix:as_segcompar+10 () | genunix:avl_find+72 () | genunix:as_segat+3d () | genunix:as_fault+27a () | unix:pagefault+96 () | unix:trap+d23 () | unix:cmntrap+e6 () | unix:bcopy_altentry+55a () | genunix:uiomove+f8 () | fifofs:fifo_read+192 () | genunix:fop_read+5b () | genunix:read+2a7 () | genunix:read32+1e () | unix:brand_sys_sysenter+1c9 () |

Das stehts irgendwie. Da müssen aber die Solaris-Gurus ran.
 
Wieso kann ich denn Benutzernamen mit einer Länge von 12 Buchstaben nicht anlegen und Benutzernamen mit 12 Ziffern anlegen?
Ist das so gewollt?
 
Für mich nichts leserliches. :-(

Man kann jetzt zwar nach "panicstr = BAD TRAP: type=e " googeln und es bringt ganz interessante Diskussionen zutage. Dennoch ist die Ursache von Bluescreens, Pinkscreens oder Kernel Panics immer sehr schwer einzugrenzen.

Wenn wie hier das Problem sicher wiederholt werden kann, ist es ja noch einfach indem man die üblicherweise Verdächtigten der Reihe nach einzeln ausschließt/ändert.

Hardware: RAM, Bios, NIC, HBA, Kabel, Power
Software: OS, Treiber

Wenn das Problem mit ESXi 5.5 neu ist, würde ich erst mal das letzte 5.1 mit e1000 probieren.

- - - Updated - - -

Wieso kann ich denn Benutzernamen mit einer Länge von 12 Buchstaben nicht anlegen und Benutzernamen mit 12 Ziffern anlegen?
Ist das so gewollt?

Viele Systeme hatten "traditionell" eine Begrenzung auf 8 Zeichen bei Namen und Passwörtern.
Meistens geht heute mehr aber eben nicht immer und mit allen Varianten.

Ohne die Angabe um welches System es sich handelt, ist aber gar keine Aussage machbar ausser der dass man Namen nicht länger machen sollte weil es eben Probleme bereiten kann.
 
so... will mich jetzt auch zu diesem Stammtisch setzen...
Hab mir gestern einen kleinen Dell Poweredge T20 geordert und dazu 4x4TB Festplatten.
zum Einsatz soll FreeNas in der letzten Version kommen. Installieren will ich das auf einem USB-Stick.
Ich weiß, 4 GB Ram ist ein bissel Knapp bemessen, will aber später den Server auf 32 GB-ECC-RAM aufstocken. Auch von der CPU her kommt irgendwann noch ein aktuellerer Haswell Refresh mit AES und ECC-Ram Unterstütztung, aber nur, wenn es unbedingt benötigt wird.
Hab zwar noch kein Plan, ausser als CIFS-Freigabe, was ich damit noch so alles anstellen könnte... aber es ergibt sich dann bestimmt noch viel "bastellaune"
 
hihi.. grad ein bissel am basteln mit den Dell... Peinlich, das so ein modernes System mit der aktuellen Firmware nicht mit USB-Tastaturen in der UEFI-Oberfläche klarkommt...
Ich musste doch ernsthaft nach einer alten PS2-Tastatur im eigentlich schon ausgesonderten Müll wühlen...
Ansonsten gefällt mir der interne Aufbau... fast intelligentes Kabelmanagement....

hab jetzt erstmal FreeNas drauf
nun heißt es Einrichten und lernen

PS: Am Rechner wird auch nicht getrunken... und Festplatten brauch ich selbst ;)

Ich hoffe nur, das die Performance einigermaßen auch mit 4GB Ram geht... Will erst später auf 32 GB aufrüsten
 
Ich habe gerade (vor ca. 4 Wochen) einen alten PC zu einem ZFS Storage umfunktioniert mit eigentlich "unterirdischen" Vorraussetzungen - und es Funzt trotzdem :-)
2x Raidz2 aus jeweils 7 Platten (also 5+2) - 7x2 TB und 7x3 TB - Platten aus Bestand, z.T. schon über 2 Jahre alt.
Dabei unterschiedliche Drehzahlen (7200er und 5400er), Cachegrössen (8MB, 16 MB, & 64 MB) und Sektorgrössen (AF bzw. nonAF)
gemischt , das Ganze hat dann auch nur 4 GB Speicher!

Also 4 GB geht auch, zuminidest wenn man nur mit 1 Clientrechner drauf zugreift :-)

Mein eigentlich geplantes ZFS Archiv musste ich aus Finanziellen Gründen erstmal ad acta legen, somit habe ich zur Zeit auch keinen ECC Speicher drin.
 
Obige Änderung habe ich Oktober letzten Jahres in meine ESXi Appliance Distribution eingefügt damit e1000 damit funktioniert .

napp-it // webbased ZFS NAS/SAN appliance for OmniOS, OpenIndiana, Solaris and Linux downloads
ESXi 5.5/5.1 + ZFS/OmniOS/napp-it All-IN-ONE VM - VMs & Appliances - VMware Forum

oder handelt es sich um eine Neuinstallation?
E1000 löschen oder deaktivieren reicht aber bei Problemen.

Ansonsten sollte Oracle Solaris 11.1 und Solaris10-64 die gleichen Tools installieren. Es ist nur eine Solaris ISO in ESXi enthalten. siehe napp-it // webbased ZFS NAS/SAN appliance for OmniOS, OpenIndiana, Solaris and Linux downloads Punkt 10.


Ich selbst habe ESXi5.5 neu installiert und auch Omnios 151008j neu installiert.

Asche auf mein Haupt.
@gea, es war doch keine Neuinstallation. Ich hatte obiges Image runter geladen und aktualisiert.
Sorry, ich hab in den letzten Wochen zig Mal Omnios installiert und wusste es nicht mehr richtig, erst als Grub startete hab ich es gesehen.

Die gleichen Tools mag sein, aber nicht die gleichen Treiber - zumindest so habe ich es in dem Blog verstanden.

Deshalb hatte ich gestern ja gefragt wie sich Omnios bei ESXi meldet - als Solaris 10-64 oder Oracle Solaris 11-64. Wie aber zur perl-script-laufzeit '$minor' abgefragt werden kann - da müssen die Profis ran, ich hab da keine Ahnung. :wink:
Denn Omnios habe ich als Solaris 10 64 bit VM angelegt mir wird aber im SphereClient Solaris 11 64 bit angezeigt.
Code:
root@aio:~# find /kernel/drv/ -ls |grep vmxnet3
 86890    2 -rw-r--r--   1 root     root         1071 Mär 28 13:15 /kernel/drv/vmxnet3s.conf
 86892   34 -rw-r--r--   1 root     root        [COLOR="#FF0000"]33888 [/COLOR]Mär 28 13:15 /kernel/drv/amd64/vmxnet3s
 86891   25 -rw-r--r--   1 root     root        [COLOR="#FF0000"]24336 [/COLOR]Mär 28 13:15 /kernel/drv/vmxnet3s
root@aio:~# find . -ls |grep vmxnet3
 86204   34 -rw-r--r--   1 root     root        34072 Feb 11 11:31 ./vmware-tools-distrib/lib/modules/binary/2009.06_64/vmxnet3s
 86209   35 -rw-r--r--   1 root     root        35088 Feb 11 11:31 ./vmware-tools-distrib/lib/modules/binary/11_64/vmxnet3s
 86182   34 -rw-r--r--   1 root     root        [COLOR="#FF0000"]33888 [/COLOR]Feb 11 11:31 ./vmware-tools-distrib/lib/modules/binary/10_64/vmxnet3s
 86187    2 -rw-r--r--   1 root     root         1071 Feb 11 11:31 ./vmware-tools-distrib/lib/modules/binary/10/vmxnet3s.conf
 86190   25 -rw-r--r--   1 root     root        [COLOR="#FF0000"]24336 [/COLOR]Feb 11 11:31 ./vmware-tools-distrib/lib/modules/binary/10/vmxnet3s
 86177   25 -rw-r--r--   1 root     root        24424 Feb 11 11:31 ./vmware-tools-distrib/lib/modules/binary/2009.06/vmxnet3s
 86176    2 -rw-r--r--   1 root     root         1071 Feb 11 11:31 ./vmware-tools-distrib/lib/modules/binary/2009.06/vmxnet3s.conf
 86200   25 -rw-r--r--   1 root     root        24568 Feb 11 11:31 ./vmware-tools-distrib/lib/modules/binary/11/vmxnet3s
 86195    2 -rw-r--r--   1 root     root         1071 Feb 11 11:31 ./vmware-tools-distrib/lib/modules/binary/11/vmxnet3s.conf
root@aio:~#
Treiber wiederum scheinen von Solaris 10_64 zu sein.

Dieser anscheinende Bug ist aber in 5.5 immer noch enthalten:
Morgen kann ich dir hoffentlich mehr sagen, denn da werde ich eine Neuinstallation mit 2 x vmxnet3 machen.

ESXi5.5 hab ich nicht neu installiert - nur mein aio-Omnios.
In meinem obigen Quote war vmxnet3-Treiber von Solaris 10_64 installiert.
In diesem Blog Cyber Explorer: Improving VM to VM network throughput on an ESXi platform wird ja von einem Bug in /root/vmware-tools-distrib/bin/vmware-config-tools.pl berichtet.
Also bin ich her gegangen und hab mit vi das '<' gegen '>' ausgetauscht.
Nachdem die Tools installiert waren, war auch der Treiber von Solaris 11_64 installiert. Da ging aber gar nichts mehr. Ich konnte nicht mal '/var/adm/messages' per WinSCP zum Bearbeiten öffnen.
So muss ich davon ausgehen, dass für Omnios es kein Bug ist.

Jetzt hat mein Omnios nur eine vnic mit vmxnet3 und bis jetzt flutscht es auch richtig.
Hoffentlich bleibt es auch so. :hail:
 
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