VMware-Forum

Hallo,

wir haben neben dem SAN noch einen NFS-Datenspeicher (Windows), der Software, insbesondere
die OS ISO's bereitstellt.
Alles war soweit schön und gut.

Nun habe ich aber den Folder "Software" auf dem Fileserver (Pfad: \public\software) durch
ein neues "Laufwerk" ersetzt aber halt als Folder in die bestehende Freigabe gemountet und diesem somit keinen Laufwerksbuchstaben zugewiesen.
Und nun sieht das vCenter genau diesen Software-Folder nicht mehr. Warum?

Wie kann ich das für das vCenter sichtbar machen?
Eine NFS-Freigabe für diesen Folder funktioniert nicht, da schließlich der übergeordnete Folder freigegeben ist. Was nun?

Das Ganze hatte natürlich seinen Sinn. Es sollte nicht rückgängig gemacht werden.

Danke und Gruß,
Jumo

Puuuh, ich weiss jetzt nicht ob Windows NFS auch die NTFS Redirections (Junctions oder so ähnlich heissen die) im Griff hat. Scheinbar wohl nicht. Welches Windows setzt du denn als NFS-Speicher ein? Da ging für NFS auch einiges in den letzten Versionen.

An dieser Stelle noch Windows Storage Server 2003.

Aloha.

um es noch einmal aufleben zu lassen: Nein, dieses Problem ist immer noch nicht gelöst.

Interessanterweise können andere Linux-Clients auf diese Windows 2k3-Freigabe zugreifen. Nur die ESXi-Server nicht mehr.

Also über jede Idee würde ich mich freuen.

Die NFS-Freigabe ist auf dem W 2k3 nicht geändert, wozu auch, wenn alle anderen Linuxclients zugreifen können?

Wenn ich mich direkt per SSH auf einen ESXi-Server anmelde, dann sehe ich die Freigabe und kann darauf zugreifen, aber halt nicht auf das "software-Verzeichnis", das existiert nicht.

Da muss es doch ne Lösung geben!

Danke und Gruß
Jumo

Wurden die beiden betroffenen Seiten (NFS-Server-Dienst, NFS-Client im ESX) schon neu gestartet?

Warum nimmt man für NFS-Freigaben nicht gleich Linux anstatt sich mit was drangefrickelten unter Windows rumzuärgern?

Dayworker hat geschrieben:Warum nimmt man für NFS-Freigaben nicht gleich Linux anstatt sich mit was drangefrickelten unter Windows rumzuärgern?

Vielleicht weil sich nicht jeder mit Linux auskennt und bevor ich ein System verwende bei dem ich im Fehlerfall nicht weiß was ich machen muss, nehm ich lieber Windows wo ich mich durchklicken kann.

[...]ich im Fehlerfall nicht weiß was ich machen muss, nehm ich lieber Windows wo ich mich durchklicken kann

Mal ehrlich - das ist doch in Teilen eine Illusion. Natürlich bietet dir die Windows-GUI viele Optionen zum Durchklicken an. Aber nicht wenige Optionen oder Möglichkeiten sind doch gar nicht auf die GUI durchgeschliffen - da muss dann mit Registry-Keys oder Config-Dateien manuell hantiert werden. Und ob dir die für dein Problem entscheidende Option überhaupt als Klick zur Verfügung steht, entscheiden andere.

Leute wie Mark Russinovich können einen Debugger an den Windows-Prozess hängen und im Process Monitor oder Process Explorer nach der Ursache fahnden, aber das ist nur etwas für Windows-Entwickler, die genau wissen, was sie da tun.

Unter Linux hasst du im Fehlerfall die Möglichkeit, den Dienst über Verbose (-v) und/oder Debug-Schalter zur Superplaudertasche zu machen und in den allermeisten Fällen sollte sich die Fehlerursache dann in den Logs offenbaren. Im Extremfall kannst du sogar im Quellcode des Projekts suchen, ob das ein Bug/Glitch/Feature ist. Diese Möglichkeiten hast du unter Windows meist nicht. Und dann stehst du vor einem Problem und - klickst wohin?

In deinem Fall ist doch nach den Infos von dir die Lage relativ eindeutig: Bevor du den Pfad "Software" durch eine Junction ersetzt hattest, funktionierte alles. Nach dem Einhängen des Volumes findet der ESXi-NFS-Client den Pfad nicht mehr - er kann ihn nicht mehr "sehen".

Da du auf meine erste Frage nicht geantwortet hast, gehe ich davon aus, dass du Prozessfehler durch Neustarts eliminiert hast.

Ich würde als Test das Volume wieder aushängen, eine Datei in das Verzeichnis "Software" schreiben und schauen, ob es unter ESXi sichtbar ist.

Ohne jetzt auch zuviel um die Glaubensfrage zu blubbern, ich finde Windows-Server weder Gefrickel noch Mühsam zu administrieren. Im Gegenteil. Exzessives Logging kann man auch unter Windows aktivieren, wenn man weiss wies geht, genauso wie man unter Linux eine Ahnung haben muss für die Fehlerbehebung. Unter Windows habe ich noch restlos alles repariert bekommen, meine Linux-Gehversuche endeten bei der Fehlersuche meist in einer Neuinstallation nach X-Stunden misserfolg. Kommt immer darauf an was man sich gewöhnt ist.
Tägliches kann unter Windows in der Regel mit GUI erledigt werden. Vom einfachen Patchmanagement ist Linux noch meilenweit von Windows entfernt, leider.

Zum Problem:
Versuch doch mal eine neue Freigabe zu erstellen welches auch ein solcher per NTFS zu Verfügung gestellter Ordner ist, aber vorher noch keine Freigabe hatte. Wenn das klappt, sind in der Registry vielleicht noch Überreste von der vorherigen Freigabe oder sonstigen Mount-Points vorhanden.Wenn nicht, dann ist das ein Feature von NTFS welches mit NFS nicht zu funktionieren scheint und evlt. in neueren funktioniert (oder auch nicht... könnte ich Dir evtl. testen)

UrsDerBär hat geschrieben:Ohne jetzt auch zuviel um die Glaubensfrage zu blubbern, ich finde Windows-Server weder Gefrickel noch Mühsam zu administrieren.

Es ging Dayworker um den Umstand, das ein klassisches Linux-Produkt wie NFS an Windows drangefrickelt wird. Nicht um Windows allein.

UrsDerBär hat geschrieben:Im Gegenteil. Exzessives Logging kann man auch unter Windows aktivieren, wenn man weiss wies geht, genauso wie man unter Linux eine Ahnung haben muss für die Fehlerbehebung.

Ok, dann bin ich scheinbar nur zu blöd, diese Optionen zu finden.

UrsDerBär hat geschrieben:Unter Windows habe ich noch restlos alles repariert bekommen, meine Linux-Gehversuche endeten bei der Fehlersuche meist in einer Neuinstallation nach X-Stunden misserfolg. Kommt immer darauf an was man sich gewöhnt ist.

Das ist der Kern des Problems: Wenn man am Anfang solche Schwierigkeiten hat, dann färbt das Gehirn das als "Gefrickel" ein und dann bleibt es dabei.

UrsDerBär hat geschrieben:Tägliches kann unter Windows in der Regel mit GUI erledigt werden. Vom einfachen Patchmanagement ist Linux noch meilenweit von Windows entfernt, leider.

Da fällt mir der Kaffee-Pott aus der Hand - einfaches Patchmanagement? Ich ärgere mich seit Jahren über die grausamen Patchorgien von Windows-Desktops und -Servern, die immer mehr Arbeitszeit einfordern.

Aber lass mich das mit einem Zitat aus dem Film "Die Braut des Prinzen":

Vizzini: "Unvorstellbar!"
Fizzik: "Das sagst du aber oft. Ich glaube nicht, das wir das Gleiche darunter verstehen"

abschließen und dabei belassen.

@thc: Drangefrickelt finde ich trotzdem überzogen. NFS für Windows bietet sehr viel an, auch punkto Authentifizierung. Seit 2012 mit allem was es für ESXi braucht.

Logging: Mit speziellen Registry-Switches kann man für sehr viele/alle Bereiche exzessives Logging aktivieren. Klar hat man nicht die gleichen Debug-Möglichkeiten wie unter Linux. Braucht man aber auch eher selten. Schwerwiegende Probleme liegen eigentlich immer bei inkompatiblen Treiber oder Hardwaredefekten. Alles andere ist dann Applikationsbasis und muss das jeweilige Programm solche Switches haben.

Gefrickel: Weder habe ich Linux als solches bezeichnet noch finde ich es schlecht. Ich kann es nur nicht bedienen. Windows dafür schon. Daher wehre ich mich genauso wie die Linux-Kenner wenn etwas als Gefrickel bezeichnet wird das einfach nicht der Fall ist. Auf den Schlips getreten fühle ich mich deswegen aber nicht.
Auch wenn es (wieder mal) Richtung Linux vs Windows abdriftet, dass das Patch- und Treibermanagement unter Linux komplexer ist, wird wohl niemand abstreiten wollen. Mit WSUS habe ich mit den Updaterei seit Jahren absolut 0 Probleme. Probleme hatte ich unter Windows generell nur, wenn 100'000 Schrottsoftware installiert wurde. Sei es von Hersteller oder den Bedienern. Ich kann mich gar nicht erinnern wann ich in den letzten 10 Jahren einen BlueScreen in einer produktiven Umgebung gesehen habe. Mir fällt grad nur einer ein, wegen einem Treiberproblem eines USB-Gerätes. Lag aber nicht an Windows, sondern eben am Treiber.

Von daher Leben und Leben lassen...

UrsDerBär hat geschrieben:Auch wenn es (wieder mal) Richtung Linux vs Windows abdriftet, dass das Patch- und Treibermanagement unter Linux komplexer ist, wird wohl niemand abstreiten wollen.

Ich würde das schon bestreiten.

Wenn der Update-Mechanismus in Windows durcheinander kommt, ist es schwierig, ihn wieder zum Laufen zu bekommen. Dann wird man auch feststellen, wie komplex die Dateistrukturen sind, welche hinter den Updates stecken. Windows sieht von außen nur so einfach aus.

In den diversen Linux-Distributionen ist das wesentlich robuster. Und es ist klarer strukturiert und einfacher zu debuggen.

Um das mal zum Abschluß zu bringen und auf das eigentliche Thema zurückzukommen...
Ich kenne inzwischen (notgedrungen) beides und finde bei beiden Vor- und Nachteile sowohl hinsichtlich Administration, Updates und täglicher Nutzung.



Mich würde jetzt interessieren, ob "Jumo" die beiden betroffenen Seiten (NFS-Server-Dienst, NFS-Client im ESX) neu gestartet hat und/oder sein Problem andersweitig gelöst ist.

Hallo allerseits,

zur Zeit habe ich nur den NFS-Server (Dienst) neu gestartet und auf der ESXi-Seite noch nicht. Noch ohne Erfolg.

Ein kleiner beitrag zur geführten Linux <-> Windows Diskussion:
- warum nicht Linux als NFS?
wir befinden uns hier in einer reinen Windows-Umgebung (Domäne) und nur weil eine
Hand voll Maschinen mit Linux bespaßt sind, sehe ich da keinen Grund (weder technisch
noch glaubenstechnisch) einen Linux-NFS-Server zu betreiben.
Ich selbst bin in beiden Welten zu Hause und sehe genau so wie Dayworker Vor- und
Nachteile auf beiden Seiten.

Da wie geschildert NFS funktioniert und "alle anderen" (Linux und Windows Clients) darauf
zugreifen können, mag es evtl. nur an den ESX-Servern liegen, oder an Ypsmir, der Nordseite hat.
Wie oben geschrieben, habe ich den NFS-Client auf der ESXi-Seite noch nicht neu gestartet.
Wenn ich einen geeigneten Moment finde, werde ich das schnellstmöglich nachholen.

Vielen Dank.

Fein... dann sind wir uns immerhin einig, dass wir uns nicht unbedingt einig sind, ausser in der Tatsache, dass es wohl - wie so vieles - eine Frage der Gewohnheit ist...

Was mich interessieren würde, kannst Du testen ob ein neues Windows (ab 2012) das ganze packen würde oder nicht? Weil rein NFS-Protokoll-mässig ist meines Wissens erst ein 2012 in der unterstützten Liga von ESXi. Vorher funktioniert auch, die Einschränkungen weiss ich nicht, aber die die offiziell unterstützte Prokollversion ist halt tiefer als das was ESXi haben will. Ob das einen Einfluss auf von NTFS unterstützten Mounts hat, weiss ich aber nicht, würde es aber gerne wissen


Falls Du die Möglichkeiten nicht hast, könnte ich das mal testen. Problem ist nur, dass meine VM's die das betrifft jeweils mit PCI-Passtrough arbeiten und die wollen keinerlei HotAdd für ne zusätzliche Disc mehr haben... Müsste also von nem Host alle VM's herunterfahren sowie die Storage-App oder nen neue VM aufsetzen.... Beides ziemlich mühsam...

Also Windows 2012 und Windows 2012 R2 Server funktionieren einwandfrei als NFS Storage für ESXi.

Es geht darum ob ein per NTFS-Mountpoint in einem Ordner bereitgestelltes Volume ebenfalls per NFS erreichbar ist via der normalen Ordnerstruktur. Das es mit gewöhnlichen Ordner geht ist bekannt und setzte ich auch so ein

Ah ok das hatte ich überlesen.

Ich kann das am WE mal testen bin eh gerade dabei mir einen Testserver einzurichten für Win 2012 R2.

Wenn Du eh grad am testen und spielen bist, kannst auch gleich das ganze als Single-Node Cluster aufsetzen. --> Vom ReadCache auf das ClusterVolume profitieren --> Bis zu 80% des RAM's kannst da zuweisen. Wirst extrem performante Reads bekommen