Red Hat Bugzilla – Bug 1373930
[RFE][HC] Expose mount options under getStorageDomainInfo verb (for DR and hosted engine)
Last modified: 2018-05-15 13:51:05 EDT
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
correction- the related Bug is 1263602
The attached patch was abandoned, returning to NEW. We need to redesign the solution for this requirement.
Need to see if this is still relevant in the new HE flow.
Does the node zero hosted engine work remove the need for this RFE?
Martin, Do you need this RFE for Hosted Engine?
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.
Closing based on comment #9.
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.
(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.
(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.
(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.
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.
(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.
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.
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