Agent installed on OracleVM virtualization server version 3.1.1.
Kernel:2.6.39-200.1.1.el5uek #1 SMP Thu Apr 19 18:14:07 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux

could you please add a summary of the problem here (as per https://zabbix.org/wiki/Docs/bug_reporting_guidelines#Reporting_an_issue ), thanks

Problem: file system discovery does not discover ocfs2 file systems

Description:
We have set up zabbix agent on Oracle VM virtualization hosts(cut down linux version with xen support).
Oracle virtualization server version is 3.1.1. Product page http://www.oracle.com/technetwork/server-storage/vm/overview/index.html

Problem is - agent does not discover mounted ocfs2 file systems(template OS linux, discovery rules).

These file systems are visible as normal local file systems in "df -h" output like:
/dev/mapper/3600508b4000753ee0001000000290000
900G 867G 34G 97% /OVS/Repositories/0004fb000003000099de5999d1a266f8

and also in /proc/mounts like this:
/dev/mapper/3600508b4000753ee0001000000290000 /OVS/Repositories/0004fb000003000099de5999d1a266f8 ocfs2 rw,relatime,_netdev,heartbeat=global,nointr,data=o rdered,errors=remount-ro,cluster_stack=o2cb,coherency=full,user_xattr,ac l 0 0

First idea was it is because the regexp for file system discovery did not include neither ocfs2 or ocfs.
Administration->General->Regular expressions -> File systems discovery was"^(btrfs|ext2|ext3|ext4|jfs|reiser|xfs|ffs|ufs| jfs|jfs2|vxfs|hfs|ntfs|fat32)$"
we then changed it to "^(btrfs|ext2|ext3|ext4|ocfs2|jfs|reiser|xfs|ffs|u fs|jfs|jfs2|vxfs|hfs|ntfs|fat32)$", but ocfs2 type file systems are still not discovered(suitable time has past).

Zabbix server 2.0.3
zabbix agent 2.0.2

I did additional tests on agent side:
#zabbix_agent -p (filtered output follows)

vfs.fs.discovery [s|{
...
"

":"\/proc\/sys\/fs\/binfmt_misc",
"

":"ocfs2"},

Then doing zabbix_get from server:

1. zabbix_get -s x.x.x.x -k vfs.fs.size[/boot]
   101116928
   #zabbix_get -s x.x.x.x -k vfs.fs.size[/proc/sys/fs/binfmt_misc]
   0
2. zabbix_get -s x.x.x.x -k vfs.fs.size[/OVS/Repositories/0004fb000003000099de5999d1a266f8]
   ZBX_NOTSUPPORTED

Additional info: upgrading zabbix_agentd to 2.0.3 did not help.

looks like it does discover them, but does not support monitoring them

Related issue: ZBX-5229

Hi, is there any progress or prognosis for this issue?
Oracle VM virtualization picks up speed and is used more and more. Would be very usefull to use zabbix agent where applicable to monitor space in storage repositories(ocfs2).

no specific plans at this time

Tested with agent 2.4.6 no change.

This is a problem in our 2.2.4 environment as well. The ocfs2 filesystems are discovered, but then go into "not supported" with "Not supported by Zabbix Agent".

I used the following script to create an OCFS2 partition on my Debian (stable, 8.1) box:

TARGET_FILE=/home/vl/tmp/ocfs2
TARGET_MP=/mnt/ocfs2
TARGET_SIZE=200000 # bytes

sudo umount $TARGET_MP >/dev/null 2>&1
dd if=/dev/zero of=$TARGET_FILE bs=1024 count=$TARGET_SIZE || exit 1
sudo mkfs.ocfs2 -b 4k -C 32K -L "MyOCFS2Cluster" -N 4 $TARGET_FILE || exit 1
sudo mount $TARGET_FILE $TARGET_MP || exit 1

After that df shows the filesystem properly

$ df -h /mnt/ocfs2
Filesystem      Size  Used Avail Use% Mounted on
/dev/loop0      196M   71M  126M  36% /mnt/ocfs2

$ grep /mnt/ocfs2 /proc/mounts 
/dev/loop0 /mnt/ocfs2 ocfs2 rw,relatime,_netdev,heartbeat=local,nointr,data=ordered,errors=remount-ro,atime_quantum=60,coherency=full,user_xattr,acl 0 0

So then I check if Zabbix filesystem discovery sees it and it does

$ bin/zabbix_get -s localhost -p 11339 -k vfs.fs.discovery | json_xs
[...]
      {
         "{#FSNAME}" : "/mnt/ocfs2",
         "{#FSTYPE}" : "ocfs2"
      }
[...]

Also getting the metrics of discovered entities works

vl@dimir:trunk:trunk$ bin/zabbix_get -s localhost -k vfs.fs.size[/mnt/ocfs2] 
204800000
vl@dimir:trunk:trunk$ bin/zabbix_get -s localhost -k vfs.fs.size[/mnt/ocfs2,pfree] 
64.080000

Using latest trunk (pre-3.0.0-alpha3, r55678). In your examples seems some mapper is used. Is there different ways on how to set up OCFS2 partition?

By design ocfs2 is cluster file system - it can be mounted from several hosts simultaneously. We use it clustered way.

I compared mount options:
clustered mount: rw,relatime,_netdev,heartbeat=global,nointr,data=ordered,errors=remount-ro,cluster_stack=o2cb,coherency=full,user_xattr,acl 0 0
single host : rw,relatime,_netdev,heartbeat=local,nointr,data=ordered,errors=remount-ro,atime_quantum=60,coherency=full,user_xattr,acl 0 0

Differences:
—
heartbeat=global vs local - https://blogs.oracle.com/wim/entry/ocfs2_global_heartbeat
One of the main features added most recently is Global Heartbeat. OCFS2 as a filesystem typically was used with what's called local heartbeat. Basically for every filesystem you mounted, it would start its own local heartbeat, membership mechanism. The disk heartbeat means a disk io every 1 or 2 seconds for every node in the cluster, for every device. It was never a problem when the number of mounted volumes was relatively small but once customers were using 20+ volumes the overhead of the multiple disk heartbeats became significant and at times became a stability issue.
Global heartbeat was written to provide a solution to the multiple heartbeats. It is now possible to specify on which device(s) you want a heartbeat thread and then you can mount many other volumes that do not have their own and the heartbeat is shared amongst those one, or few threads and as such significantly reducing disk IO overhead.

cluster_stack=o2cb https://oss.oracle.com/projects/ocfs2-tools/dist/documentation/v1.4/o2cb.html
o2cb is the default cluster stack for the OCFS2 file system. It includes a node manager (o2nm) to keep track of the nodes in the cluster, a heartbeat agent (o2hb) to detect live nodes, a network agent (o2net) for intra-cluster node communication and a distributed lock manager (o2dlm) to keep track of lock resources. All these components are in-kernel. It also includes an in-memory file system, dlmfs, to allow userspace to access the in-kernel dlm.

atime_quantum=60 OCFS2 will not update atime unless this number of seconds has passed since the last update. Set to zero to always update atime. This option need work with strictatime.
—
I set up zabbix agent 2.4.6 on test environment today and tried to retrieve values from server. Got other message, but that probably is other and not relevant issue:

1. zabbix_get -s x.x.x.x -k vfs.fs.size[/OVS/Repositories/0004fb0000030000973b3c1631c70e2d]
   ZBX_NOTSUPPORTED: Cannot obtain filesystem information: [13] Permission denied
   I can get values for / and /boot - no problem.

About /dev/mapper. It just forms single virtual LUN for use, but technically you can "see" same LUN via muptiple SAN paths. OCFS2 is formatted onto this virtual device(LUN).
Do not know internals of zabbix_agent system calls, may be /dev/mapper type device confuses it? It should not, for example file systems on top of LVM(also /dev/mapper virtual devices) are monitored by agent with no problems.

In case test setup is needed - easyest would be to set up iscsi target on some linux host and connect/format/mount ocfs2 luns from there to couple other machines, probably Virtualbox setup with 3 VMs on single host would be ok.
Additional info http://www.oracle.com/us/technologies/linux/ocfs2-best-practices-2133130.pdf

It doesn't look like a trivial task to set the cluster up on my Debian stable. Some tools are missing, perhaps also not the latest version. If you could give us an access to some test machine where we could play with it - that'd be great. Or if you could take some time and provide us with the simplest and easiest example, listing the exact sequence of commands on a fresh installation, on how to set this up and get the error - it would be great. Otherwise we do not have time to spend on learning all this technology at this time.

Also, thank you for trying agent 2.4.6, it gives more information on the error. Could you run the following command:

$ strace zabbix_agentd -t vfs.fs.size[/OVS/Repositories/0004fb0000030000973b3c1631c70e2d] > /tmp/zabbix-ocfs2-strace.log 2>&1

and attach the generated log file?

strace zabbix_agentd -t vfs.fs.size[/OVS/Repositories/0004fb0000030000973b3c1631c70e2d]

While collecting strace log I discovered interesting thing:

1)"zabbix_agentd -t" when run on agent - it does return file system size, here folow some examples:

1. zabbix_agentd -t vfs.fs.size[/boot]
   vfs.fs.size[/boot] [u|103512064]
2. zabbix_agentd -t vfs.fs.size[/OVS/Repositories/0004fb0000030000973b3c1631c70e2d]
   vfs.fs.size[/OVS/Repositories/0004fb0000030000973b3c1631c70e2d] [u|10737418240]

2)if "zabbix_get -s" is run for the same item regarding ocfs2 - it returns "Permission denied". For /boot(ext3) size is returned.

1. zabbix_get -s x.x.x.x -k vfs.fs.size[/boot]
   103512064
2. zabbix_get -s x.x.x.x -k vfs.fs.size[/OVS/Repositories/0004fb0000030000973b3c1631c70e2d]
   ZBX_NOTSUPPORTED: Cannot obtain filesystem information: [13] Permission denied

3)If zabbix_agentd is run as root(AllowRoot=1 in config) then also from server ocfs2 size value is returned
if zabbix agent is run ar root then from server query returns value:

1. zabbix_get -s x.x.x.x -k vfs.fs.size[/OVS/Repositories/0004fb0000030000973b3c1631c70e2d]
   10737418240

Where is the difference how agent asks values from ext3 vs ocfs2?

I assume that in case 1) you were running "zabbix_agentd" command as root?

There is really no difference in how we get the size of a ext3 or any other filesystem partition size. We just use (or in your case, is used) statfs() system call. In your case when zabbix_agentd is running as non-root statfs() returns EACCESS (13, "Permission denied"). From the man page of statfs():

Perhaps you could search further for a "search permission" of ocfs2.

If there is a certain group for accessing ocfs2 partition you could add user "zabbix" to it. Also on one forum I saw people complaining about permission errors on ocfs2 which appeared to be because of SELinux. Perhaps you could check that also.

Yes, in case 1) I run command as root.

It turns out problem is simply file system permissions then.
Really ocfs2 file system is mounted under multiple level path:

Filesystem            Size  Used Avail Use% Mounted on
...
/dev/mapper/3600144f0ff43941b00005559ca760018   10G  4.2G  5.9G  42% /OVS/Repositories/0004fb0000030000973b3c1631c70e2d

looking deeper ir turns out in the mddle of the path there is no access for zabbix user:

# ls -ld /OVS
drwxr-xr-x 3 root root 4096 Jun 11 15:03 /OVS
# ls -ld /OVS/Repositories/
drwx------ 3 root root 4096 Sep 22 10:11 /OVS/Repositories/
# ls -ld /OVS/Repositories/0004fb0000030000973b3c1631c70e2d/
drwxr-xr-x 8 root root 3896 Sep 22 10:11 /OVS/Repositories/0004fb0000030000973b3c1631c70e2d/

SElinux is disabled.

If I temporarily add execute permissions to the /OVS/Repositories/ for zabbix user, zabbix server can get value of that ocfs2 file system and also discover ocfs2 file system.

Thanks for pointing to right direction! Initially I thought that it does not matter under what mount path file system is mounted to get its parameters for discovery.
I guess ticket can be closed.

thanks for the update, closing then

One more test which proves that read/search permission is required for all folders on the path to a mount point:

# df -h | grep sda
/dev/sda2       184G  143G   41G  78% /
/dev/sda1       488M   31M  457M   7% /boot
/dev/sda5        14G  6.0G  6.5G  49% /root/1

# ps aux | grep zabbix | sed 'q'
zabbix   10326  0.0  0.0  95084  2760 ?        S    23:02   0:00 ./zabbix_agentd

# whoami
root

# zabbix_get -s localhost -k vfs.fs.size[/root/1,pfree]
ZBX_NOTSUPPORTED: Cannot obtain filesystem information: [13] Permission denied

# zabbix_agentd -t vfs.fs.size[/root/1,pfree]
vfs.fs.size[/root/1,pfree]                    [d|51.871173]

# ls -ld /root
drwx------ 41 root root 4096 Mar  3 23:29 /root

# ls -ld /root/1
dr-x------. 20 root root 4096 Nov 15 18:40 /root/1

Fix parent folder permission for the mount point and successfully test:

# chmod o+rx /root

# ls -ld /root
drwx---r-x 41 root root 4096 Mar  3 23:29 /root

# zabbix_get -s localhost -k vfs.fs.size[/root/1,pfree]
51.871173