Bug 1247475
| Summary: | Permission error in export domain inhibit any of the host to become SPM | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | nijin ashok <nashok> | ||||
| Component: | vdsm | Assignee: | Maor <mlipchuk> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Aharon Canan <acanan> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 3.5.0 | CC: | adevolder, amureini, bazulay, kgoldbla, lpeer, lsurette, mgoldboi, mlipchuk, nashok, srevivo, tnisan, ycui, ykaul, ylavi | ||||
| Target Milestone: | ovirt-4.0.0-alpha | ||||||
| Target Release: | 4.0.0 | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2016-05-04 11:10: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: | |||||||
| Attachments: |
|
||||||
|
Description
nijin ashok
2015-07-28 06:09:14 UTC
I don't understand the point of this BZ. The export domain, like any other domain, should be owned by 36:36. Why would you change it? Why can't the customer just chown the directory to the appropriate owner/group? (In reply to Allon Mureinik from comment #3) > I don't understand the point of this BZ. > The export domain, like any other domain, should be owned by 36:36. > > Why would you change it? > Why can't the customer just chown the directory to the appropriate > owner/group? Unfortunately I am not sure how the permission got changed in customer's environment. The permission has been fixed already and the environment is up now. However here the issue is only with export domain. But this causes the Data Center to go "non responsive" and made all storage domains status to "Unknown" even though we don't have any issue with these domains. This makes the whole RHEV environment unmanageable from the portal. As the export domain is not necessary for running the RHEV environment I think this is not an intended behavior. this is an automated message. oVirt 3.6.0 RC3 has been released and GA is targeted to next week, Nov 4th 2015. Please review this bug and if not a blocker, please postpone to a later release. All bugs not postponed on GA release will be automatically re-targeted to - 3.6.1 if severity >= high - 4.0 if severity < high Looks like the problem was resolved in the customer environment after he fixed the permissions on the Storage Domain I was trying to investigate the spmStart process in VDSM and it looks like the spm start operation iterates over all the active Storage Domains in the storage pool and tries to call _realProduce (see [1]) for each one. One of those Storage Domains is the Export Storage Domain, and since there was a permission issue the operation of spmStart failed. [1] The Exception: dcbefba5-f747-44bb-8418-c0aa561e9f01::DEBUG::2015-07-23 14:53:42,746::fileSD::152::Storage.StorageDomain::(__init__) Reading domain in path /rhev/data-center/mnt/10.0.12.90:_volume1_RHEVExport/df457e4d-536d-428b-87f1-79e3422325f5 dcbefba5-f747-44bb-8418-c0aa561e9f01::ERROR::2015-07-23 14:53:42,747::sp::294::Storage.StoragePool::(startSpm) Backup domain validation failed Traceback (most recent call last): File "/usr/share/vdsm/storage/sp.py", line 291, in startSpm File "/usr/share/vdsm/storage/securable.py", line 77, in wrapper File "/usr/share/vdsm/storage/sp.py", line 1424, in checkBackupDomain File "/usr/share/vdsm/storage/sdc.py", line 98, in produce File "/usr/share/vdsm/storage/sdc.py", line 52, in getRealDomain File "/usr/share/vdsm/storage/sdc.py", line 122, in _realProduce File "/usr/share/vdsm/storage/sdc.py", line 141, in _findDomain File "/usr/share/vdsm/storage/nfsSD.py", line 122, in findDomain File "/usr/share/vdsm/storage/fileSD.py", line 159, in __init__ File "/usr/share/vdsm/storage/fileSD.py", line 88, in validateFileSystemFeatures File "/usr/share/vdsm/storage/outOfProcess.py", line 351, in directTouch File "/usr/lib/python2.7/site-packages/ioprocess/__init__.py", line 507, in touch File "/usr/lib/python2.7/site-packages/ioprocess/__init__.py", line 391, in _sendCommand OSError: [Errno 13] Permission denied dcbefba5-f747-44bb-8418-c0aa561e9f01::DEBUG::2015-07-23 14:53:42,757::fileSD::152::Storage.StorageDomain::(__init__) Reading domain in path /rhev/data-center/mnt/10.0.12.90:_volume1_RHEVExport/df457e4d-536d-428b-87f1-79e3422325f5 dcbefba5-f747-44bb-8418-c0aa561e9f01::ERROR::2015-07-23 14:53:42,758::sp::330::Storage.StoragePool::(startSpm) Unexpected error Traceback (most recent call last): File "/usr/share/vdsm/storage/sp.py", line 302, in startSpm File "/usr/share/vdsm/storage/securable.py", line 77, in wrapper File "/usr/share/vdsm/storage/sp.py", line 205, in _updateDomainsRole File "/usr/share/vdsm/storage/sdc.py", line 98, in produce File "/usr/share/vdsm/storage/sdc.py", line 52, in getRealDomain File "/usr/share/vdsm/storage/sdc.py", line 122, in _realProduce File "/usr/share/vdsm/storage/sdc.py", line 141, in _findDomain File "/usr/share/vdsm/storage/nfsSD.py", line 122, in findDomain File "/usr/share/vdsm/storage/fileSD.py", line 159, in __init__ File "/usr/share/vdsm/storage/fileSD.py", line 88, in validateFileSystemFeatures File "/usr/share/vdsm/storage/outOfProcess.py", line 351, in directTouch File "/usr/lib/python2.7/site-packages/ioprocess/__init__.py", line 507, in touch File "/usr/lib/python2.7/site-packages/ioprocess/__init__.py", line 391, in _sendCommand OSError: [Errno 13] Permission denied dcbefba5-f747-44bb-8418-c0aa561e9f01::ERROR::2015-07-23 14:53:42,758::sp::331::Storage.StoragePool::(startSpm) failed: [Errno 13] Permission denied dcbefba5-f747-44bb-8418-c0aa561e9f01::DEBUG::2015-07-23 14:53:42,758::sp::337::Storage.StoragePool::(_shutDownUpgrade) Shutting down upgrade process (In reply to Maor from comment #7) > Looks like the problem was resolved in the customer environment after he > fixed the permissions on the Storage Domain > > I was trying to investigate the spmStart process in VDSM and it looks like > the spm start operation iterates over all the active Storage Domains in the > storage pool and tries to call _realProduce (see [1]) for each one. > One of those Storage Domains is the Export Storage Domain, and since there > was a permission issue the operation of spmStart failed. So what's the remaining action item here? (In reply to Allon Mureinik from comment #9) > (In reply to Maor from comment #7) > > Looks like the problem was resolved in the customer environment after he > > fixed the permissions on the Storage Domain > > > > I was trying to investigate the spmStart process in VDSM and it looks like > > the spm start operation iterates over all the active Storage Domains in the > > storage pool and tries to call _realProduce (see [1]) for each one. > > One of those Storage Domains is the Export Storage Domain, and since there > > was a permission issue the operation of spmStart failed. > So what's the remaining action item here? It depends what are we plan to do with the SPM, this issue can be solved as part of the SPM removal. I would want a clear error in the manager to say this is the issue. The main problem here is that you need to dig to get the permission error. Created attachment 1153789 [details]
audit_log_error
Looks like we already have an audit log indicating there was a permissions error (see Comment 12), probably due to fix https://gerrit.ovirt.org/#/c/54958/. Moving this bug to Currentrelease status, please feel free to re-open if there is an issue that needs to be addressed. |