Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1823207

Summary:

import NFS storage domain fails when adding NFS mount parameters

Product:

[oVirt] vdsm

Reporter:

Ahmad Khiet <akhiet>

Component:

Core

Assignee:

Ahmad Khiet <akhiet>

Status:

CLOSED NOTABUG

QA Contact:

Ilan Zuckerman <izuckerm>

Severity:

high

Docs Contact:

Priority:

unspecified

Version:

4.40.13

CC:

aefrat, bugs, izuckerm, mkalinin, nsoffer, tnisan

Target Milestone:

ovirt-4.4.1

Target Release:

---

Hardware:

Unspecified

OS:

Unspecified

Whiteboard:

Fixed In Version:

Doc Type:

If docs needed, set a value

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2020-07-01 13:23:59 UTC

Type:

Bug

Regression:

---

Mount Type:

---

Documentation:

---

CRM:

Verified Versions:

Category:

---

oVirt Team:

Storage

RHEL 7.3 requirements from Atomic Host:

Cloudforms Team:

---

Target Upstream Version:

Embargoed:

Attachments:

Description	Flags
Error_screenshot	none
timeo=100 option failure	none
engine and vdsm logs	none

Description Ahmad Khiet 2020-04-12 17:51:12 UTC

Description of problem:
sending NFS mountOptions is not processed in vdsm as expected and the importing NFS storage domain will fails.
for example: sending 'ro' mount option to 'ro' NFS mount will result an error in the UI and vdsm.
the UI error is what vdsm returns.


the UI/engine side of the bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1810893


How reproducible:
Always


Steps to Reproduce:
1. 'Storage' -> 'Storage Domains' 
2. 'Import Domain'
3. under 'Custom domain parameters' add to 'Additional mount Options' the needed NFS parameters
   for example, add 'ro' if the imported domain is read-only

Actual results:
Importing the NFS storage domain will fail.

a message in a popup window will show:

Error while executing action Add Storage Connection: Permission settings on the specified path do not allow access to the storage.
Verify permission settings on the specified storage path.

Expected results:
Importing the storage domain with the NFS mount parameters will success

Additional info:

Comment 1 Ahmad Khiet 2020-04-12 17:51:58 UTC

Created attachment 1678292 [details]
Error_screenshot

Comment 4 Ahmad Khiet 2020-04-12 18:28:14 UTC


debugging notes:

The raised error from enigne/ui side is StorageServerAccessPermissionError(469)
see:
https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/common/src/main/java/org/ovirt/engine/core/common/errors/EngineError.java#L246


from vdsm side:
https://github.com/oVirt/vdsm/blob/485b1b32aa3c9b80d9e13066b02a3ea8e565f93a/lib/vdsm/storage/exception.py#L1160

the error will raise in vdsm under storageServer#connect()

https://github.com/oVirt/vdsm/blob/cc1aaa2a0dfd5e3966182e7337ad9a050beaea19/lib/vdsm/storage/storageServer.py#L162


and in fileSD
I think this is where the error is raised after validating the access permissions
https://github.com/oVirt/vdsm/blob/3628b3bab2367646221ada5aa27630bb909b8727/lib/vdsm/storage/fileSD.py#L78


https://github.com/oVirt/vdsm/blob/3628b3bab2367646221ada5aa27630bb909b8727/lib/vdsm/storage/fileSD.py#L494

Comment 5 Tal Nisan 2020-04-13 08:54:23 UTC

*** Bug 1823208 has been marked as a duplicate of this bug. ***

Comment 6 Marina Kalinin 2020-04-16 19:22:59 UTC

Tal - how a storage domain can be read only?
You cannot mount it in a read only way. How would we update a metadata?
I do not think this is a legit use case.
What are your thoughts on this?

Comment 7 Tal Nisan 2020-04-23 09:13:07 UTC

(In reply to Marina Kalinin from comment #6)
> Tal - how a storage domain can be read only?
> You cannot mount it in a read only way. How would we update a metadata?
> I do not think this is a legit use case.
> What are your thoughts on this?

Read only is never an option, I targeted it for general mount options that are not passing but obviously ro is not a viable option as a part of using the domain is actually writing data to it.
Ahmad, you cannot test with ro, please use another NFS mount option for your verification

Comment 8 Ahmad Khiet 2020-04-23 09:20:21 UTC

I tested with different nfs mount options, and I see it all passes.
the 'ro' mount option will fail, because of the storage domain can't be 'read-only'

Ilan, can you re-check what did fail again in the tests you did before in this bug:
 https://bugzilla.redhat.com/show_bug.cgi?id=1810893

Comment 11 Ilan Zuckerman 2020-04-27 12:21:57 UTC

Ahmed, I am not able to verify this BZ.

After importing the NFS SD with "Additional mount options", i do not see them take affect on the actual mount point on the VDSM host.

Steps to reproduce:
1. Click import SD from storage domains window
2. Choose "NFS", and fill in all other params such as path of existing SD which you wish to import
3. click "custom connection params" to expand it and in "Additional mount options" fill in "suid" (this is one of the possible mount options). Tried also with "intr" option. the result was the same.
4. click OK

Observing the engine log you can see the the new mountOptions is being passed to the VDSM as expected:

2020-04-27 15:05:33,486+03 INFO  [org.ovirt.engine.core.vdsbroker.vdsbroker.DisconnectStorageServerVDSCommand] (default task-73) [19f39bd0-d112-453b-821a-073f99b42364] START, DisconnectStorageServerVDSCommand(HostName = host_mixed_1, StorageServerConnectionManagementVDSParameters:{hostId='c0f29837-32ac-406f-a4b1-c48bc560932c', storagePoolId='00000000-0000-0000-0000-000000000000', storageType='NFS', connectionList='[StorageServerConnections:{id='3601e825-90b0-455a-9821-228246c6b2cd', connection='XXX.redhat.com:/Storage_NFS/storage_local_ge13_nfs_0', iqn='null', vfsType='null', mountOptions='suid', nfsVersion='AUTO', nfsRetrans='null', nfsTimeo='null', iface='null', netIfaceName='null'}]', sendNetworkEventOnFailure='true'}), log id: 35e0765b


Observing the VDSM log, you can also see that this option is being received:

2020-04-27 15:04:41,135+0300 INFO  (jsonrpc/0) [vdsm.api] START connectStorageServer(domType=1, spUUID='00000000-0000-0000-0000-000000000000', conList=[{'password': '********', 'protocol_version': 'auto', 'port': '', 'mnt_options': 'suid', 'iqn': '', 'connection': 'XXX.redhat.com:/Storage_NFS/storage_local_ge13_nfs_0', 'ipv6_enabled': 'false', 'id': '3601e825-90b0-455a-9821-228246c6b2cd', 'user': '', 'tpgt': '1'}], options=None) from=::ffff:10.35.161.131,52790, flow_id=7ee17965, task_id=a6b6fe22-b5e0-4259-bf8c-4daab4e14c89 (api:48)


BUT observing at the new mount point we see that it DOES NOT have the additional mount option "suid":

[root@storage-ge5-vdsm2 ~]# mount | grep ge13
XXX.redhat.com:/Storage_NFS/storage_local_ge13_nfs_0 on /rhev/data-center/mnt/XXX.redhat.com:_Storage__NFS_storage__local__ge13__nfs__0 type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,soft,nosharecache,proto=tcp6,timeo=600,retrans=6,sec=sys,clientaddr=2620:52:0:2353:21a:4aff:fe16:2544,local_lock=none,addr=2620:52:0:2350:21b:21ff:fe75:35fb)


I would expect the new mount to have (rw,suid etc...)

Comment 12 Ahmad Khiet 2020-04-27 12:35:42 UTC

(In reply to Ilan Zuckerman from comment #11)
> Ahmed, I am not able to verify this BZ.
> 
> After importing the NFS SD with "Additional mount options", i do not see
> them take affect on the actual mount point on the VDSM host.
> 
> Steps to reproduce:
> 1. Click import SD from storage domains window
> 2. Choose "NFS", and fill in all other params such as path of existing SD
> which you wish to import
> 3. click "custom connection params" to expand it and in "Additional mount
> options" fill in "suid" (this is one of the possible mount options). Tried
> also with "intr" option. the result was the same.
> 4. click OK
> 
> Observing the engine log you can see the the new mountOptions is being
> passed to the VDSM as expected:
> 
> 2020-04-27 15:05:33,486+03 INFO 
> [org.ovirt.engine.core.vdsbroker.vdsbroker.
> DisconnectStorageServerVDSCommand] (default task-73)
> [19f39bd0-d112-453b-821a-073f99b42364] START,
> DisconnectStorageServerVDSCommand(HostName = host_mixed_1,
> StorageServerConnectionManagementVDSParameters:{hostId='c0f29837-32ac-406f-
> a4b1-c48bc560932c', storagePoolId='00000000-0000-0000-0000-000000000000',
> storageType='NFS',
> connectionList='[StorageServerConnections:{id='3601e825-90b0-455a-9821-
> 228246c6b2cd',
> connection='XXX.redhat.com:/Storage_NFS/storage_local_ge13_nfs_0',
> iqn='null', vfsType='null', mountOptions='suid', nfsVersion='AUTO',
> nfsRetrans='null', nfsTimeo='null', iface='null', netIfaceName='null'}]',
> sendNetworkEventOnFailure='true'}), log id: 35e0765b
> 
> 
> Observing the VDSM log, you can also see that this option is being received:
> 
> 2020-04-27 15:04:41,135+0300 INFO  (jsonrpc/0) [vdsm.api] START
> connectStorageServer(domType=1,
> spUUID='00000000-0000-0000-0000-000000000000', conList=[{'password':
> '********', 'protocol_version': 'auto', 'port': '', 'mnt_options': 'suid',
> 'iqn': '', 'connection':
> 'XXX.redhat.com:/Storage_NFS/storage_local_ge13_nfs_0', 'ipv6_enabled':
> 'false', 'id': '3601e825-90b0-455a-9821-228246c6b2cd', 'user': '', 'tpgt':
> '1'}], options=None) from=::ffff:10.35.161.131,52790, flow_id=7ee17965,
> task_id=a6b6fe22-b5e0-4259-bf8c-4daab4e14c89 (api:48)
> 
> 
> BUT observing at the new mount point we see that it DOES NOT have the
> additional mount option "suid":
> 
> [root@storage-ge5-vdsm2 ~]# mount | grep ge13
> XXX.redhat.com:/Storage_NFS/storage_local_ge13_nfs_0 on
> /rhev/data-center/mnt/XXX.redhat.com:
> _Storage__NFS_storage__local__ge13__nfs__0 type nfs4
> (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,soft,
> nosharecache,proto=tcp6,timeo=600,retrans=6,sec=sys,clientaddr=2620:52:0:
> 2353:21a:4aff:fe16:2544,local_lock=none,addr=2620:52:0:2350:21b:21ff:fe75:
> 35fb)
> 
lets try and set one of the parameters from this line.
mforexampe lets change time out
timeo=100 and see if it changes

> 
> I would expect the new mount to have (rw,suid etc...)

Comment 13 Ilan Zuckerman 2020-04-27 12:55:52 UTC

Passing "timeo=100" as "Additional mount options" causes vdsm error, and a message box to pop up in the UI with the following message:

"Error while executing action: Cannot add Storage Connection. Custom mount options contain the following duplicate managed options: timeo."

See attached image.

Engine:

2020-04-27 15:49:14,736+03 INFO  [org.ovirt.engine.core.vdsbroker.vdsbroker.DisconnectStorageServerVDSCommand] (default task-69) [18b4001d-3e1a-40a3-8d5f-af386723670f] START, DisconnectStorageServerVDSCommand(HostName = host_mixed_1, StorageServerConnectionManagementVDSParameters:{hostId='c0f29837-32ac-406f-a4b1-c48bc560932c', storagePoolId='00000000-0000-0000-0000-000000000000', storageType='NFS', connectionList='[StorageServerConnections:{id='null', connection='yellow-vdsb.qa.lab.tlv.redhat.com:/Storage_NFS/storage_local_ge13_nfs_0', iqn='null', vfsType='null', mountOptions='timeo=100', nfsVersion='AUTO', nfsRetrans='null', nfsTimeo='null', iface='null', netIfaceName='null'}]', sendNetworkEventOnFailure='true'}), log id: 5ef7e4f2


VDSM:

2020-04-27 15:53:17,880+0300 ERROR (jsonrpc/6) [storage.HSM] Could not disconnect from storageServer (hsm:2528)
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/vdsm/storage/hsm.py", line 2524, in disconnectStorageServer
    conObj.disconnect()
  File "/usr/lib/python3.6/site-packages/vdsm/storage/storageServer.py", line 436, in disconnect
    return self._mountCon.disconnect()
  File "/usr/lib/python3.6/site-packages/vdsm/storage/storageServer.py", line 201, in disconnect
    self._mount.umount(True, True)
  File "/usr/lib/python3.6/site-packages/vdsm/storage/mount.py", line 217, in umount
    umount(self.fs_file, force=force, lazy=lazy, freeloop=freeloop)
  File "/usr/lib/python3.6/site-packages/vdsm/common/supervdsm.py", line 56, in __call__
    return callMethod()
  File "/usr/lib/python3.6/site-packages/vdsm/common/supervdsm.py", line 54, in <lambda>
    **kwargs)
  File "<string>", line 2, in umount
  File "/usr/lib64/python3.6/multiprocessing/managers.py", line 772, in _callmethod
    raise convert_to_error(kind, result)
vdsm.storage.mount.MountError: Command ['/usr/bin/umount', '-f', '-l', '/rhev/data-center/mnt/yellow-vdsb.qa.lab.tlv.redhat.com:_Storage__NFS_storage__local__ge13__nfs__0'] failed with rc=32 out=b'' err=b'umount: /rhev/data-center/mnt/yellow-vdsb.qa.lab.tlv.red
hat.com:_Storage__NFS_storage__local__ge13__nfs__0: no mount point specified.\n'

Comment 14 Ilan Zuckerman 2020-04-27 12:56:33 UTC

Created attachment 1682153 [details]
timeo=100 option failure

Comment 15 Ahmad Khiet 2020-04-28 10:12:37 UTC

I tested with parameter 'hard' and I saw it passed to vdsm.
can you try the following parameters:

hard
nfsvers=3
noacl

Comment 16 Ilan Zuckerman 2020-05-03 13:48:28 UTC

'hard' option ends with vdsm error:

2020-05-03 16:24:05,765+0300 DEBUG (tasks/7) [storage.ResourceManager] Released resource '00_storage.4cf28b78-e264-4230-9eb7-1c1ab1302
f5c' (0 active users) (resourceManager:566)
2020-05-03 16:24:05,765+0300 DEBUG (tasks/7) [storage.ResourceManager] Resource '00_storage.4cf28b78-e264-4230-9eb7-1c1ab1302f5c' is f
ree, finding out if anyone is waiting for it. (resourceManager:572)
2020-05-03 16:24:05,765+0300 DEBUG (tasks/7) [storage.ResourceManager] No one is waiting for resource '00_storage.4cf28b78-e264-4230-9
eb7-1c1ab1302f5c', Clearing records. (resourceManager:580)
2020-05-03 16:24:05,765+0300 ERROR (tasks/7) [root] Job '0f1f6f78-2ae8-4c76-b819-8b1523bb6fb5' failed (jobs:223)
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/vdsm/jobs.py", line 159, in run
    self._run()
  File "/usr/lib/python3.6/site-packages/vdsm/storage/sdm/api/copy_data.py", line 87, in _run
    self._operation.run()
  File "/usr/lib/python3.6/site-packages/vdsm/storage/qemuimg.py", line 349, in run
    for data in self._operation.watch():
  File "/usr/lib/python3.6/site-packages/vdsm/storage/operation.py", line 106, in watch
    self._finalize(b"", err)
  File "/usr/lib/python3.6/site-packages/vdsm/storage/operation.py", line 179, in _finalize
    raise cmdutils.Error(self._cmd, rc, out, err)
vdsm.common.cmdutils.Error: Command ['/usr/bin/qemu-img', 'convert', '-p', '-t', 'none', '-T', 'none', '-n', '-f', 'qcow2', '/rhev/data-center/mnt/blockSD/4cf28b78-e264-4230-9eb7-1c1ab1302f5c/images/d98e0b93-ada4-4a2a-94df-09da6b084c84/f7c55d73-050a-448c-9bc6-b4310d275b63', '-O', 'qcow2', '-o', 'compat=1.1', '/rhev/data-center/mnt/blockSD/4cf28b78-e264-4230-9eb7-1c1ab1302f5c/images/091464fd-90be-4599-8d19-8237660719a8/0d64fdbb-0c6e-421c-b858-475bd8b1be09'] failed with rc=1 out=b'' err=bytearray(b'qemu-img: warning: -o has no effect when skipping image creation\nqemu-img: warning: This will become an error in future QEMU versions.\nqemu-img: error while writing sector 2841728: No space left on device\n')
2020-05-03 16:24:05,766+0300 INFO  (tasks/7) [root] Job '0f1f6f78-2ae8-4c76-b819-8b1523bb6fb5' will be deleted in 3600 seconds (jobs:251)


option 'nfsvers=3' ends with vdsm ERROR:

2020-05-03 16:29:35,924+0300 INFO  (jsonrpc/5) [storage.Mount] unmounting /rhev/data-center/mnt/yellow-vdsb.qa.lab.tlv.redhat.com:_Sto
rage__NFS_storage__local__ge13__nfs__0 (mount:215)
2020-05-03 16:29:35,957+0300 ERROR (jsonrpc/5) [storage.HSM] Could not disconnect from storageServer (hsm:2528)
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/vdsm/storage/hsm.py", line 2524, in disconnectStorageServer
    conObj.disconnect()
  File "/usr/lib/python3.6/site-packages/vdsm/storage/storageServer.py", line 436, in disconnect
    return self._mountCon.disconnect()
  File "/usr/lib/python3.6/site-packages/vdsm/storage/storageServer.py", line 201, in disconnect
    self._mount.umount(True, True)
  File "/usr/lib/python3.6/site-packages/vdsm/storage/mount.py", line 217, in umount
    umount(self.fs_file, force=force, lazy=lazy, freeloop=freeloop)
  File "/usr/lib/python3.6/site-packages/vdsm/common/supervdsm.py", line 56, in __call__
    return callMethod()
  File "/usr/lib/python3.6/site-packages/vdsm/common/supervdsm.py", line 54, in <lambda>
    **kwargs)
  File "<string>", line 2, in umount
  File "/usr/lib64/python3.6/multiprocessing/managers.py", line 772, in _callmethod
    raise convert_to_error(kind, result)
vdsm.storage.mount.MountError: Command ['/usr/bin/umount', '-f', '-l', '/rhev/data-center/mnt/yellow-vdsb.qa.lab.tlv.redhat.com:_Storage__NFS_storage__local__ge13__nfs__0'] failed with rc=32 out=b'' err=b'umount: /rhev/data-center/mnt/yellow-vdsb.qa.lab.tlv.redhat.com:_Storage__NFS_storage__local__ge13__nfs__0: no mount point specified.\n'


noacl ends up with vdsm error, but able to import the SD:

2020-05-03 16:41:51,447+0300 ERROR (jsonrpc/1) [storage.HSM] Could not disconnect from storageServer (hsm:2528)
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/vdsm/storage/hsm.py", line 2524, in disconnectStorageServer
    conObj.disconnect()
  File "/usr/lib/python3.6/site-packages/vdsm/storage/storageServer.py", line 436, in disconnect
    return self._mountCon.disconnect()
  File "/usr/lib/python3.6/site-packages/vdsm/storage/storageServer.py", line 201, in disconnect
    self._mount.umount(True, True)
  File "/usr/lib/python3.6/site-packages/vdsm/storage/mount.py", line 217, in umount
    umount(self.fs_file, force=force, lazy=lazy, freeloop=freeloop)
  File "/usr/lib/python3.6/site-packages/vdsm/common/supervdsm.py", line 56, in __call__
    return callMethod()
  File "/usr/lib/python3.6/site-packages/vdsm/common/supervdsm.py", line 54, in <lambda>
    **kwargs)
  File "<string>", line 2, in umount
  File "/usr/lib64/python3.6/multiprocessing/managers.py", line 772, in _callmethod
    raise convert_to_error(kind, result)
vdsm.storage.mount.MountError: Command ['/usr/bin/umount', '-f', '-l', '/rhev/data-center/mnt/yellow-vdsb.qa.lab.tlv.redhat.com:_Storage__NFS_storage__local__ge13__nfs__0'] failed with rc=32 out=b'' err=b'umount: /rhev/data-center/mnt/yellow-vdsb.qa.lab.tlv.redhat.com:_Storage__NFS_storage__local__ge13__nfs__0: no mount point specified.\n'


At this point, all of the SDs on the env became unresponsive (red), and shortly after, the imported NFS SD was forcefully removed by engine.
Attaching logs.

Comment 17 Ilan Zuckerman 2020-05-03 13:50:27 UTC

Created attachment 1684430 [details]
engine and vdsm logs

Comment 18 Nir Soffer 2020-06-26 20:51:02 UTC

Ilan, please explain the use case for every option that you want to add.

Testing random options that do not make sense (e.g. ro) or have special
UI (like timeo and retrans) is not helpful.

Vdsm is not a generic mount helper and it does not support all options,
and even if some options are supported they may have bad effects and 
are not tested by QE.

If we don't know about any use case that require special options why
are we testing this?

Comment 19 Ilan Zuckerman 2020-06-29 12:13:14 UTC

Re-tested with the following custom mount settings for importing NFS domain on rhv-release-4.4.1-5-001.noarch
I tried just a few custom mount options which i can not think why they shouldn't be supported.
'hard' and 'noacl' 

'hard' - hard or soft — Specifies whether the program using a file via an NFS connection should stop and wait (hard) for the server to come back online, if the host serving the exported file system is unavailable

'noacl' — Turns off all ACL processing. This may be needed when interfacing with older versions of Red Hat Enterprise Linux, Red Hat Linux, or Solaris, since the most recent ACL technology is not compatible with older systems.

I can not verify this BZ assuming both of those options should be supported. Because 'noacl' is not reflected on the actual mount.

---------------------------------

'hard': mount successful.

What is being passed by the engine:

2020-06-29 14:57:39,604+03 INFO  [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSCommand] (EE-ManagedThreadFactory-engine-Thread-30404) [46339cf6] START, ConnectStorageServerVDSCommand(HostName = host_mixed_1, StorageServerConnectionManagementVDSParamete
rs:{hostId='3246c13f-873a-46b1-9a2c-00639e37403f', storagePoolId='00000000-0000-0000-0000-000000000000', storageType='NFS', connectionList='[StorageServerConnections:{id='221290a8-e01e-41a9-9d45-6f029425b585', connection='yellow-vdsb.qa.lab.tlv.redhat.com:/Storage_NFS/sto
rage_local_ge5_nfs_0', iqn='null', vfsType='null', mountOptions='hard', nfsVersion='AUTO', nfsRetrans='null', nfsTimeo='null', iface='null', netIfaceName='null'}]', sendNetworkEventOnFailure='true'}), log id: 258893bf


What is being received by vdsm:

2020-06-29 14:57:39,611+0300 INFO  (jsonrpc/1) [vdsm.api] START connectStorageServer(domType=1, spUUID='00000000-0000-0000-0000-000000000000', conList=[{'password': '********', 'protocol_version': 'auto', 'port': '', 'mnt_options': 'hard', 'iqn': '', 'connection': 'yellow
-vdsb.qa.lab.tlv.redhat.com:/Storage_NFS/storage_local_ge5_nfs_0', 'ipv6_enabled': 'false', 'id': '221290a8-e01e-41a9-9d45-6f029425b585', 'user': '', 'tpgt': '1'}], options=None) from=::ffff:10.35.83.166,39710, flow_id=46339cf6, task_id=02f90010-5780-4d22-85c1-40510dba0f0
2 (api:48)


'mount' command result:
[root@storage-ge13-vdsm1 ~]# mount | grep ge5__nfs__0
yellow-vdsb.qa.lab.tlv.redhat.com:/Storage_NFS/storage_local_ge5_nfs_0 on /rhev/data-center/mnt/yellow-vdsb.qa.lab.tlv.redhat.com:_Storage__NFS_storage__local__ge5__nfs__0 type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,nosharecache,proto=tcp6,timeo=100,retrans=3,sec=sys,clientaddr=2620:52:0:2353:21a:4aff:fe16:26ab,local_lock=none,addr=2620:52:0:23bd:21a:4aff:fe16:9843)


----------------------------------------------------

'noacl' - mount is not reflected on the system.

What is being passed by the engine:

2020-06-29 14:47:10,160+03 INFO  [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSCommand] (EE-ManagedThreadFactory-engine-Thread-30301) [2fe3979c] START, ConnectStorageServerVDSCommand(HostName = host_mixed_1, StorageServerConnectionManagementVDSParameters:{hostId='3246c13f-873a-46b1-9a2c-00639e37403f', storagePoolId='00000000-0000-0000-0000-000000000000', storageType='NFS', connectionList='[StorageServerConnections:{id='b52d2b7e-1699-4612-b9d4-62c6b9c0224b', connection='yellow-vdsb.qa.lab.tlv.redhat.com:/Storage_NFS/storage_local_ge5_nfs_0', iqn='null', vfsType='null', mountOptions='noacl', nfsVersion='AUTO', nfsRetrans='null', nfsTimeo='null', iface='null', netIfaceName='null'}]', sendNetworkEventOnFailure='true'}), log id: 7ad62c06


What is being received by vdsm:

[root@storage-ge13-vdsm1 ~]# mount | grep ge5__nfs__0
yellow-vdsb.qa.lab.tlv.redhat.com:/Storage_NFS/storage_local_ge5_nfs_0 on /rhev/data-center/mnt/yellow-vdsb.qa.lab.tlv.redhat.com:_Storage__NFS_storage__local__ge5__nfs__0 type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,soft,nosharecache,proto=tcp6,timeo=100,retrans=3,sec=sys,clientaddr=2620:52:0:2353:21a:4aff:fe16:26ab,local_lock=none,addr=2620:52:0:23bd:21a:4aff:fe16:9843)


2020-06-29 14:47:10,167+0300 INFO  (jsonrpc/5) [vdsm.api] START connectStorageServer(domType=1, spUUID='00000000-0000-0000-0000-000000000000', conList=[{'password': '********', 'protocol_version': 'auto', 'port': '', 'mnt_options': 'noacl', 'iqn': '', 'connection': 'yellow-vdsb.qa.lab.tlv.redhat.com:/Storage_NFS/storage_local_ge5_nfs_0', 'ipv6_enabled': 'false', 'id': 'b52d2b7e-1699-4612-b9d4-62c6b9c0224b', 'user': '', 'tpgt': '1'}], options=None) from=::ffff:10.35.83.166,39710, flow_id=2fe3979c, task_id=be04b683-6b8d-451c-aa0d-26d97f86fd10 (api:48)


how it was being mounted on the system:

[root@storage-ge13-vdsm1 ~]# mount | grep ge5__nfs__0
yellow-vdsb.qa.lab.tlv.redhat.com:/Storage_NFS/storage_local_ge5_nfs_0 on /rhev/data-center/mnt/yellow-vdsb.qa.lab.tlv.redhat.com:_Storage__NFS_storage__local__ge5__nfs__0 type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,soft,nosharecache,proto=tcp6,timeo=100,retrans=3,sec=sys,clientaddr=2620:52:0:2353:21a:4aff:fe16:26ab,local_lock=none,addr=2620:52:0:23bd:21a:4aff:fe16:9843)


You can see that 'noacl' is being passed by the engine and is being received by the host.
But this option is not reflected in the actual mount.

Comment 20 Avihai 2020-07-01 13:08:23 UTC

Nir, please provide a simple scenario so Ilan can verify this bug.

This bug is on NEW state if this is fixed move to ON_QA, also patch is missing please add this to Links section.

keep this bug targeted to 4.4.3 as this is not a customer or high pri bug.

Comment 21 Nir Soffer 2020-07-01 13:23:59 UTC

Based on comment 0, the mount option "ro" was pass to vdsm successfully
so the feature works and there is no bug.