| Summary: | [vdsm][performance]After fencing vdsm it takes it 4 minutes to come up | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Moran Goldboim <mgoldboi> | ||||
| Component: | vdsm | Assignee: | Eduardo Warszawski <ewarszaw> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Haim <hateya> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 6.3 | CC: | abaron, bazulay, danken, iheim, ilvovsky, ofrenkel, yeylon, ykaul | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | vdsm-4.9-92 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2011-12-06 07:31:35 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Attachments: |
|
||||||
I don't think there's anything we can do about it, as most of the time is wasted inside pvs:
MainThread::DEBUG::2011-07-14 15:19:43,512::lvm::359::Storage.Misc.excCmd::(cmd) '/usr/bin/sudo -n /sbin/lvm pvs --config " devices { pref
MainThread::DEBUG::2011-07-14 15:23:38,006::lvm::359::Storage.Misc.excCmd::(cmd) SUCCESS: <err> = ' /dev/mapper/36006016066102900184f9fa5
However, connectStoragePool keeps taking ages (6 minutes) to complete, which confuses rhevm. The log shows 34 connectStoragePool interlaced with 10 disconnectStoragePool. Omer, why are disconnectStoragePool sent at all?
its hard to say without rhevm log, but guessing the possible flow, i'd say this is the only up host in the pool, so trying to select spm every 10 secs will do the connectStoragePool. about the disconnectStoragePool - since there are only 10, i can guess they are caused or by the user with maintenance, or reconstruct master which requires disconnectStoragePool, or user tries to activate a host (not the first one - less likely), and it moves to non-operational (In reply to comment #5) > http://gerrit.usersys.redhat.com/#change,775 verified on 4.9-104. vdsm now initialize faster by responding to getVdsCaps with regardless of storage connection, this ease the pain described above. 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. http://rhn.redhat.com/errata/RHEA-2011-1782.html |
Created attachment 512904 [details] vdsm log Description of problem: After fencing vdsm it takes it 4 minutes to come up - issue happened on 50 SDs FC deployment, sending an offline status to master domain. caused the vdsm to be fenced and afterwards it took it 4 minutes to come up. Version-Release number of selected component (if applicable): vdsm-4.9-81.el6.x86_64 How reproducible: always Steps to Reproduce: 1.make master SD offline- make sure all paths are offline( echo offline > /sys/block/sdby/device/state) 2.vdsm will then fence. 3. Actual results: Expected results: Additional info: MainThread::INFO::2011-07-14 15:19:43,268::vdsm::71::vds::(run) I am the actual vdsm 4.9-81 Thread-11::DEBUG::2011-07-14 15:23:45,274::supervdsm::43::SuperVdsmProxy::(__init__) Connected to Super Vdsm