[Sammelthread] ZFS Stammtisch

[snipor]

Ich möchte mal wieder etwas an meinem System weiterbasteln. Auf meinem ESXi Host läuft u.a. ein Windows Server und eine napp-it VM. Ich habe über napp-it SMB sowie ISCSi aktiviert bzw. bereitgestellt.
Ich möchte, dass die Snaps als "Vorgängerversionen" auftauchen.
Erstelle ich nun einen ZFS Snapshot funtioniert das über SMB jedoch nicht über ISCSi. Welche Einstellungen sind nötig damit das funktioniert?
Kann mir hier jemand helfen?

 

[besterino]

Das dürfte nicht gehen.

Das „hostende“ OS hat bei iSCSI-Shares keine Kenntnis vom Inhalt. Umgekehrt wird der Snapshot aber auch „außerhalb“ des Shares angelegt (quasi als „Rohdaten“ nur mit Nullen und Einsen). Das hat zur Folge, dass das Gast-OS die Snaps nicht sehen kann.

Darüber hinaus haben iSCSI deshalb auch den Nachteil, dass das Host-OS den Snap „stumpf“ anlegt - werden gerade Daten geschrieben, sind die wenn’s dumm läuft eben auch nur teilweise im snap/inkonsistent.

 

[snipor]

Ich nehm auch immer NFS3, wenn nötig in einem eigenen Netz oder mit Firwallschutz. Ist einfach, schnell und hat im Gegensatz zu iSCSI auch kein Problem mit verzögerten Mount (Storage VM stellt NFS mit weiteren VMs ja erst mit einer Verzögerung bereit). Performancemäßig ist NFS mit gleichen Einstellungen wie sync=on und iSCSI mit writeback=off ähnlich schnell.

Vorherige Version ist ein Windows Feature (Dateiexplorer > Datei/Ordner > Eigenschaft > vorherige Version) um unter ntfs auf Windows Shadow Copies zuzugreifen. Ist der Server ZFS/Solarish so greift man stattdessen auf die ZFS Snaps des Dateisystems zu.

Nutzt man Windows um ein ZFS Dateisystem (zvol) oder Datei (ESXi vdisk) zu sharen, so greift vorherige Version nur auf Windows Shadow Copies zu. ZFS Snaps kann man zwar für das zvol oder das NFS Dateisystem anlegen. Das wirkt jedoch dann auf das ganze Dateisystem das man dann nur komplett per Rollback zurückstellen kann. Es gibt keinen dateibasierten Zugriff mehr auf ZFS Snaps. Das geht nur wenn man das ZFS Dateisystem direkt über den Solarish SMB Server freigibt.

- - - Updated - - -



Wenn man Windows als Dateiserver für ZFS Storage nutzen möchte, so legt man üblicherweise unter ZFS ein Zvol an (Dateisystem als Blockdevice). Daraus erstellt man ein iSCSI Target und mountet das daraus erzeugte LUN mit dem in Windows beiliegenden iSCSI Initiator Service. Das ZFS LUN wird dann als lokale Platte verwaltet die man per SMB freigeben kann.

Hatte mich hierauf bezogen: [Sammelthread] ZFS Stammtisch - Seite 344
Möglicherweise habe ich Gea da dann falsch verstanden? Hatte gedacht über ISCSi kann ich dann die ZFS Snaps nutzen.
Gibt es dann überhaupt eine Möglichkeit die Freigabe der Netzlaufwerke über Windows Server zu machen und trotzdem auf die ZFS Snaps zugreifen zu können?

Also was ich erreichen möchte ist folgendes:
Windows Server stellt Daten bereit (diese sollen auf ZFS liegen) --> Windows Client greift über Netzlaufwerk auf diese Freigabe des Windows Server zu --> Windows Client kann über Vorgängerversion auf die ZFS Snaps zugreifen.
Ist das möglich?

 

[CommanderBond]

zfs send -I pool/fs@snapA pool/fs@snapD > /snaps/fs@all-I

Ich versteh diesen Befehl nicht, was soll das machen? Er sagt bei mir immer /snaps/fs@all-I no such file or directory.

Muss ich den Ordner Snaps anlegen? Ist das überhaupt ein Ordner, oder ein ZFS Dataset? Was ist fs@all-I ?

also fs habe ich mit meinem Dataset Namen ersetzt. Und wo soll /snaps überhaupt liegen?

Und was sind inkrementelle Snapshots ? Kenne nur die normalen. Wo liegen die Unterschiede?

 

[Luckysh0t]

https://docs.oracle.com/cd/E19253-01/819-5461/gfwqj/index.html

Send an incremental stream from the original snapshot to create a clone. The original snapshot must already exist on the receiving side to accept the incremental stream. For example

Damit kannst du die inkremmentellen Snapshots übertragen, aber der Basis Snapshot muss schon vorhanden sein.

inkrementelle Snapshots

Von der Bedeutung bei Backups ausgehend, würde ich mal sagen, dass das hier das gleiche ist ->neue Snaps beinhalten jeweils nur die Änderungen des vorherigen und es werden alle Snaps vom gewollten Stand bis zurück zum Ursprungs Snap und der dazwischen befindlichen inkrimentellen Snaps.



Sollte ich das falsch verstanden haben, bitte ich gerne um Korrektur, da mich das @ am Ende etwas irritiert. @Gea ^^

 

[CommanderBond]

Naja die offizielle Doku kenn ich, habs dennoch net so recht verstanden nach dem Durchlesen dennoch frage ich hier

Basis Snapshot ist damit das Dataset an sich gemeint?
Also ich habe hier über nappit eingestellt dass wöchentlich ein Snapshot erstellt wird. Was sind das jetzt für Snapshots?

 

[besterino]

Das sind zusätzliche snapshots. Jedenfalls bei Nappit. Da spielt die Job-ID die entscheidende Rolle - die autosnaps haben eine andere ID als die vom Replikations-Job.

 

[gea]

viele Fragen

iSCSI und Freigabe via Windows
Hier wird ein ZFS Dateisystem als Zvol quasi wie eine Fetsplatte bereitgestellt und mit ntfs formatiert. Vorherige Version geht dann via Windows und shadow copies. Man kann zusätzlich ZFS Snaps des zugrunde liegenden Dateisystems erstellen und per Rollback darauf zurückgehen- ZFS Snaps auf Dateiebene gibt es ja nicht.

ZFS Snaps

Wenn ZFS Datenblöcke auf Platte ändert, werden vorhandene Datenblöcke nicht überschrieben (wie bei älteren Dateisystemen) sondern die Datenblöcke immer neu angelegt (CopyOnWrite). Der alte Datenblock wird dabei zum überschreiben freigegeben. Ein ZFS Snap friert diese alten Datenblöcke nun ein. Bei weiteren Änderungen wird der vorherige Zustand ebenfalls eingefroren. Daher geht ein Snap ohne Zeitverzug da nichts kopiert werden muss und friert den kompletten Zustand eines Dateisystems zum Zeitpunkt des Snaps ein.

Ein darauf folgender Snapshot macht gleiches, aber nur für Änderungen die anschliessend passieren. "Inkrementelle Snapshots" als Terminus gibt es aber nicht auch wenn ein Snap ein Einfrieren der Änderungen zum Vorsnap bedeutet.

Replikation

Bei einer erstmaligen Replikation wird nun ein komplette Dateisystem basierend auf einem Snapshot übertragen, entweder in ein Datei mit dem > Parameter oder zu ZFS receive um es unterhalb eines Zieldateisystems anzulegen. Nach einer erfolgreichen Erstreplikation wird auf dem Zielsystem ein Snap angelegt. Diesen Snap nennt man Basissnap weil er den identischen Inhalt wie der Quellsnap hat der zur Replikation benutzt wurde.

Bei der folgenden inkrementellen Replikation wird ein neuer Snap auf dem Quelldateisystem angelehgt. Er enthält nur die geänderten Datenblöcke zum vorherigen Dateisystemsnap und wird zum Zielsystem übertragen. Um sicherzugehen dass das Zielsystem identisch zum vorherigen Stand des Quellsystems ist, wird es per Rollback auf diesen Stand zurückgesetzt. Die inkrementelle Replikation sorgt nun dafür dass Quell und Zieldateisystem danach identisch sind. Anschliessend wird auf dem Ziel ein neuer Basissnap angelegt (identisch zum Snap auf dem Quellsystem. Napp-it numeriert die Snaps dazu automatisch).

Prinzipiell gibt es keinen Unterschied zwischen einem Replikationssnap und Snap der z.B. per Autosnap erstellt wird. Für die Replikation muss man die allerdings syncron halten, daher die Nummerierung und Namensgebung in napp-it.

 

[CommanderBond]

zfs send -I pool/fs@snapA pool/fs@snapD > /snaps/fs@all-I

weiß du denn auch welche bedeutet "/snaps" hier hat. fs steht für mein Filesystem, aber er sagt mir jedesmal "no file or directory". Ist snap irgendein Systemordner oder was ist das?

 

[snipor]

viele Fragen

iSCSI und Freigabe via Windows
Hier wird ein ZFS Dateisystem als Zvol quasi wie eine Fetsplatte bereitgestellt und mit ntfs formatiert. Vorherige Version geht dann via Windows und shadow copies. Man kann zusätzlich ZFS Snaps des zugrunde liegenden Dateisystems erstellen und per Rollback darauf zurückgehen- ZFS Snaps auf Dateiebene gibt es ja nicht.

Also was ich erreichen möchte ist folgendes:
Windows Server stellt Daten bereit (diese sollen auf ZFS liegen) --> Windows Client greift über Netzlaufwerk auf diese Freigabe des Windows Server zu --> Windows Client kann über Vorgängerversion auf die ZFS Snaps zugreifen.
Ist das möglich?

Das heißt mein hier beschriebenes Szenario ist nicht darstellbar? Oder gibt es irgendeine Möglichkeit das von mir gewünschte Verhalten abzubilden?

 

[gea]

Das heißt mein hier beschriebenes Szenario ist nicht darstellbar? Oder gibt es irgendeine Möglichkeit das von mir gewünschte Verhalten abzubilden?

Da ein iSCSI target aus Sicht von ZFS eine einzelne Datei oder Dateisystem ist (das nachher mit ntfs formatiert wird) kann Windows vorherige Version aus ZFS Snaps nicht gehen. ZFS weiss ja nichts von den Dateien auf dem Target. Windows Shadow Copies macht dann die vorherige Version (nicht so elegant wie ZFS und auch nicht geschützt gegen Löschen mit Adminrechten z.B. via Ramsomware).


@CommanderBond
zfs send erzeugt wie copy einen Datenstrom aus dem Unterschied der Snaps pool/fs@snapA und pool/fs@snapD .
Den kann man per redirekt ">" in eine Datei z.B. /ordner/dateiname umlenken. share ist als in dem Beispiel ein Ordnername.
Diese Datei könnte man irgenwohin bringen und dann als Input von ZFS receive nutzen
(Dort müsste man dann vor dem Receive ein Rollback auf den Snapstand fs@snapA vornehmen)


Üblichereweise schickt man den Datenstrom per pipe zu zfs receive, entweder direkt oder einen Netzwerk-Transportmechanismus
wie mbuffer, netcat oder SSH.

fs@all-I wäre ein Dateiname mit der Namensgebung eines Snaps (wegen dem @ im Namen, könnte Probleme machen)

 

[snipor]

Da ein iSCSI target aus Sicht von ZFS eine einzelne Datei oder Dateisystem ist (das nachher mit ntfs formatiert wird) kann Windows vorherige Version aus ZFS Snaps nicht gehen. ZFS weiss ja nichts von den Dateien auf dem Target. Windows Shadow Copies macht dann die vorherige Version (nicht so elegant wie ZFS und auch nicht geschützt gegen Löschen mit Adminrechten z.B. via Ramsomware).

Unter der Annahme ESXi wird genutzt und es kommt eine Windows VM zum Einsatz, gibt es dann überhaupt sinnvolle Szenarien bei denen ISCSi statt NFS genutzt werden sollte?
Leider blicke ich da immer noch nicht richtig durch. Zuletzt dachte ich ja das mit den Snapshots als Vorgängerversion geht mit ISCSi aber da lag ich falsch.
Das scheint ja wirklich NUR mit SMB zu gehen, liege ich da jetzt wenigstens richtig?

 

[gea]

Für normales VM Storage macht in der Tat NFS am meisten Sinn.
iSCSI nimmt man nur wenn man Multipathing braucht oder eben das Client-Dateisystem.

"Vorherige Version" ist ein Windows Feature auf ntfs Datenträgern mit aktivierten Shadow Copies.
Ein Nicht-Windows Filer mit Solarish unterstützt das out of the Box für SMB Freigaben.

Ausserhalb von SMB kann es das für Windows nicht geben.
(und dateibasiert für iSCSI prinzipiell nicht, auch nicht mit ZFS Snaps)

 

[snipor]

Irgendwie versuche ich da scheinbar krampfhaft etwas umzusetzen was nicht möglich ist.
Weil mir geht es die ganze Zeit nicht um VM Storage, sondern um Nutzdaten auf welche dann die Clients zugreifen sollen.

 

[besterino]

Mach das doch einfach mit SMB und gut ist? Eine etwaige Rechteverwaltung kannst Du auch relativ easy mit napp-it abbilden oder zur Not eben mit 'ner AD.

 

[snipor]

Dann muss ich auf dem Windows Server wohl die Laufwerke auch per SMB anbinden. Dann ist die Frage ob Exchange und die Essential Dienste (wegen dem Remotewebaccess) auf ein solches Netzwerklaufwerk zugreifen können.
Ich meine es geht nur mit Laufwerken die auch in der Datenträgerverwaltung auftauchen.

 

[Trambahner]

gea, würdest Du bei Oracle-Datenbanken für die Logfiles und Tablespaces mit übersichtlicher Größe (<100GB) eher ISCSI-Vols einsetzen oder reguläre Vmdk's auf NFS nutzen?

Vorausgesetzt sei AIO-Setup ESXI mit BSD-Storagevm für ZFS und Oracle 12c (kann man ja per OTN-Lizenz für nichtkommerzielle und Lernzwecke nutzen) würde auf einer Windows-VM laufen.
(Ich weiß, das ist eigentlich ideales Terrain für native Solaris. Aber ich möchts halt auf meinem Mehrzweck-AIO fahren und auf Win ist Oracle sehr einfach installiert).

Bis dato hab ich für Versuche/Learning (nicht Prod-Einsatz!) immer nur NFS-Shares genutzt für so eine VM genutzt, nie ISCSI. Ich nehm mal an, für so kleine nichtproduktive Sachen ist das ok? Btw, ich liebe LZ4 dafür geradezu.

 

[gea]

Dann muss ich auf dem Windows Server wohl die Laufwerke auch per SMB anbinden. Dann ist die Frage ob Exchange und die Essential Dienste (wegen dem Remotewebaccess) auf ein solches Netzwerklaufwerk zugreifen können.
Ich meine es geht nur mit Laufwerken die auch in der Datenträgerverwaltung auftauchen.

Wenn man ein lokales Windows Dateisystem braucht, ist iSCSI mit ZFS ideal. Ich mach das mit meinem Windows Mailserver auch so. Dazu Shadow Copies für Windows "vorherige Version" und ZFS Snaps für den Disasterfall. Mit ZFS unter ntfs gibts sogar CopyOnWrite, sicheres sync write und Prüfsummen dazu.

- - - Updated - - -

gea, würdest Du bei Oracle-Datenbanken für die Logfiles und Tablespaces mit übersichtlicher Größe (<100GB) eher ISCSI-Vols einsetzen oder reguläre Vmdk's auf NFS nutzen?

Vorausgesetzt sei AIO-Setup ESXI mit BSD-Storagevm für ZFS und Oracle 12c (kann man ja per OTN-Lizenz für nichtkommerzielle und Lernzwecke nutzen) würde auf einer Windows-VM laufen.
(Ich weiß, das ist eigentlich ideales Terrain für native Solaris. Aber ich möchts halt auf meinem Mehrzweck-AIO fahren und auf Win ist Oracle sehr einfach installiert).

Bis dato hab ich für Versuche/Learning (nicht Prod-Einsatz!) immer nur NFS-Shares genutzt für so eine VM genutzt, nie ISCSI. Ich nehm mal an, für so kleine nichtproduktive Sachen ist das ok? Btw, ich liebe LZ4 dafür geradezu.

Es gibt von Oracle Tuninganleitungen für die Datenbanken und ZFS.
Ein Aspekt wäre neben LZ4 auch recordsize (ZFS/NFS) bzw blocksize (iSCSI).
Bei ESXi ist NFS und iSCSI ähnlich schnell bei gleichen sync-Einstellungen.
Wie das mit Oracle Datenbanken aussieht, kann ich mangels Erfahrung nicht sagen.

https://docs.oracle.com/cd/E36784_01/html/E36845/chapterzfs-db2.html

 

[snipor]

Wenn man ein lokales Windows Dateisystem braucht, ist iSCSI mit ZFS ideal. Ich mach das mit meinem Windows Mailserver auch so. Dazu Shadow Copies für Windows "vorherige Version" und ZFS Snaps für den Disasterfall. Mit ZFS unter ntfs gibts sogar CopyOnWrite, sicheres sync write und Prüfsummen dazu.

CopyOnWrite, sicheres sync write und Prüfsummen würde es bei NFS dann quasi nicht geben?
Gibt es bei diesem Szenario eine Möglichkeit auf den Inhalt der Snaps zuzugreifen, oder besser gesagt wo finde ich die Funktion in napp-it um auf einen solchen Snap zuzugreifen?

 

[besterino]

Doch, da gibt es das auch und noch komfortabler.

 

[snipor]

Beziehst du dich mit deiner Antwort auf meine Frage zu NFS?

 

[besterino]

Ja. Copyonwrite geht bei ZFS nicht ohne. sync Write ist Einstellungssache. Snaps geht auch immer, die Frage ist eben da nur, ob die auch für Windows Vorherige Version „visibel“ sind.

So zumindest in der Solarish Welt, also auf dem / aus Sicht des Hosts. Dem ist Wurscht, was ein etwaiges Windows OS „dahinter“ dann noch rummurkst.

 

[snipor]

Mir ist leider immer noch nicht ganz klar wann dann nun ISCSi für die beschriebenen Szenarien Sinn macht.
Gea schrieb dazu:

Für normales VM Storage macht in der Tat NFS am meisten Sinn.
iSCSI nimmt man nur wenn man Multipathing braucht oder eben das Client-Dateisystem.

Das mit dem Multipathing verstehe ich soweit aber was ist mit Client-Dateisystem gemeint. Bzw. wo ist hier genau der Vorteil zu NFS.

Er nutzt es ja wie er schreibt für Mail Server, warum ist für diesen Fall ISCSi zu bevorzugen im Vergleich zu NFS?

 

[besterino]

Befasse Dich vielleicht noch etwas mit Basics zu Dateisystemen (=wie wird was auf der Platte gespeichert, z.B. ZFS, BTFRS, NTFS, ext4 usw.) und Übertragungsprotokollen (SMB/CIFS, NFS). iSCSI ist dann noch ein gewisser Sonderfall, weil es - im Gegensatz zu den bisher genannten - genau den Grundsatz durchbricht, dass der (File)Server (allein) das Dateisystem managed und eben als „Freigabe“ Blockbasiert arbeitet, d.h. - vereinfacht ausgedrückt - der Client behandelt die Freigabe nicht wie einen Nerzwerk“Ordner“ sondern eher wie eine lokale Festplatte. Dass das aber keine lokale Festplatte ist (und was der iSCSI Host dahinter alles sonst noch so macht), bekommt der Client eben gar nicht mit.

Kurz: NFS/SMB für Client = „ich kümmere mich nur über die Übertragung und ggf Rechte“ (NICHT auch Filesystem). iSCSI für Client = „ich mach‘ alles selbst“ (inkl. Filesystem).

Nun haben bestimmte Anwendungen unterschiedliche Anforderungen. Windows Server zum Beispiel verlangt für den Einsatz von Netzwerkspeichern als Ersatz in Form von „nicht lokalen Festplatten“ bisweilen einfach SMB3 (z.B. VM-Speicherplatz unter Hyper-V wenn ich mich richtig erinnere) oder eben iSCSI. SMB2 geht nicht. NFS ist in der Wkndows Welt - naja - auch eher schwieriger. Und ein Exchange Server ist von seinen Anforderungen her auch nicht ganz ohne. Da gibt man eben den Speicherplatz per iSCSI her und Windows ist happy. Dazu freut man sich dann über die von gea genannten zusätzlichen Gimmicks von ZFS, die es bei Solaris eben für umme obendrauf gibt und so per Software kommt, was sonst EMC & Co. in Ihren Hardware-Appliances liefern.

 

[snipor]

Danke für die Ausführungen.
Aber speziell bei den hier genannten Fällen, also ESXi als Host und Filer und Windows Server als VM bekommt doch der Windows Server gar nicht mit wenn NFS benutzt wird. Das wird ja eine Ebene darüber im ESXi Host gemacht.
Der Windows Server behandelt die Festplatte die er sieht ja dann als ganz normal.
Falls das von mir bisher geschriebene soweit korrekt ist, dann verstehe ich den Vorteil von iSCSI gegenüber NFS für dieses Szenario nicht.
Ich hoffe man kann verstehen an welcher Stelle mein Verständnisproblem liegt.

 

[Luckysh0t]

Also mal einfach geschrieben.

Was ist der Vorteil/Unterschied von einer vmdk HDD(nfs)in Windows gegenüber einer Einbindung eines iscsi Volumes als Datastorage, in deinem Szenario.

Ist das so richtig Snipor ?

 

[snipor]

Genau so meine ich das

 

[besterino]

Zur Performance sagt gea: „Performancemäßig ist NFS mit gleichen Einstellungen wie sync=on und iSCSI mit writeback=off ähnlich schnell.“

NFS plus VMDK ist m.E. einfacher zu handhaben als iSCSI. VMs können von VMDKs ohne Weiteres booten. Man kann den Speicherplatz m.E. einfacher managen bzw. effizienter nutzen (VMDKs anlegen/vergrößern/umhängen usw. geht für den Laien leichter als iSCSI-Shares), da das alles über den ESXI-Host funktioniert und man nicht jeweils im iSCSI-Target und Client-Initiator rumfrickeln muss. VMDK einhängen, fertig. Theoretisch kann auch der Filer den Platz dann effizienter nutzen: per iSCSI zugewiesener Platz ist für den Filer komplett weg - man muss also von Anfang an richtig provisionieren und das gehört dann exklusiv dem einen Client. Bei den (flexiblen) VMDKs wächst der Platzbedarf eben nur bei realem Bedarf der VM.

 

[gea]

NFS (und SMB) sind Datei-Sharing Verfahren mit denen ein Server seinen Speicher über das Netzwerk für mehrere Benutzer gleichzeitig zur Verfügung stellen kann. Welches Dateisystem dabei der Server nutzt (ntfs, ext4, HFS oder ZFS) ist dabei unerheblich. Aus Sicht eines beliebigen SMB/NFS Clients erscheint so ein Share wie ein normaler Dateiordner. Die Möglichkeiten, Einschränkungen eines Share z.B. im Vergleich zu einem Share das ein Windows Server selbst bereitstellt sind abhängig von der SMB/NFS Serversoftware (z.B. Windows SMB Server, SAMBA als SMB Server oder der Solaris eigene ZFS/Kernel-SMB Server). Macht man ZFS Snaps so kann man aus dem Snap einzelne Dateien wiederherstellen (Windows vorherige Version oder aus Ordner dateisystem/.zfs/snapshots)

iSCSI nutzt man dann, wenn man eigentlich weitere lokale Festplatten haben möchte oder wegen einer besonderen Applikation muss die mit dem lokalen Windows Dateisystem z.B. ntfs formatiert werden. Ein iSCSI Server stellet dazu echte Festplatten oder Teile des Serverstorages wie eine Festplatte bereit. Nachdem die in Windows im iSCSI Initiator angemeldet wurde, ist sie aus Windows Sicht eine lokale Festplatte.

Der Vorteil von iSCSI mit ZFS (man könnte ja auch einfach eine weitere lokale Festplatte kaufen) sind Extras wie die einfache Administration wie die Möglichkeit diese Festplatte woanders anzumelden, man kann die Größe flexibel ändern, zentral sichern (per ZFS Replikation auch mit offenen Dateien), hat Versionierung, Bitrot- und Prüfsummenschutz sowie bessere Sicherheit beim Absturz (CopyOnWrite, schnelles sicheres Sync-Write).

Wenn man beides aus ESXi Sicht betrachtet, so bietet ein NFS Share einen Ablageordner für virtuellen Platten von ESXi (vmdk) und sonstige Konfigurationsdateien. Per VM wird dabei ein einfacher Ordner mit den notwendigen Dateien darin angelegt. Das bietet eine extrem einfache Art VMs zu sichern, zu klonen oder wiederherzustellen (ins Inventory aufnehmen: per Maus-Rechtsklick auf die .vmx Datei). NFS unterstützt Thin provision und man kann direkt auf diese Dateien Zugreifen, auch von anderen Clients oder per SMB und hat damit Windows "vorherige Version" für ESXi VMs.

Ein iSCSI Target wird in ESXi wie eine lokale Festplatte mit vmfs formatiert und genutzt. Zugriff hat exklusiv ESXi (keine allgemeines Multiuser-Sharing). Lediglich ESXi hat Zugriff auf die Dateien. Snapshots auf VM/Dateiebene kann man nur als ESXi Snapshot wiederherstellen. ZFS Snapshots decken nur die Platte als Ganzes ab und man kann auch nur die ganze Platte aus einem ZFS Snap wiederherstellen (rollback, clone, replikation).

Thin Provisioning geht mit ESXi auf NFS und lokalem vmfs storage. iSCSI kann seler auch unabhängig von einem Client die Targets thin provisioned bereitstellen (LUNs haben wzar wie eine Fetsplatte eine Größe nutzen aber zunächst nur den belegten Platz)

 

[besterino]

Wenn es um die direkte Einbindung geht (ohne VMDK dazwischen): diverse Anwendungen lassen sich schlicht nicht auf Netzwerkfreigaben (SMB) installieren/ausführen, auf iSCSI-Shares hingegen schon. Manche Steam-Spiele zicken zum Beispiel, wenn sie auf Laufwerk D: installiert werden sollen und dieses "Laufwerk D:" eine über SMB(2.x) gemappte Netzwerkfreigabe ist. Ist Laufwerk D: aber über iSCSI eingebunden, geht es (genauso wie wenn es eine lokale Festplatte wäre oder eben eine VMDK in einer ESXi-VM).

Vielleicht einmal eine Frage zwischendrin: geht es Dir primär darum, Plattenplatz in einer ESXi-VM bereit zu stellen, oder soll der Platz in einem (zweiten) physischen Windows-Rechner verfügbar gemacht werden? In letzterem Fall scheidet die Möglichkeit einer VMDK auf einem NFS-Share eigentlich aus und Du hast faktisch nur die Wahl zwischen SMB und iSCSI.