vmware / open-vm-tools

Official repository of VMware open-vm-tools project
http://sourceforge.net/projects/open-vm-tools/
2.27k stars 427 forks source link

open-vm-tools does not properly discover all LVM mounted disks #94

Open Wicaeed opened 8 years ago

Wicaeed commented 8 years ago

Greetings! Before anyone's head explodes at the Issue name, let me explain:

I was setting up our monitoring system (Zabbix 2.4) to monitor our VMware environment when I noticed some odd behavior with VM resource discovery. Zabbix uses the vCenter API to discover and populate the monitoring system's inventory with vm hosts, vm guests & cluster information. I was using the Managed Object Browser to see how Zabbix was discovering & mapping the resources exposed by the VM

When looking at the resources of two similar database hosts, I noticed that one of the VMs did not have the LVM Logical Volume /data listed on the GuestDiskInfo screen in the Managed Object Browser. Both VM's were mounting this partition at /data and VM's were running the same OS. The only differences I could was that the Logical Volume naming scheme was slightly different between hosts, and that one host was running open-vm-tools and the other was running toolsVersion 10246 from the MOB.

I completely removed open-vm-tools from the VM in question and installed the same version of vmware-tools on the VM that was working, and within a short time all of the mounted disks showed up.

Curiously, our vCenter 6 appliance is also apparently running open-vm-tools, however that VM does show all of the mounted disks on the GuestDiskInfo MOB page...

Please let me know what information I can provide to help troubleshoot this (mountpoints, lvs output, etc)!

terra-nova commented 8 years ago

Hi,

I also think there's something fishy going on with the way open-vm-tools populates the GuestDiskInfo structure. We use the vCenter API for monitoring disk space on some systems, and sometimes I find that regular subdirectories are falsely reported as virtual disks. For example, on one of our VMs I get this:

/var/tmp is 95.17% full (494.17 MiB free out of 9.99 GiB).
/var/lib/mock/epel-6-x86_64/root/var/cache/yum is 93.7% full (644.41 MiB free out of 9.99 GiB).

But this is nonsense, neither /var/tmp nor /var/lib/mock... are mountpoints. They are just regular subdirectories of the root LV of the system VG.

Kind regards

cblomart commented 6 years ago

I do see the same...

On my box:

# mount | egrep  "^/"
/dev/mapper/rhel-root on / type xfs (rw,noatime,attr2,inode64,noquota)
/dev/sda1 on /boot type xfs (rw,noatime,attr2,inode64,noquota)
/dev/mapper/rhel-opt on /opt type xfs (rw,noatime,attr2,inode64,noquota)
/dev/mapper/rhel-home on /home type xfs (rw,noatime,attr2,inode64,noquota)
/dev/mapper/rhel-var on /var type xfs (rw,noatime,attr2,inode64,noquota)
/dev/mapper/rhel-var_log on /var/log type xfs (rw,noatime,attr2,inode64,noquota)

VMware reporteds disks (guestdiskinfos):

/
/boot
/home
/opt
/var
/var/log
/var/tmp

What is /var/tmp/ doing in there?