Hi,
I have working vms with their disks on a NFS share (happened by mistake, usually is on iscsi/lvm), the nfs is a linux based system (qnap), i have console root access.
I wish to test a new pve server on the same nfs host, but the new pve server has no permission on any existing share, atm.
I could change that on the nfs server web gui and of course on the console adding new pve server IP permission for existing share or, better, creating a new share and letting the new pve server access test share, BUT, iirc, that would probably restart the server, causing a temporary problem to working vms disks, and that would cause a "Stale NFS file handle" error, crashing the vms. I do not want this, for sure.
probably the nfs host server would do a
/sbin/service nfs restarti've seen here http://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-nfs-start.html
that <<To reload the NFS server configuration file without restarting the service, as root, type: /sbin/service nfs reload >>
or probably, as on http://nfs.sourceforge.net/#section_c:
<< C2. Can I modify export permissions without needing to remount clients in order to have them take effect?
A. Yes. The safest thing to do is edit /etc/exports and run "exportfs -r".
Note that when a mount request arrives, mountd check .../etab to see if that host is allowed access. If it is, an entry is placed in .../rmtab and the filesystem is exported thus creating an entry in /proc/fs/nfs/exports.
When you run "exportfs -io <options> host:/dir then the entry in ../etab is changed, or a new one is added. If it is a subnet/wildcard/netgroup entry, then every line in ../rmtab is checked to see if it matches. When a match is found, a host-specific entry is given to (or changed in) the kernel. When you run "exportfs -a" it makes sure that all entries in /etc/exports are properly reflected in ../etab. Any extra entries in etab are left alone. Once the correct content of etab has been determined, rmtab is examine to create a list of specific-host entries for any new entries in etab. This host-specific entries are given to the kernel.
When you run "exportfs -r" it ignores the prior contents of ../etab and initializes etab to the contents of /etc/exportfs. Then it inspects rmtab and make an changes to /proc/fs/nfs/export that are necessary.
>>
In your experience, will this different way let me edit shares permissions or adding new shares without causing troubles to running vm disks?
Thanks,
Marco
I have working vms with their disks on a NFS share (happened by mistake, usually is on iscsi/lvm), the nfs is a linux based system (qnap), i have console root access.
I wish to test a new pve server on the same nfs host, but the new pve server has no permission on any existing share, atm.
I could change that on the nfs server web gui and of course on the console adding new pve server IP permission for existing share or, better, creating a new share and letting the new pve server access test share, BUT, iirc, that would probably restart the server, causing a temporary problem to working vms disks, and that would cause a "Stale NFS file handle" error, crashing the vms. I do not want this, for sure.
probably the nfs host server would do a
/sbin/service nfs restarti've seen here http://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-nfs-start.html
that <<To reload the NFS server configuration file without restarting the service, as root, type: /sbin/service nfs reload >>
or probably, as on http://nfs.sourceforge.net/#section_c:
<< C2. Can I modify export permissions without needing to remount clients in order to have them take effect?
A. Yes. The safest thing to do is edit /etc/exports and run "exportfs -r".
Note that when a mount request arrives, mountd check .../etab to see if that host is allowed access. If it is, an entry is placed in .../rmtab and the filesystem is exported thus creating an entry in /proc/fs/nfs/exports.
When you run "exportfs -io <options> host:/dir then the entry in ../etab is changed, or a new one is added. If it is a subnet/wildcard/netgroup entry, then every line in ../rmtab is checked to see if it matches. When a match is found, a host-specific entry is given to (or changed in) the kernel. When you run "exportfs -a" it makes sure that all entries in /etc/exports are properly reflected in ../etab. Any extra entries in etab are left alone. Once the correct content of etab has been determined, rmtab is examine to create a list of specific-host entries for any new entries in etab. This host-specific entries are given to the kernel.
When you run "exportfs -r" it ignores the prior contents of ../etab and initializes etab to the contents of /etc/exportfs. Then it inspects rmtab and make an changes to /proc/fs/nfs/export that are necessary.
>>
In your experience, will this different way let me edit shares permissions or adding new shares without causing troubles to running vm disks?
Thanks,
Marco
Last edited: