Hide Forgot
Description of problem: VDSM uses iscdiadm to perform iSCSI operations which are often complicated to debug. iscsiadm offers a -d (--debug) parameter on all its commands which adds debug information to the command's output, which may be useful to redirect to VDSM's log. This could probably be added in iscsiadm.py in the _runCmd function, where the value of -d is obtained from some external conf. file.
The whole idea this RFE is questionable, being iscsiadm errors actually logged in vdsm.log and there is no need for logging iscasiadm possitive flows in vdsm.logs. Dumping big chunks of unrelated data on the vdsm log will make vdsm.log worse.
(In reply to Eduardo Warszawski from comment #1) > The whole idea this RFE is questionable, being iscsiadm errors actually > logged in vdsm.log and there is no need for logging iscasiadm possitive > flows in vdsm.logs. > > Dumping big chunks of unrelated data on the vdsm log will make vdsm.log > worse. But without this debugging information it makes virtually impossible to debug any iscsiadm related issues, like the issue of configuration that becomes corrupted, and prevents the machine from performing any other iSCSI related tasks, until the corrupted DB is removed. The issue is we can't really know at which stage the configuration became corrupted, unless we'll be able to collect and analyze this debug information. If you are concerned with vdsm.log being filled up with iscsiadm debug info, then there is an option to store it in a separate log file i.e. iscsiadm.log, but additional timestamping headers will have to be added before each debug dump.
Patch is available here: http://gerrit.ovirt.org/#/c/20338/
Seems that this RFE needs more discussion; waiting for maintainers aproval on this RFE.
(In reply to Lev Veyde from comment #2) > The issue is we can't really know at which stage the configuration became > corrupted, unless we'll be able to collect and analyze this debug > information. Lev, could you provide more information about the corrupted config issue? Is there a BZ on that? If we need iscsiadm's debug info for a specific research case, we can apply the suggested (or simpler) patch to the machine(s) in question, or change /usr/sbin/iscsiadm to a script with `/usr/sbin/iscsiadm -d 8 $*`.
(In reply to Dan Kenigsberg from comment #5) > (In reply to Lev Veyde from comment #2) > > > The issue is we can't really know at which stage the configuration became > > corrupted, unless we'll be able to collect and analyze this debug > > information. > > Lev, could you provide more information about the corrupted config issue? Is > there a BZ on that? If we need iscsiadm's debug info for a specific research > case, we can apply the suggested (or simpler) patch to the machine(s) in > question, or change /usr/sbin/iscsiadm to a script with `/usr/sbin/iscsiadm > -d 8 $*`. Hi Dan, BZ: https://bugzilla.redhat.com/show_bug.cgi?id=915747 We have this issue randomly appearing on all host servers that participate in CI. As already mentioned in that BZ we implemented a fix that simply erases the empty files, since without debugging info there was no way for us to try and find the source of the issue. Our guess is that some data iscsiadm receives from the SAN target causes it to crash while creating the config entry, thus leaving it in corrupted state (zero sized file). I agree that we can potentially add some code just to our env., but that will probably include a patch for VDSM which will have to be included in each VDSM build anyway and more importantly some customer(s) may potentially run into the same issue as us, and the already implemented facility will ease the debugging and troubleshooting for GSS. A simple config. switch may be implemented to turn this logging on and off.
I am not as dramatic as Saggi: first use something like mv /usr/bin/iscsiadm /usr/bin/iscsiadm_orig cat << EOF #!/bin/sh exec /usr/bin/iscsiadm_orig -d 8 "$@" EOF to find forensics for bug 915747. If it turns up useful, we can take it into Vdsm. If not - it's dead code.
Nacked by u/s maintainers. If Dan's suggestion from comment 7 ever proves useful, we can reopen this.