|Summary:||[RFE][HC] Expose mount options under getStorageDomainInfo verb (for DR and hosted engine)|
|Product:||Red Hat Enterprise Virtualization Manager||Reporter:||Roy Golan <rgolan>|
|Component:||vdsm||Assignee:||Fred Rolland <frolland>|
|Status:||CLOSED ERRATA||QA Contact:||Nikolai Sednev <nsednev>|
|Version:||2.1.0||CC:||bugs, frolland, lsurette, msivak, nsednev, phbailey, ratamir, srevivo, stirabos, tnisan, ycui, ykaul, ylavi|
|Target Milestone:||ovirt-4.2.0||Keywords:||FutureFeature, Improvement, Reopened, Triaged|
|Fixed In Version:||Doc Type:||If docs needed, set a value|
|Doc Text:||Story Points:||---|
|Last Closed:||2018-05-15 17:49:33 UTC||Type:||Bug|
|oVirt Team:||Storage||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:||1393902|
Description Roy Golan 2016-09-07 12:57:41 UTC
Description of problem: The mount options used to mount a domain can be useful for DR and hosted engine management, when we want to reconstruct the exact connection details in the engine. See Bug 1263603 for the hosted engine use-case - Example of the current verb output: ```bash vdsClient -s 0 getStorageDomainInfo X uuid = X version = 3 role = Regular remotePath = lago_he_basic_suite_4_0_storage:/exports/nfs_he type = NFS class = Data pool = ['00000001-0001-0001-0001-000000000148'] name = hosted_storage ``` - the actual kernel mount options ```bash cat /proc/mounts | grep 'exports/nfs_he' lago_he_basic_suite_4_0_storage:/exports/nfs_he /rhev/data-center/mnt/lago__he__basic__suite__4__0__storage:_exports_nfs__he nfs rw,relatime,vers=3,rsize=262144,wsize=262144,namlen=255,soft,nosharecache,proto=tcp,timeo=600,retrans=6,sec=sys,mountaddr=192.168.200.2,mountvers=3,mountport=20048,mountproto=udp,local_lock=none,addr=192.168.200.2 0 0 ``` Based on that
Comment 1 Roy Golan 2016-09-07 12:59:21 UTC
correction- the related Bug is 1263602
Comment 2 Allon Mureinik 2016-09-25 11:19:59 UTC
The attached patch was abandoned, returning to NEW. We need to redesign the solution for this requirement.
Comment 6 Allon Mureinik 2017-09-14 15:37:41 UTC
Need to see if this is still relevant in the new HE flow.
Comment 7 Yaniv Lavi 2017-11-06 09:28:28 UTC
Does the node zero hosted engine work remove the need for this RFE?
Comment 8 Fred Rolland 2017-11-09 10:16:41 UTC
Martin, Do you need this RFE for Hosted Engine?
Comment 9 Martin Sivák 2017-11-09 11:11:37 UTC
Node 0 does not need it, the old flow does. Closing this depends on the amount of love we want to give to the old flow now.
Comment 11 Martin Sivák 2018-02-09 10:41:55 UTC
Yaniv, this or some kind of a tool might be needed to allow already deployed pre-Node 0 environments to work properly once we remove all the (administrative) SD restrictions. Like putting a non-HE disk on HE storage domains. Engine will not be able to mount the SD on non HE host if non-standard mount options are needed.
Comment 12 Yaniv Lavi 2018-02-14 12:54:13 UTC
(In reply to Martin Sivák from comment #11) > Yaniv, this or some kind of a tool might be needed to allow already deployed > pre-Node 0 environments to work properly once we remove all the > (administrative) SD restrictions. Like putting a non-HE disk on HE storage > domains. Engine will not be able to mount the SD on non HE host if > non-standard mount options are needed. We didn't support this prior to 4.2, so any such bugs would be not a bug. Special mount options are a 4.2 feature, because of the things you mentioned.
Comment 13 Yaniv Kaul 2018-03-12 08:33:35 UTC
(In reply to Yaniv Lavi from comment #12) > (In reply to Martin Sivák from comment #11) > > Yaniv, this or some kind of a tool might be needed to allow already deployed > > pre-Node 0 environments to work properly once we remove all the > > (administrative) SD restrictions. Like putting a non-HE disk on HE storage > > domains. Engine will not be able to mount the SD on non HE host if > > non-standard mount options are needed. > > We didn't support this prior to 4.2, so any such bugs would be not a bug. > Special mount options are a 4.2 feature, because of the things you mentioned. Do we expose the mount options under 'Advanced' in Cockpit? If we do, and we pass it along, please move this to ON_QA.
Comment 14 Phillip Bailey 2018-03-12 13:57:49 UTC
(In reply to Yaniv Kaul from comment #13) > Do we expose the mount options under 'Advanced' in Cockpit? If we do, and we > pass it along, please move this to ON_QA. Mount options are configurable in Cockpit and are passed in the var files, but the field is not in the advanced section. Moving to ON_QA, as requested.
Comment 21 Avihai 2018-03-28 08:28:22 UTC
Hi Fred, I did not get a replay from Simone until now(10 days ago), Is there anyone else who can help to understand if this bug was fixed or not? From my POV bug is still there as both bug's headline ('Expose mount options under getStorageDomainInfo verb') and original description of this bug clearly state what is the expected fix. If the verification scenario is not to check via getStorageDomainInfo verb that mount options are there then please provide the revised verification scenario. Please advise how to proceed here.
Comment 22 Simone Tiraboschi 2018-03-28 09:34:00 UTC
(In reply to Avihai from comment #21) Sorry for the delay, I missed this. According to comments 9, 12, 13, 14 we decided to avoid fixing it on VDSM side. In the new ansible based flow, the storage domain is going to be create over a locally running engine via REST APIs and we are passing additional mount options there. No need to infer or detect them at auto import time since in this new flow we don't have any auto import process for the hosted-engine storage domain. In order to verify it, deploy hosted-engine from CLI and/or from the cockpit wizard. Both of the two should let you enter additional mount options from the storage domain. At the end of the deployment check storage domain details, the additional mount options should be there.
Comment 23 Nikolai Sednev 2018-03-28 14:21:19 UTC
Node 0 works fine with mounting options on these components for CLI/Cockpit: ovirt-hosted-engine-setup-2.2.15-1.el7ev.noarch ovirt-hosted-engine-ha-2.2.9-1.el7ev.noarch rhvm-appliance-4.2-20180202.0.el7.noarch cockpit-160-3.el7.x86_64 cockpit-ovirt-dashboard-0.11.19-1.el7ev.noarch Linux 3.10.0-862.el7.x86_64 #1 SMP Wed Mar 21 18:14:51 EDT 2018 x86_64 x86_64 x86_64 GNU/Linux Red Hat Enterprise Linux Server release 7.5 (Maipo) Deployment with these options works fine over NFS: [ INFO ] changed: [localhost] Please specify the storage you would like to use (glusterfs, iscsi, fc, nfs)[nfs]: nfs Please specify the nfs version you would like to use (auto, v3, v4, v4_1)[auto]: v4 Please specify the full shared storage connection path to use (example: host:/path): yellow-vdsb.qa.lab.tlv.redhat.com:/Compute_NFS/nsednev_he_1 If needed, specify additional mount options for the connection to the hosted-engine storagedomain : rsize=32768,wsize=32768 After deployment I've checked that mounting option was clearly seen in "Storage->Domains->Manage Domain->Custom Connection Parameters" on hosted_storage. Please feel free to reopen if you feel that there is still missing options for this RFE.
Comment 26 errata-xmlrpc 2018-05-15 17:49:33 UTC
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2018:1489
Comment 27 Franta Kust 2019-05-16 13:07:46 UTC