Hide Forgot
Due to lvm bug#1344206, vdsm lvm commands slow down significantly because filter is not considered.
Nir has already provided a fix for it in: https://gerrit.ovirt.org/#/c/58943/
Tentatively targeting to 3.6.8, although if this patch is the only thing required and we're sure it will work with VDSM 3.6.z too, I wouldn't mind seeing it in 3.6.7.
Gil, considering comment 2, can we have quick testing of this patch?
The vdsm patch using global_filter in place of filter is correct and will continue to be fine once the lvm filter is fixed. The only difference between filter and global_filter is that filter does not apply to lvmetad, but global_filter does. RHEV is not using lvmetad, so filter and global_filter should be the same (when working correctly.)
Created attachment 1167718 [details] repoplot on idle hypervisor with 50 storage domains The section in the middle uses filter, the right and left parts are using global_filter. I modified vdsm code on the machine and restarted vdsm. We see lvm times of ~1 seconds when using global_filter vs ~7 seconds when using filter.
Allan, can you attach vdsm logs to this bug, showing the timeframe where lvm commands run slowly?
Adding back request for Gil, see comment 4.
Created attachment 1167924 [details] repoplot of vdsm.log from host tulhv1p10 rhevh 7 20160328.0 We don't see unusual slow lvm commands in this log, this is probably not the right log. An easy way to get more interesting info from the logs is to do: unxz *.xz for f in vdsm.log*; /path/to/vdsm-source/contrib/repoplot $f done Or maybe only for some of the log files, around the time there was an issue e.g., migration failed. For example of slow lvm commands, see bug 1081962.
Nir, I see that this issue is targeted to 3.6.8. I will be able to handle it only after we complete the scale activities for 3.6.7.
Marina, I don't mind that Fabian will handle this, but this should be fixed in vdsm, not in ovirt-node. ovirt-node should require vdsm vdsm version that requires the fixed lvm package.
What lvm version are we requiring now? We do not really need to verify but on ly the lvm pkg right?
(In reply to Aharon Canan from comment #35) > What lvm version are we requiring now? lvm2-2.02.130 > > We do not really need to verify but only the lvm pkg right? Yes
(In reply to Yaniv Dary from comment #36) > (In reply to Aharon Canan from comment #35) > > What lvm version are we requiring now? > Correction: > 7:2.02.130-5.el7_2.5 > > > > > We do not really need to verify but only the lvm pkg right? > > Yes
[root@green-vdsa ~]# yum deplist vdsm-4.18.6-1.el7ev.x86_64 |grep lvm Failed to set locale, defaulting to C Repository jboss-eap-7.0.Z is listed more than once in the configuration dependency: lvm2 >= 7:2.02.130-5.el7_2.5 provider: lvm2.x86_64 7:2.02.130-5.el7_2.5
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://rhn.redhat.com/errata/RHEA-2016-1671.html