besterino
Legende
Lecker Ding! Halt uns gerne auf dem Laufenden!
Ich versuche gerade verzweifelt einen NFS Share in vsphere 6.0 zu mounten. Gibt es da ein Problem mit dem Netzwerkadapter (VMXNET3/E1000)?
Müsste doch eigentlich total easy sein: IP napp-it 10.0.0.10 | tank/vm mit NFS on - Im VSphere Client dann 10.0.0.10 und /vm - leider mountet er nicht
Als SMB-Share auf den Rechnern alles Problemlos :/
Müsste doch eigentlich total easy sein: IP napp-it 10.0.0.10 | tank/vm mit NFS on - Im VSphere Client dann 10.0.0.10 und /vm - leider mountet er nicht
Als SMB-Share auf den Rechnern alles Problemlos :/
fdiskc2000
Enthusiast
- Mitglied seit
- 30.05.2007
- Beiträge
- 2.230
Fummel ich auch jedes mal hin. Versuch mal /Tank/vm
besterino
Legende
Du musst das mit dem Namen "IP:/pool/Filesys" einhängen. Bei meinem kleinen HP sieht das dann wie folgt aus:
(der obere halt - der 2. Datastore ist auf dem USB-Stick selbst)
(der obere halt - der 2. Datastore ist auf dem USB-Stick selbst)
@gea
Zum Einstieg ist imho das
X11SSL-CF für an die 300€ derzeit noch geeigneter (dazu rate ich zumindest meist)
10Base-t kannste für die Differenz später nachrüsten (oder ne gebrauchte intel von Ebay holen) und ne m2 bekommste mit nem 25€ PCIe Adapter rein ...
Trotzdem gz zum Board
Zum Einstieg ist imho das
X11SSL-CF für an die 300€ derzeit noch geeigneter (dazu rate ich zumindest meist)
10Base-t kannste für die Differenz später nachrüsten (oder ne gebrauchte intel von Ebay holen) und ne m2 bekommste mit nem 25€ PCIe Adapter rein ...
Trotzdem gz zum Board
Zuletzt bearbeitet:
Sehe ich grundsätzlich auch so.
Die Intel X550 ist momentan noch recht nutzlos da ganz neu und daher kaum unterstützt.
Für mich ist es aber ein Testboard, auch mit der 10G Option. Ich hoffe ja dass Treiber für ESXi und Illumos nicht allzu lange brauchen und dann wird es das ideale Storage/AiO Board bei dem man eine tolle Basis bis 64 GB ECC RAM mit CPUs ab 50 Euro hat die auch vt-d Support haben. Für gut 400 Euro hat man sowohl 2 x 10G wie 8 x Sata + 8 x Sata/ 12G SAS (= 16 schnelle/gute Ports für Platten). Normalerweise kostet ja allein eine Intel Netzwerkkarte mit 2 x 10G soviel wie hier das komplette Board.
Die Intel X550 ist momentan noch recht nutzlos da ganz neu und daher kaum unterstützt.
Für mich ist es aber ein Testboard, auch mit der 10G Option. Ich hoffe ja dass Treiber für ESXi und Illumos nicht allzu lange brauchen und dann wird es das ideale Storage/AiO Board bei dem man eine tolle Basis bis 64 GB ECC RAM mit CPUs ab 50 Euro hat die auch vt-d Support haben. Für gut 400 Euro hat man sowohl 2 x 10G wie 8 x Sata + 8 x Sata/ 12G SAS (= 16 schnelle/gute Ports für Platten). Normalerweise kostet ja allein eine Intel Netzwerkkarte mit 2 x 10G soviel wie hier das komplette Board.
Danke! Also der Tipp mit dem tank war das eine!
Es hat wohl was mit der Sophos UTM zu tun. Diese ist bei mir DHCP-Server/Standartgateway mit 10.0.0.1 - mit der Firewall Regel Intern zu Intern (Any) läuft es. So richtig gefallen tut mir das aber nicht.
Mmh. Dachte das mit der UTM wars - jetzt in mein Pool im vSphere wieder inaktiv (ausgegraut). Ich habe ihn zwischenzeitlich sogar durchsucht. Dann nach ein paar Minuten alles weg :/
Es hat wohl was mit der Sophos UTM zu tun. Diese ist bei mir DHCP-Server/Standartgateway mit 10.0.0.1 - mit der Firewall Regel Intern zu Intern (Any) läuft es. So richtig gefallen tut mir das aber nicht.
Mmh. Dachte das mit der UTM wars - jetzt in mein Pool im vSphere wieder inaktiv (ausgegraut). Ich habe ihn zwischenzeitlich sogar durchsucht. Dann nach ein paar Minuten alles weg :/
Zuletzt bearbeitet:
teqqy
Enthusiast
Das mit der UTM und der Regel hätte es auch nicht sein können. 
Blöde Frage, aber hast du mal in die Logs geguckt? Unter Linux steht da zumindest immer was brauchbares drin.
Blöde Frage, aber hast du mal in die Logs geguckt? Unter Linux steht da zumindest immer was brauchbares drin.
Du hattest in einem früheren Post mal das Board EPC612D4U-2T8R von ASRock empfohlen. Was sind denn Deiner Meinung nach die wesentlichen Vorteile vom SuperMicro X11SSH-CTF gegenüber dem EPC612D4U-2T8R von ASRock?
Zuletzt bearbeitet:
Vorteil - Eigentlich nur der Einstiegspreis.
Mit SAS, 10G und Xeon sind beide etwa gleichteuer und damit das Asrock der bessere Kauf.
Bei Sockel 1151 gibt es aber bereits mit dem G4400 für 50 Euro eine CPU mit ECC und vt-d die für fast alles reicht.
Interessant ist momentan eher die Version ohne 10G (da noch zu neu). Ich habe die 100 Euro Aufpreis für 2 x 10G in Kauf genommen da es sich mehr um ein Testboard handelt und ich hoffe dass vor allem ESXi aber auch Illumos das bald unterstützen.
Mit SAS, 10G und Xeon sind beide etwa gleichteuer und damit das Asrock der bessere Kauf.
Bei Sockel 1151 gibt es aber bereits mit dem G4400 für 50 Euro eine CPU mit ECC und vt-d die für fast alles reicht.
Interessant ist momentan eher die Version ohne 10G (da noch zu neu). Ich habe die 100 Euro Aufpreis für 2 x 10G in Kauf genommen da es sich mehr um ein Testboard handelt und ich hoffe dass vor allem ESXi aber auch Illumos das bald unterstützen.
Noch inoffiziell aber Release Note und Datum sind bereits online
ReleaseNotes/r151018
ReleaseNotes/r151018
Es gibt bei mir einen Datenpool "dpool" mit 4TB Nennkapazität. Um den Füllstand zu prüfen, habe ich die beiden folgenden Kommandos abgesetzt:
Nun sind hier tatsächlich noch 1,29 TB frei, aber warum gibt der Befehl "zpool list" an, dass noch 2,31 TB frei sind? Das sollte doch ein Bug ein, oder?
Code:
root@host:/root# zpool list dpool
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
dpool 3,62T 1,31T 2,31T - 14% 36% 1.00x ONLINE -
root@host:/root# zfs list dpool
NAME USED AVAIL REFER MOUNTPOINT
dpool 2,22T 1,29T 96K /dpoolNun sind hier tatsächlich noch 1,29 TB frei, aber warum gibt der Befehl "zpool list" an, dass noch 2,31 TB frei sind? Das sollte doch ein Bug ein, oder?
Ich meine mich zu erinnern das diese Frage erst kürzlich in einer der mailing listen (ZoL,OpenZFs,illumos) rund um ZFS gefragt wurde... finde es auf anhieb aber nicht.
Aber hier von 2010 klick dich mal durch die Antworten:
https://lists.freebsd.org/pipermail/freebsd-stable/2010-May/056648.html
... eine Antwort aus der liste:
zpool shows the total bytes of storage available in the pool.
zfs shows the total bytes of storage available to the filesystem, after redundancy is taken into account.
du shows the total bytes of storage used by a directory, after compression and dedupe is taken into account.
"ls -l" shows the total bytes of storage currently used to store a file,
after compression, dedupe, thin-provisioning, sparseness, etc.
----
Ich denke mal dein dpool ist ein raidz?
Somit würde ich sagen alles korrekt, da zfs die Redundanz verständlicherweise als belegt mitzählt im Gegensatz zu zpool
Zuletzt bearbeitet:
Es ist ein Mirror aus 2 x 4 TB Platten. Selbst wenn "zpool" hier die insgesamt noch verfügbare Kapazität im Pool anzeigen sollte, ist die Ausgabe dann trotzdem nicht schlüssig (SIZE ist ja auch nur 3,62T und ALLOC mit 1,31T kann dann schon gar nicht richtig sein). Napp-it zeigt hier übrigens auch unschlüssige Werte an:
ALLOC + AVAIL = 1,31T + 1,29T = 2,6T vs. SIZE = 3,6T
Das ist jetzt kein Riesending, aber man sollte schon genauer hinsehen.
zfs list und zpool list ermitteln ihre Angaben höchst unterschiedlich und betrachten unterschiedliche Sachverhalte. Auch muss man jetzt noch unbedingt Reservierungen berücksichtigen, die vom verfügbaren Platz abgehen obwohl sie keinen Platz verbrauchen. napp-it macht ja per default z.B. eine 10% Reservierung auf den Pool, damit ist der verfügbare Platz für alle Dateisysteme nur noch 90%
Dann ist es ja so, dass das Speichern von 1 Byte je nach blocksize z.B. 4k verbraucht, dann gibt es noch Fragmentierung, Metadaten, Prüfsummen, compress und dedup. Insgesamt ist daher jede Angaben für den verfügbaren oder belegten Platz ungenau, zum Background vielleicht noch The Blog of Ben Rockwood oder http://docs.oracle.com/cd/E19253-01/819-5461/gamml/index.html
zpool list ist dabei die Angabe mit der man am wenigsten anfangen kann wenn man den verfügbaren Platz für die Dateisysteme wissen will. zfs list ist da informativer. Wenn man die Angabe zu den Reservierungen addiert hat man den tatsächlich verfügbaren und belegten Platz noch am ehesten.
Last not least, ZFS rechnet in Tib (1T = 1 Tib), die Verkäufer verkaufen Platten aber mit dem größeren TB Wert (4 TB ca 3,6 TiB)
Dann ist es ja so, dass das Speichern von 1 Byte je nach blocksize z.B. 4k verbraucht, dann gibt es noch Fragmentierung, Metadaten, Prüfsummen, compress und dedup. Insgesamt ist daher jede Angaben für den verfügbaren oder belegten Platz ungenau, zum Background vielleicht noch The Blog of Ben Rockwood oder http://docs.oracle.com/cd/E19253-01/819-5461/gamml/index.html
zpool list ist dabei die Angabe mit der man am wenigsten anfangen kann wenn man den verfügbaren Platz für die Dateisysteme wissen will. zfs list ist da informativer. Wenn man die Angabe zu den Reservierungen addiert hat man den tatsächlich verfügbaren und belegten Platz noch am ehesten.
Last not least, ZFS rechnet in Tib (1T = 1 Tib), die Verkäufer verkaufen Platten aber mit dem größeren TB Wert (4 TB ca 3,6 TiB)
Ich lese gerade:
Erpressungs-Trojaner "Samsa" mit neuer Taktik: Erst schauen, dann verschlüsseln | heise Security
Darin geht es um einen neuen Typ Ransomware namens Samsa der ein perfides Verhalten hat:
Erst versucht er sich möglichst weit im Netz zu verbreiten und die IT Infrasatruktur zu erfassen ohne aktiv zu werden.
Dazu gehören eventuell auch Informationen über Backups und Backupzeiten.
Es kann passieren dass er zunächst nur Backups verschlüsselt sobald man Backuplaufwerke anschliesst.
Ansonsten sammelt er Infos über vorhandene Platten, Shares und Dateien.
Wenn er dann aktiv wird, dann auf allen Systemen gleichzeitiig.
Dadurch kann es passieren, dass man eines Morgens aufwacht und
- Daten aller infizierten Arbeitsplätze sind verschlüsselt
- Daten aller erreichbaren Netzwerkshares und eventueller administrativer Freigaben sind verschlüsselt
- alle Windows Snaps/ Shadow Copies oder Snaps auf die ein lokaler Admin Zugriff hat sind gelöscht
- Alle oder einige Backups sind auch verschlüsselt
Frage: Inwieweit sind ZFS Systeme betroffen oder können helfen
- aktuelle Daten: sind unsicher. Wenn ein Administrator betroffen war, kann er alle Dateien auf dem Server verschlüsseln, ein normales SMB share ist anfällig
- ZFS Snaps: sind nicht betroffen da die nur readonly sind und nur von eimem lokalen Root-Benutzer auf dem Storage gelöscht werden können (kein remote destroy).
kleine Ergänzung zu "erst mal schauen"
Vielleicht wartet Samsa auch noch auf den 12.4.2016 um noch größeren Schaden anzurichten >> http://badlock.org/
Dann soll eine kritische Lücke in SMB bei Windows und SAMBA veröffentlicht/gepatcht werden. ZFS mit kernelbasierten Solaris/Illumos/OmniOS SMB Server soll davon aber nicht betroffen sein.
Erpressungs-Trojaner "Samsa" mit neuer Taktik: Erst schauen, dann verschlüsseln | heise Security
Darin geht es um einen neuen Typ Ransomware namens Samsa der ein perfides Verhalten hat:
Erst versucht er sich möglichst weit im Netz zu verbreiten und die IT Infrasatruktur zu erfassen ohne aktiv zu werden.
Dazu gehören eventuell auch Informationen über Backups und Backupzeiten.
Es kann passieren dass er zunächst nur Backups verschlüsselt sobald man Backuplaufwerke anschliesst.
Ansonsten sammelt er Infos über vorhandene Platten, Shares und Dateien.
Wenn er dann aktiv wird, dann auf allen Systemen gleichzeitiig.
Dadurch kann es passieren, dass man eines Morgens aufwacht und
- Daten aller infizierten Arbeitsplätze sind verschlüsselt
- Daten aller erreichbaren Netzwerkshares und eventueller administrativer Freigaben sind verschlüsselt
- alle Windows Snaps/ Shadow Copies oder Snaps auf die ein lokaler Admin Zugriff hat sind gelöscht
- Alle oder einige Backups sind auch verschlüsselt
Frage: Inwieweit sind ZFS Systeme betroffen oder können helfen
- aktuelle Daten: sind unsicher. Wenn ein Administrator betroffen war, kann er alle Dateien auf dem Server verschlüsseln, ein normales SMB share ist anfällig
- ZFS Snaps: sind nicht betroffen da die nur readonly sind und nur von eimem lokalen Root-Benutzer auf dem Storage gelöscht werden können (kein remote destroy).
kleine Ergänzung zu "erst mal schauen"
Vielleicht wartet Samsa auch noch auf den 12.4.2016 um noch größeren Schaden anzurichten >> http://badlock.org/
Dann soll eine kritische Lücke in SMB bei Windows und SAMBA veröffentlicht/gepatcht werden. ZFS mit kernelbasierten Solaris/Illumos/OmniOS SMB Server soll davon aber nicht betroffen sein.
Zuletzt bearbeitet:
Bzzz
Enthusiast
...und weil CoW auch bedeutet, dass die Veränderungen gegenüber einem Snapshot erst Speicherplatz belegen, wenn sie gemacht werden, wird der Admin ggf. durch plötzlich rasant steigende Plattenbelegung gewarnt. Ohne würde ja nur überschrieben, ohne Mehrverbrauch (ggf. Temp-Files). Falls das ZFS zu Beginn ungeschickterweise auch schon mehr als halb voll ist, wird die Sache gar nicht erst durchlaufen können, denn wohin solls auch geschrieben werden
@gea, zu dem Board weiter oben: Hast du nen Vergleich zu den Supermicro X10SDV-4C-TLN2F oder -TLN4F? Die haben ja ebenfalls 10Gb (durch den SoC) an Bord und liegen bei <550€, wenngleich ohne SAS.
@gea, zu dem Board weiter oben: Hast du nen Vergleich zu den Supermicro X10SDV-4C-TLN2F oder -TLN4F? Die haben ja ebenfalls 10Gb (durch den SoC) an Bord und liegen bei <550€, wenngleich ohne SAS.
Ich habe folgendes Problem mit VMware (ESXi 6.0U2) und OmniOS (neustes bloody - clean install):
In ESXi ist Passthru für folgende PCI-Geräte eingestellt.
IBM M1015
i210-T2 NIC Onboard (nur Port 1 ist passthru - nicht Port 2)
i350-T4 NIC (Nur Port 1 und 2 ist passthru - nicht Port 3 und 4)
X540-T1 NIC
Der IBM M1015 ist für OmniOS durchgereicht und funktioniert einwandfrei.
Problem habe ich bei den NIC's: Ich möchte manche NIC-Ports einzelnen zu OmniOS durchreichen... bisher ohne Erfolg.
Testweise habe ich die NIC-Ports mal in einer Win7-VM durchgereicht und alles wird dort ohne Probleme erkannt und ich sehe
alle NIC-Interfaceses im Geräte-Manager.
Wenn ich die i210 Port1, oder i350 Port 1,2 zu OmniOS durchreiche werden diese irgendwie gar nicht vom System erkannt.
Ein dlcdm show-link oder show-phys listet nur den e1000 vom VM-Network auf (also keine Passthru Geräte).
Wenn ich die x540-T1 an OmniOS durchreiche und ein dladm show-phys eingebe friert die komplette VM ein.
Da alles unter Windows funktioniert poste ich hier und nicht im VMware-Thread, da es ein vermutlich ein OmniOS problem ist?
Wieso kommt OmniOS damit nicht klar? (Ein nativ-installiertes OmniOS erkennt die NICs)
Wenn das Passthru für NICs unter OmniOS nicht klappt bleibt nur wie bisher die Möglichkeit die NIC von exsi zu verwalten und den e1000/VMXNET zu nutzen.
In ESXi ist Passthru für folgende PCI-Geräte eingestellt.
IBM M1015
i210-T2 NIC Onboard (nur Port 1 ist passthru - nicht Port 2)
i350-T4 NIC (Nur Port 1 und 2 ist passthru - nicht Port 3 und 4)
X540-T1 NIC
Der IBM M1015 ist für OmniOS durchgereicht und funktioniert einwandfrei.
Problem habe ich bei den NIC's: Ich möchte manche NIC-Ports einzelnen zu OmniOS durchreichen... bisher ohne Erfolg.
Testweise habe ich die NIC-Ports mal in einer Win7-VM durchgereicht und alles wird dort ohne Probleme erkannt und ich sehe
alle NIC-Interfaceses im Geräte-Manager.
Wenn ich die i210 Port1, oder i350 Port 1,2 zu OmniOS durchreiche werden diese irgendwie gar nicht vom System erkannt.
Ein dlcdm show-link oder show-phys listet nur den e1000 vom VM-Network auf (also keine Passthru Geräte).
Wenn ich die x540-T1 an OmniOS durchreiche und ein dladm show-phys eingebe friert die komplette VM ein.
Da alles unter Windows funktioniert poste ich hier und nicht im VMware-Thread, da es ein vermutlich ein OmniOS problem ist?
Wieso kommt OmniOS damit nicht klar? (Ein nativ-installiertes OmniOS erkennt die NICs)
Wenn das Passthru für NICs unter OmniOS nicht klappt bleibt nur wie bisher die Möglichkeit die NIC von exsi zu verwalten und den e1000/VMXNET zu nutzen.
Zuletzt bearbeitet:
Ich habe ein OmniOS unter ESXi mit Passthrough installiert und dummerweise die virtuelle Platte für das OmniOS zu klein konfiguriert. Nun habe ich nur noch 500 MB freien Platz und werde kaum auf die kommende r151018 upgraden können. Gibt es irgend eine schlaue Idee wie ich die virtuelle Platte vergrößernd kann? Unter ESXi ist das ja schnell konfiguriert aber wie bekommt das dann OmniOS mit?
fdiskc2000
Enthusiast
- Mitglied seit
- 30.05.2007
- Beiträge
- 2.230
Habe gerade versucht das nachzubauen. Also ich habe zwar r151016 mit ESXI 6.0U1, aber meine Intel Pro/1000 PT Dual Port taucht mit dem einen Port den ich durchgereicht habe auf. Wird zwar als e1000g1 angegeben in Napp-IT, aber ich denke zumindest sollte es grob klappen.
Du solltest es hinkriegen, indem Du OmniOS eine zusätzliche, grössere virtuelle Platte gibst und mit dieser dann aus dem rpool einen Mirror machst.
Oracle Solaris 11 Express: Mirroring Your ZFS Root Pool und dabei "zpool set autoexpand=on rpool" setzt.
Danach hängst Du die alte virtuelle Disk im ESXi ab und testest ob die neue bootet, Wenn ja (rpool sollte jetzt wg. einer fehlenden Platte DEGRADED sein), solltest Du mit "zpool detach rpool <alte Platte>" einen sauberen und grösseren rpool haben.
Zuletzt bearbeitet:
Danke. Könnte auch an ESXi 6U2 liegen.
Ich ruder gerade mal auf 6U1 zurück und teste. die i210/i350 NIC sind ja im igb treiber enthalten... müssten also erkannt werden.
Zuletzt bearbeitet:
So, ebend ESXi 6.0 U1 installiert. (vSphere Client auf Windows weiterhin 6U2):
Einmal omnios LTS14 und omnios_bloody probiert. Leider genau das gleiche. Beim Passthru von i210 oder i350 stürtzt die VM bei "dladm show-phys" ab und bei der x540 schon direkt nach root-pw-eingabe.
Hat jemand noch eine Idee?
Hier mal die wichtigen Schritte in Bildern, damit es bei der Konfiguration auch keine Missverständnisse gibt:
1) Passthru aktivieren und reboot:
2) der omnios-VM neue PCIE-Geräte zuweisen:
Und hier die beiden Fenster wo die VM dann abgestürtzt ist und einfach aus ist:
Einmal omnios LTS14 und omnios_bloody probiert. Leider genau das gleiche. Beim Passthru von i210 oder i350 stürtzt die VM bei "dladm show-phys" ab und bei der x540 schon direkt nach root-pw-eingabe.
Hat jemand noch eine Idee?
Hier mal die wichtigen Schritte in Bildern, damit es bei der Konfiguration auch keine Missverständnisse gibt:
1) Passthru aktivieren und reboot:
2) der omnios-VM neue PCIE-Geräte zuweisen:
Und hier die beiden Fenster wo die VM dann abgestürtzt ist und einfach aus ist:
