Server primär als NAS Ersatz (VMware oder Proxmox)

Solaris protokolliert ja eher zuviel als zuwenig.
Man kann also im System und Fehlerlog erst mal nachschauen.

USB Platten machen auch gerne mal Probleme
(falls backup auf USB liegt)

Wenn es wieder auftritt, dann schauen ob man auf die Pools z.B. per WinSCP zugreifen kann bzw ob ein Pool export + import funktioniert (oder ob "etwas" den Pool blockiert)
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
OK! Danke sehr!

Ich melde mich wenn's wieder passiert!

Die Backupplatte (tank_backup single) hängt am gleichen LSI3008 wie die anderen 6 (tank raidz2)
 
ESXi meldet für die VM auf der napp-it läuft:

Die auf dieser virtuellen Maschine installierte VMware Tools-Version ist veraltet. Durch das VMware Tools-Upgrade können verbesserte Funktionen und eine bessere Stabilität bereitgestellt werden.

Wie kann ich VMware Tools aktualisieren?

BTW: Ist es erforderlich OmniOS an sich gelegentlich zu aktualisieren, wie ich das von Linux kenne (apt-get update upgrade) oder erledigt das napp-it von sich aus?

Aktuell läuft SunOS Storage 5.11 omnios-r151024-e482f10563 i86pc i386 i86pc

Ich glaube die letzte Version ist r151026
 
Zuletzt bearbeitet:
Nach dem gestrigen Update klappt die Syncronisation wieder nicht!

Wenn ich "Snapschüsse" aufrufe bekomme ich die Meldung ...

Tty.c: loadable library and perl binaries are mismatched (got handshake key 9e00080, needed 9e40080)

... und sehe die Snapshots nicht!

Wo liegt das Problem?



*** Ergänzung ***

Nach einem Update auf "18.06 dev" sehe ich wieder die Snapshots, aber die Replikationsjobs laufen nicht durch ...

my_log end 1551: error, source filesystem tank/Photos not found

Ein Reboot hilft nicht!

Wenn ich auf "18.03 pro" zurückgehe, sehe ich wieder keine Snapshots!
 
Zuletzt bearbeitet:
Unter "18.06 dev" laufen auch die Replikationsjobs wieder.

Allerding muss ich mehrmals booten bis ich wieder auf napp-it zugreifen kann! Irgendwas stimmt nicht, ich sehe folgende Fehlermeldungen ...

May 17 23:51:18 storage devfsadmd[478]: [ID 387712 daemon.error] you must be superuser to sync /etc/path_to_inst
May 17 23:51:18 storage devfsadmd[478]: [ID 473248 daemon.error] WARNING: failed to update /etc/path_to_inst
 
Nach dem Update auf r151026 habe ich einige Probleme - siehe voranstehende Posts!
Z. B. hat die VM keine IP erhalten, kein Konsolen log-in möglich ...

Ich habe jetzt auf ein Backup der "napp-it VM" zurückgesetzt r151024/18.03 Pro und möchte es nochmals versuchen und hätte dazu folgende Fragen:

1. Die VM zu löschen und eine Backupkopie zu verwenden - ist das OK oder muss man ein anderen Verfahren wählen?

2. Ich mache das Update auf r151026 wie im Punkt 3) der Anleitung beschrieben. Dort steht allerdings Update OmniOS (base OS without zones). Mite dem Befehl "zoneadm list -vi" sehe ich jedoch eine Zone "global" mit dem Status "running". Hat das einen Einfluss auf das Backup?

3. Muss ich dannach napp-it 18.03 Pro nochmals downloaden/installieren/aktivieren?

Ich habe auch zuvor versucht ein Update lt. Anleitung für VMware Tools durchzuführen - leider erfolglos.

pkg update open-vm-toos
No update available for this image.

Bitte um Hilfe ... danke!
 
Das ist ja unglaublich, was Du für Probleme mit Deinem System hast. Bei mir waren mehrere Solaris Installationen mit napp-it Fire-and-Forget.

Wenn das kein Tippfehler war: das Paket heißt open-vm-tools (mit L).
 
War ein Tippfehler ...

System ist bisher auch super gelaufen, hatte nur einmal das Problem mit den Replikationen.

Nach dem OmniOS Update habe ich Probleme ...
 
Da sind ein paar Grundinformationen wichtig

Ein aktuelles OmniOS/ Solaris wird nur mit einem aktuellen napp-it unterstützt,
siehe napp-it // webbased ZFS NAS/SAN appliance for OmniOS, OpenIndiana, Solaris and Linux Changelog

Ein OmniOS Update auf 026 geht also nur zusammen mit dem neuesten 18.01 free/03pro/06dev
(napp-it About > Update > Download..)
Bei einem alten napp-it auf einem neuen OS kommt der TTy Fehler wegen fehlender Unterstützung der Perl Umgebung


zum Recovery: Viele Wege führen nach Rom
Wenn man OmniOS oder napp-it updated wird ein Systemsnap erstellt (Bootenvironment/BE).
Bei Starten kann man damit auf einen früheren Systemstand zurückgehen.

Man kann auch die VM löschen und neu bereitstellen und den Pool importieren.
Das macht man aber nur wenn man alles verstellt hat oder man einen klaren Neustart möchte.


zum Repository
OmniOS bietet für jede stable/LTS Version ein eigenes Software Repository. Das wird nicht upgedatet sondern erhält nur kritische Bugfixes. Ein pkg update in 024 erhält also nicht die neuere Version z.B. von 026. Wenn man die neuesten Sachen möchte muss man erst auf 026 updaten und erhält da auch die neuesten Tools.

Lediglich die bloody (aktuell 027) hat immer die neueste Software (und Bugs). Die jeweilige Stable ist ein Einfrieren einer stabilisierten Bloody alle 6 Monate.
 
Tippfehler beim Post oder Tippfehler bei der Eingabe des Befehls? Sprich: funktioniert das Paket nun oder nicht?
 
Danke gea!!!

Das mit dem Repository verstehe ich jetzt (ist halt anders als bei Linux)!

Das Thema Recovery habe ich so gelöst - hoffe das ist kein Blödsinn:
Ich fahre einmal pro Monat alle VM's runter und kopiere den gesamten Datenspeicher auf eine externe HDD. Diese Kopie kopiere ich bei Bedarf einfach zurück und registriere die VM neu.

Ich denke, das Update auf 26 habe ich genau nach der Anleitung gemacht. Aktiv war zu diesem Zeitpunkt 18.3 Pro. Trotzdem ist es zu dem Fehler gekommen.

Code: 
pkg update
reboot
pkg unset-publisher omnios 
pkg set-publisher -g https://pkg.omniosce.org/r151026/core omnios
pkg update   
reboot


*** Ergänzung ***

Ich habe es nochmals nach der Anleitung auf Upgrading OmniOS gemacht ...

Code: 
beadm create xxx1
pkg set-publisher -O https://pkg.omniosce.org/r151026/core omnios
pkg update -f -r --be-name=r151026
init 6

... klappt auch nicht. Ich bekomme folgende Anzeige:

SumOS Relesas 5.11 Version ...
Copyright (c) ...
Copyright (c) ...
Loading smf(5) services descriptions: 12/12
Hostname: storage
storage console login:

Es dauert es ein paar Sekunden, dann kommt ...

Mountig ZFS filesystems: (34/34)
May 18 15:54:59 storage smbd[582]: dyndns: failed to get domainname

storage console login:

Der Host "storage" bekommt keine IP im Netz, WebGUI ist nicht erreichbar.

Nach einem neuerlichen Reboot klappt zwar der Zugriff aber es kommen die Fehlermeldungen:

... storage devfsadmd[478]: you must be superuser to sync /etc/path_to_inst
... storage devfsadmd[478]: WARNING: failed to update /etc/path_to_inst

Also ich weiss nicht was das falsch läuft und bin schon etwas verzweifelt ...


@martingo: Tippfehler NUR im Post ...
 
Zuletzt bearbeitet:
Bei dem IP Problem tippe ich auf ein Problem mit dem DNS/DHCP Server (Internet Router?)
Als DNS mal Google eintragen (8.8.8.8)

manuelle Netzwerk Konfiguration, siehe z.B.
napp-it // webbased ZFS NAS/SAN appliance for OmniOS, OpenIndiana, Solaris and Linux : OmniOS (etwas runterscrollen zu setup options)

akternativ wenn die GUI geht. System > Network ETH

Die Meldung von devfsadm habe ich in 10 Jahren noch nie gesehen oder von jemand gehört der das hatte und hatte auch noch nie die Notwendigkeit was damit zu machen. Irgendwelche Informationen dazu ob vorher urgendwas "exotisches" versucht wurde.
 
Mit der akutellen OmniOS Version und napp-it 18.03 Pro funktioniert alle bestens!
Mein Problem ist offensichtlich einzigartig, daher stellt sich die Frage ob es nicht besser wäre die VM mit napp-it-san024-jan2018.ova neu auszusetzen und das Update dann einzuspielen? Ich möchte eigentlich nicht endlos Fehler suchen und letztlich erst alles neu machen. "Exotisches" habe ich nicht versucht. DNS/DHCP habe ich geprüft - läuft!

* Kann ich dann problemlos auf meine Pools zugreifen?
* Kann ich die gesicherten Setting, die ich mit Backup erstellt habe einfach wieder einspielen oder neu konfigurieren, was letztlich nicht so viel Aufwand sein sollte.
* Wenn ich die VM neu aufsetze habe ich automatisch die napp-it Version 18.01 free, kann ich mit meinem Key auf 18.03 Pro upgraden oder brauche ich einen neuen Key?



*** ERGÄNZUNG ***

Ich habe mal eine zweite napp-it VM installiert, das Update auf OmniOS 16 hat problemlos geklappt. Offensichtlich habe ich was bei meiner erste Installation was verbockt ...

Mit der 2. VM (die erste ist natürlich down) kann ich nicht auf die Pools zugreifen - Meldung ...

Tty.c: loadable library and perl binaries are mismatched (got handshake key 9e00080, needed 9e40080)

Hat das was mit der Version zu tun 18.01 Free auf der 2. VM - 18.03 Pro auf der ersten?
 
Zuletzt bearbeitet:
OmniOS 151026 (Mai 2018) ist neuer als die erste 18.01 free (Jan 2018) oder 18.03 (März)
Man muss also napp-it jeweils auf die neueste 18.01/03/06 updaten damit das neue OmniOS unterstützt wird.
 
Hab die VM neu aufgesetzt - update auf 18.01 Free und update auf OmniOS 16. Alles funktioniert soweit aber sobald ich den Pool importiere kommt der o. a. DynDNS Fehler und ich komme nicht mehr auf die Gui.
 
Es gibt eigentlich nur eine mögliche Verbindung zwischen GUI geht nicht bzw. sonstigen Systemreaktionen und einem Pool Import und das wäre wenn das System sich wegen eines Hardware, Treiber, Platten oder Poolfehlers beim Poolimport aufhängt.

Wenn das System noch reagiert, was zeigt ein
zpool status
format
ifconfig -a

Eventuell ohne Datenplatten starten und System bzw Fehler Log anschauen ob da was erhellendes steht
ansonsten Platte um Platte einstecken und schauen ob die sich sauber melden oder eine defekt ist.
 
Seltsame Sache ...

Ich habe jetzt einige male die VM neu gestartet und es hat funktioniert - die VM hat eine IP erhalten. Beim nächsten reboot wieder das gleiche Problem mit dem DynDns - keine Verbindung zum Netzwerk. Wenn ich folgende Befehle (lt. Anleitung) eingebe steht die Verbindung sofort:

ipadm create-if vmxnet3s0
ipadm create-addr -T dhcp vmxnet3s0/dhcp

Hier noch die Logs:
Code: 
May 21 23:21:45 Storage smbd[558]: [ID 413393 daemon.error] dyndns: failed to get domainname
May 21 23:21:58 Storage last message repeated 3 times
May 21 23:21:59 Storage in.routed[454]: [ID 749644 daemon.notice] vmxnet3s0 has a bad address 0.0.0.0
May 21 23:21:59 Storage in.routed[454]: [ID 464608 daemon.error] route 0.0.0.0/8 --> 0.0.0.0 nexthop is not directly connected
May 21 23:21:59 Storage /sbin/dhcpagent[132]: [ID 778557 daemon.warning] configure_v4_lease: no IP broadcast specified for vmxnet3s0, making best guess


Nächstes Problem: Ich kann nicht auf 18.03 Pro upgraden, höchste Version ist 18.01 Pro ?

Und ... bei Aufruf von ACL on folders kommt wieder die Meldung ...

Tty.c: loadable library and perl binaries are mismatched (got handshake key 9e00080, needed 9e40080)


Hier noch die Ausgabe auf die angeführten Befehle:

Code: 
root@Storage:~# zpool status
  pool: rpool
 state: ONLINE
status: Some supported features are not enabled on the pool. The pool can
        still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
        the pool may no longer be accessible by software that does not support
        the features. See zpool-features(5) for details.
  scan: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        rpool       ONLINE       0     0     0
          c2t0d0    ONLINE       0     0     0

errors: No known data errors

  pool: tank
 state: ONLINE
status: Some supported features are not enabled on the pool. The pool can
        still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
        the pool may no longer be accessible by software that does not support
        the features. See zpool-features(5) for details.
  scan: scrub repaired 0 in 57h24m with 0 errors on Sun Mar 25 06:37:37 2018
config:

        NAME                       STATE     READ WRITE CKSUM
        tank                       ONLINE       0     0     0
          raidz2-0                 ONLINE       0     0     0
            c0t5000C500A4D1390Ad0  ONLINE       0     0     0
            c0t5000C500A4D15D91d0  ONLINE       0     0     0
            c0t5000C500A4D15DC5d0  ONLINE       0     0     0
            c0t5000C500A4D1653Ad0  ONLINE       0     0     0
            c0t5000C500A4D16D14d0  ONLINE       0     0     0
            c0t5000C500AFC829E9d0  ONLINE       0     0     0

errors: No known data errors

  pool: tank-2
 state: ONLINE
  scan: none requested
config:

        NAME                     STATE     READ WRITE CKSUM
        tank-2                   ONLINE       0     0     0
          c0t50014EE2B6BE5150d0  ONLINE       0     0     0

errors: No known data errors
root@Storage:~#


Code: 
root@Storage:~# format
Searching for disks...done


AVAILABLE DISK SELECTIONS:
       0. c0t5000C500A4D15D91d0 <ATA-ST4000VN008-2DR1-SC60-3.64TB>
          /scsi_vhci/disk@g5000c500a4d15d91
       1. c0t5000C500A4D15DC5d0 <ATA-ST4000VN008-2DR1-SC60-3.64TB>
          /scsi_vhci/disk@g5000c500a4d15dc5
       2. c0t5000C500A4D16D14d0 <ATA-ST4000VN008-2DR1-SC60-3.64TB>
          /scsi_vhci/disk@g5000c500a4d16d14
       3. c0t5000C500A4D1390Ad0 <ATA-ST4000VN008-2DR1-SC60-3.64TB>
          /scsi_vhci/disk@g5000c500a4d1390a
       4. c0t5000C500A4D1653Ad0 <ATA-ST4000VN008-2DR1-SC60-3.64TB>
          /scsi_vhci/disk@g5000c500a4d1653a
       5. c0t5000C500AFC829E9d0 <ATA-ST4000VN008-2DR1-SC60-3.64TB>
          /scsi_vhci/disk@g5000c500afc829e9
       6. c0t50014EE2B6BE5150d0 <ATA-WDC WD30EFRX-68E-0A82-2.73TB>
          /scsi_vhci/disk@g50014ee2b6be5150
       7. c2t0d0 <VMware-Virtual disk-1.0-40.00GB>
          /pci@0,0/pci15ad,1976@10/sd@0,0
Specify disk (enter its number):
 
Zuletzt bearbeitet:
Die aktuelle Free ist 18.01 vom 2.April
Erst die unterstützt die Mai Version OmniOS 151026
napp-it // webbased ZFS NAS/SAN appliance for OmniOS, OpenIndiana, Solaris and Linux Changelog

Eine ältere 18.01 Free kann per About > Update > Download 18.01 Free aktualisiert werden

Der ipadm Befehl setzt dhcp dauerhaft (auch nach reboot)
außer: man bootet in ein älteres Bootenvironment

siehe Menü Snapshots > Bootenvironment
Ist da current=default (default wird bei reboot automatisch gebootet).
Man sollte auch beim Booten dann die aktuelle Bootumgebung booten.
 
Ich kann machen was ich will, die Netzwerkverbindung klappt nicht.

Setze ich für vmxnet3s0 eine statische IP, kann ich die WebGUI unter dieser Adresse erreichen und jede IP im Netzwerk anpingen. Ein Ping auf eine beliebige Internetadresse funktioniert nicht.

Setze ich vmxnet3s0 auf DHCP, erreiche ich nicht mal die WebGUI, das System erhält keine IP zugwiesen. Folgendes konnte ich im Log finden:

Code: 
... in.routed[454]: [ID 970160 daemon.notice] unable to get interface flags for vmxnet3s0: No such device or address
... in.routed[454]: [ID 472501 daemon.notice] vmxnet3s0 has no ifIndex: No such device or address
... in.routed[454]: [ID 970160 daemon.notice] unable to get interface flags for vmxnet3s0: No such device or address
... in.routed[454]: [ID 472501 daemon.notice] vmxnet3s0 has no ifIndex: No such device or address
... in.routed[454]: [ID 749644 daemon.notice] vmxnet3s0 has a bad address 0.0.0.0
... in.routed[454]: [ID 464608 daemon.error] route 0.0.0.0/8 --> 0.0.0.0 nexthop is not directly connected
... /sbin/dhcpagent[20523]: [ID 778557 daemon.warning] configure_v4_lease: no IP broadcast specified for vmxnet3s0, making best guess
... in.routed[454]: [ID 606928 daemon.warning] sendto(vmxnet3s0, 224.0.0.2): No such device or address
... last message repeated 2 times
... in.routed[454]: [ID 970160 daemon.notice] unable to get interface flags for vmxnet3s0: No such device or address
... in.routed[454]: [ID 472501 daemon.notice] vmxnet3s0 has no ifIndex: No such device or address
... smbd[557]: [ID 413393 daemon.error] dyndns: failed to get domainname
 
Wie machst Du den Wechsel denn genau?

Ich würde vorsichtshalber für das Device manuell sowohl delete-addr und delete-if(?) machen und dann entsprechend manuell auch bei setzten mit create-if und create-addr.
 
Mit der statischen IP habe ich jetzt offensichtlich Zugriff auf das Internet. Zumindest gibt Ping CNN International - Breaking News, US News, World News and Video ein alive zurück.

Ich stelle wie folgt auf DHCP um:

Code: 
dladm show-link
LINK        CLASS     MTU    STATE    BRIDGE     OVER
vmxnet3s0   phys      1500   up       --         --

ipadm delete-if vmxnet3s0
Storage smdb[496]: dyndns: faild to get domainname

ipadm create-if vmxnet3s0

ipadm create-addr -T dhcp vmxnet3s0/dhcp

echo 'nameserver 10.0.0.1' >> /etc/resolv.conf

*** ifconfig -a zeigt auch eine gültige IP aus dem Netz an ***

Code: 
reboot


Storage smdb[501]: dyndns: failed to get domainname

Pinge in eine IP aus dem Netz an bekomme ich die Meldung

Code: 
ping 10.0.0.1
ping: sendto No route to host

Demnach ist die Einstellung nicht nachhaltig!


Was ich auch gar nicht verstehe ist die Tatsache, dass ich trotz Lizenz nicht auf 18.03 Pro upgraden kann, Version steht nicht zur Auswahl.
 
Zuletzt bearbeitet:
Das Problem wird der dhcp Server sein.
Er muss ip, subnetmask, DNS Server und Gateway bereitstellen.

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

Entweder im Menü System oder auf Console:
set static IP address
ipadm create-addr -T static -a 192.168.0.1/24 e1000g0/v4

add default route z.B.
route -p add default 192.168.0.254

zusätzlich muss Gateway (=Router) und DNS Server (z.b. 8.8.8.8) gesetzt werden


Für ein Update auf napp-it Pro 18.03+ wird ein Maschine ID Key benötigt.
Frühere Keys müssen getauscht werden (siehe auch Meldung beim Login)
napp-it // webbased ZFS NAS/SAN appliance for OmniOS, OpenIndiana, Solaris and Linux : Extensions
 
Sorry, aber ich wüsste nicht, was beim DHCP Server falsch laufen sollte. Alle anderen Clients (auch OmniOS/napp-it) erhalten problemlos ihre IP (DHCP Server = 10.0.0.1). Das Problem trat erst nach dem OminOS Upgrade auf.
 
OS Updates können immer ein neues Verhalten bringen.
Mir ist jedoch kein diesbezügliches Problem bekannt (weder aus meinen Setups noch aus Support Anfragen, auch nicht aus diversen Foren oder Illumos/OmniOS/OI Maillisten)

Im Zweifel mal auf manuelle ip umstellen.
Wenn das nach reboot läuft ist der dhcp client oder server das problem.
 
Zuletzt bearbeitet:
Ich vermute mal der Client ist das Problem. Ich sehe am Router (pfSense) nicht einmal eine Anfrage vom Client.
 
Anmelden, um zu antworten.

Ähnliche Themen

W
ASRock DeskMeet X600 als Proxmox Server?
Antworten
8
Aufrufe
2K
Supaman
Supaman
X
Ersatz für Homeassistant, GooglePhotos und NAS - Passt mein Software-Setup-Idee?
Antworten
8
Aufrufe
562
VirtuGuy
V
Dodo_now
[Kaufberatung] Spezielle Fragen zum Home Server (C-States, SATA HDD-SSD, RAID, ...)
Antworten
8
Aufrufe
761
pumuckel
pumuckel
P
[Kaufberatung] Budget-NAS für Backup, Foto-Selfhost und Firewall+VLAN - EpycEmbedded vs AM4 vs gebrauchte Workstation?
Antworten
14
Aufrufe
2K
Pete_5
P
S
[Kaufberatung] Ein Server für alle Fälle? Konsolidierung der Systeme, Hardwarefindung und Brauchen vs Schöner Wohnen.
2 3
Antworten
62
Aufrufe
7K
HansBohne
H
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