Bug 1373930

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>
Severity:	high	Docs Contact:
Priority:	high
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
Target Release:	---	Flags:	ratamir: testing_plan_complete-
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	dr
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-05-15 17:49:33 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:
Bug Depends On:	1393902
Bug Blocks:	1435570

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 10 Yaniv Lavi 2017-11-09 11:18:01 UTC

Closing based on comment #9.

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

BZ<2>Jira Resync