NFS 4.1 Probleme mit VM erstellung

[UrsDerBär]

Tach zusammen,

Kann mir jemand bestätigen oder verneinen, dass es auch mit nicht-Windows-NFS-Server bei ESXi 7 (aktuellster Build) Probleme mit dem erstellen von VM's auf NFS 4.1 Stores geben kann? Oder ob man zwingend eine Authentifizierung oder Kerberos einrichten muss?

Mir motzt ESXi bei einer kopierten VM beim einschalten, dass er VMX nicht bearbeiten kann oder so ähnlich und beim erstellen einer neuen VM motzt er schon vorher. Eine virtuelle Disc die auf einem NFS 4.1 Storage liegt, kann ich jedoch problemlos in eine VM einbinden welche auf Local Storage oder einem NFS3 Volume liegt.

Interessant wäre 4.1, ist ca. um den Faktor 1.3 schneller

Das zweite Problem: Ich kann keine genullten Datenträger erstellen wenn das Volume auf NFS liegt. Die Optionen der beiden Varianten sind ausgegraut. Eine vorgängig so erstellen und in den Ordner kopieren ist dagegen wieder möglich und wird auch so angezeigt.

Bedienung aktuell über die WebGui ohne vCenter.

Grüsse und Danke für Inputs

[rprengel]

Tach zusammen,

Kann mir jemand bestätigen oder verneinen, dass es auch mit nicht-Windows-NFS-Server bei ESXi 7 (aktuellster Build) Probleme mit dem erstellen von VM's auf NFS 4.1 Stores geben kann? Oder ob man zwingend eine Authentifizierung oder Kerberos einrichten muss?

Mir motzt ESXi bei einer kopierten VM beim einschalten, dass er VMX nicht bearbeiten kann oder so ähnlich und beim erstellen einer neuen VM motzt er schon vorher. Eine virtuelle Disc die auf einem NFS 4.1 Storage liegt, kann ich jedoch problemlos in eine VM einbinden welche auf Local Storage oder einem NFS3 Volume liegt.

Interessant wäre 4.1, ist ca. um den Faktor 1.3 schneller

Das zweite Problem: Ich kann keine genullten Datenträger erstellen wenn das Volume auf NFS liegt. Die Optionen der beiden Varianten sind ausgegraut. Eine vorgängig so erstellen und in den Ordner kopieren ist dagegen wieder möglich und wird auch so angezeigt.

Bedienung aktuell über die WebGui ohne vCenter.

Grüsse und Danke für Inputs

Hallo,
schau dir mal die Rechte der Dareien auf dem NFS Server per Konsole an.
Gruß

[UrsDerBär]

Ziemlich kurios, habe jetzt nochmals eine VM da hin kopiert. Ganz "doof" via dem Datastore-Browser. Diese VM lässt sich seltsamerweise einschalten. Zumindest solange sie vorher noch nicht gestartet war.

Wenn ich nun aber die Einstellungen der VM ändern möchte erscheint wiederum:
Fehler beim Neukonfigurieren der virtuellen Maschine Test10. VMX-Datei kann nicht geschrieben werden: /vmfs/.../Test10/Test10.vmx

Die Berechtigungen sind auf
dem Ordner: rwxr-xr-x
den Files (vmdk, vmsd,vmx) jeweils: rw--------

Verglichen mit einer eingeschalteten VM in einem NFS3 Share gibt es aber doch unterschiede:
vmx: rwxr-xr-x (NFS3)
vmsd: rw-r---r-- (NFS3)

Wenn ich die Berechtigungen manuell setze, dann erscheint beim ändern der Konfig:
Fehler beim Neukonfigurieren der virtuellen Maschine Test10. Es wird bereits eine andere Aufgabe ausgeführt. -

Irgendwie scheint wirklich etwas mit den Standard-Berechtigungen die ESXi auf den 4.1 Volumes macht im Argen zu liegen.

Auch die Frage ob die VM verschoben wurde kommt bei jedem einschalten. Eine ISO kann ich auch nich einhängen.

EDIT: Also es schent wirklich daran zu liegen, dass VMX Files mit falschen Berechtigung erstellt werden. Auch die Kopie die ESXi jeweils anlegt wird nicht erstellt. Änderungen an der VMX werden somit nicht übernommen. Im laufenden Betrieb oder wenn ich sie von Hand ändere funktioniert dagegen. Seltsame Sache.

[rprengel]

Ziemlich kurios, habe jetzt nochmals eine VM da hin kopiert. Ganz "doof" via dem Datastore-Browser. Diese VM lässt sich seltsamerweise einschalten. Zumindest solange sie vorher noch nicht gestartet war.

Wenn ich nun aber die Einstellungen der VM ändern möchte erscheint wiederum:
Fehler beim Neukonfigurieren der virtuellen Maschine Test10. VMX-Datei kann nicht geschrieben werden: /vmfs/.../Test10/Test10.vmx

Die Berechtigungen sind auf
dem Ordner: rwxr-xr-x
den Files (vmdk, vmsd,vmx) jeweils: rw--------

Verglichen mit einer eingeschalteten VM in einem NFS3 Share gibt es aber doch unterschiede:
vmx: rwxr-xr-x (NFS3) unter 4
vmsd: rw-r---r-- (NFS3)

Wenn ich die Berechtigungen manuell setze, dann erscheint beim ändern der Konfig:
Fehler beim Neukonfigurieren der virtuellen Maschine Test10. Es wird bereits eine andere Aufgabe ausgeführt. -

Irgendwie scheint wirklich etwas mit den Standard-Berechtigungen die ESXi auf den 4.1 Volumes macht im Argen zu liegen.

Auch die Frage ob die VM verschoben wurde kommt bei jedem einschalten. Eine ISO kann ich auch nich einhängen.

bitte mal komplett nur auf der Konsole arbeiten
der Browser kann Probleme machen
per Iphone von unterwegs

[UrsDerBär]

Habe eine Ergänzung im obigen Post gemacht.

Puuuh in der Konsole bin ich so gar nicht fit. Keine Ahnung wie ich da VM's erstelle, einschalte usw.
So wie es aussieht sind alle neuen Files die kreiert werden mtit rw und das scheint nicht zu auszureichen für die VMX.

[rprengel]

Habe eine Ergänzung im obigen Post gemacht.

Puuuh in der Konsole bin ich so gar nicht fit. Keine Ahnung wie ich da VM's erstelle, einschalte usw.
So wie es aussieht sind alle neuen Files die kreiert werden mtit rw und das scheint nicht zu auszureichen für die VMX.

Hallo,
es geht nur ums verschieben / kopieren der Vm.
Eine kleine Test Vm lokal normal anlegen uns testen. Dann aus schalten und auf der Konsole verschieben.

[UrsDerBär]

Da kein echter Plan von der Konsole habe ich sie mit WinSCP kopiert. Berechtigungen scheinen dann identisch mit der Quelle zu sein. Die Problematik bleibt aber die gleiche. Einschalten geht, VMX ändern nicht. Im laufenden Betrieb kann ich die Einstellungen der VM ändern, diesen werden nach dem ausschalten aber nicht gespeichert. Sprich das verhalten ist identisch wie wenn ich die Berechtigungen manuell gesetzt habe (ebenfalls WinSCP).

ESXi scheint wirklich auf NFS 4.1 neue Dateien mit falschen Rechten anzulegen.

[irix]

[UrsDerBär]

Nachtrag: Im Log der VM erscheint
05.857Z| vmx| | I005: FileIO_AtomicUpdateEx: rename of '/vmfs/volumes/f89c237c-81507db0-0000-000000000000/Test10/Test10.vmx~' to '/vmfs/volumes/f89c237c-81507db0-0000-000000000000/Test10/Test10.vmx' failed 16.

2021-08-27T10:11:05.857Z| vmx| | I005: [msg.dictionary.writefile.atomicUpdate] An error occurred while writing dictionary file "/vmfs/volumes/f89c237c-81507db0-0000-000000000000/Test10/Test10.vmx": Device or resource busy.

2021-08-27T10:11:05.863Z| vmx| | I005: FileIO_AtomicUpdateEx: rename of '/vmfs/volumes/f89c237c-81507db0-0000-000000000000/Test10/Test10.vmx~' to '/vmfs/volumes/f89c237c-81507db0-0000-000000000000/Test10/Test10.vmx' failed 16.

2021-08-27T10:11:05.863Z| vmx| | I005: [msg.dictionary.writefile.atomicUpdate] An error occurred while writing dictionary file "/vmfs/volumes/f89c237c-81507db0-0000-000000000000/Test10/Test10.vmx": Device or resource busy.

[MarroniJohny]

Hi

Das mit dem Rechteproblem mit NFS (v3) hatte ich anfangs auch. Ich habe allerdings per SMB kopiert. Ich nutze ein ZFS Storage auf napp-it. Ich kopiere die VMs nun mit Midgnight Commander direkt per SSH, das ist super. Dann werden auch die Rechte übernommen. Mit WinSCP oder per SMB vermeide ich wenn es geht, ansonsten muss man halt die Rechte setzen. Bei mir war auch die besagte VMX Datei das Problem.

viewtopic.php?f=51&t=33179&p=184042#p184002

viewtopic.php?f=57&t=34045

[UrsDerBär]

Scheint wohl ein generelles Problem zu sein wenn man dem hier glauben schenkt: https://www.starwindsoftware.com/blog/c ... -nfs-share

ESXi scheint wirklich die VMX mit falschen Berechtigungen erstellen zu wollen und hat nachher selber kein Zugriff mehr. Habe auch mal versucht den Datastore auf 777 zu ändern, das wird aber nicht gefressen. 777 auf den VM-Ordner hilft ebenfalls nicht. Auf die VMX alleine auch nicht, bewirkt aber, dass die VM wenigstens gestartet werden kann.

Werde mal noch versuchen die Unix-Mapping auf einem höheren Ordner-Level unter Windows zu setzen und nacher tiefer wieder freizugeben. Eventuell wird dann ja weniger restriktiv vererbt. Sowie noch ein paar andere Ideen zu sammeln. Aber fürs erste habe ich es aufgegben.

[UrsDerBär]

Kleine Ergänzung: 4.1 ist auch nicht wirklich reconnect-fest. Sprich verliert der Host die Verbindung zum Store, macht man einen Reboot des Servers, dann wird die Verbindung nicht automatisch wieder erstellt und muss gelöscht und muss wieder gemounted werden. Wenigstens geschieht das mit der gleichen Volume-ID sprich Festplatten-Verbindungen bleiben erhalten. Also ähnlich wie früher bei NFS3 welches dieses Verhalten nach gewisser Disconnect-Zeit ebenfalls hatte.

Das Problem mit dem OS konnte ich lösen indem ich die VM zwar in einem Local-Store oder NFS3 erstellt habe, danach jedoch die HDD's auf NFS4 gelegt habe. Ebenso das Träge/Starkt Null gesetzt. Wenn die VM's selbst z.Bsp. auf LocalStorage mit Stark null gesetzt erstellt wird, kann man es auch bei den normalen Discs auswählen, selbst wenn sie auf NFS liegen. Sonst sind die Optionen ausgegraut. Seltsames Verhalten der GUI

[Dayworker]

Ebenso das Träge/Starkt Null gesetzt.

Wenn ich sowas lese, werde ich immer wieder an die sinnentstellende 1:1-Übersetzung bei VMware erinnert. Macht euch bitte das Leben leichter und schaltet ggf auf die englische Oberfläche um. Dann findet man erfahrungsgemäß deutlich schneller Hilfe.

[UrsDerBär]

hehe hat was