VMware ESX computer system sensor

The VMware ESX computer system sensor discovers VMware ESX servers.

Sensor name that is used in the GUI and logs

VmwareComputerSystemSensor

Elements discovered by the sensor

Discovering the VMware ESX server (host machine) runs as it does for any other operating system. The most important issues that impact discovery is connectivity and authentication. If the account configured in the TADDM access list can connect to the VMware ESX server target, the discovery is successful.

Discoveries are launched using commands run over SSH.

Discovering the Virtual Machines (guest machines) actually discovers two instances of a VM, a physical instance and a virtual instance. After discovery, TADDM merges these two instances. The result is a single instance with all the attributes of a physical machine, but with the indication that it is virtual. In the XML output of the database, this output is represented by an attribute such as:

<virtual>true</virtual>

In the Discovery Management Console, a VM (virtual machine) is represented by a computer system icon that is blue and transparent.

The physical instance is discovered by the normal TADDM sensor for the particular guest operating system, such as Linux®. It is discovered just like a physical machine, which includes finding typical devices and attributes. No special TADDM sensors are required to discover these virtual machines any differently than the physical machines they emulate.

The virtual instance is discovered by the VMware ESX sensor. It primarily uses configuration files (.vmx) and commands on the VMware ESX server to discover a shallow instance with data that can be described as the following:

  • Attribute data required to match naming rules and create a valid stand-alone VM instance
  • Certain basic information that the VMware ESX server provides through the vmware-cmd command.
  • An attribute (primaryMACAddress) that is used to reconcile the shallow virtual instance with any physical instance that can be discovered.

There are two user scenarios for a VM discovery:

  • All-inclusive: When discovering a scope that includes the server and physical instances, everything works as expected.

    The result is a virtual instance that shows up in the appropriate domain to match its domain name. This virtual instance is populated with all the attributes that a similar physical machine would have.

    In addition, it has data and relationships regarding the host ESX server, a virtual attribute that gets set to true, and a VMID attribute that gets set to the one specified in the .vmx configuration file. As long as the TADDM server has connectivity and authentication to the VM, this scenario does not present any problems.

  • VM-only: When discovering a scope that contains only the VM, it shows up as a physical machine with typical attributes, except that VMware intentionally overrides some model and manufacturer data.

    Therefore, it is possible to determine if a machine is virtual by examining some attributes. However, the icon is the one used for physical computers, and the virtual attribute is not set to true.

To ensure all FQDN information about a VM is collected, you must have VMware Tools installed on the VM.

Limitations

VMware vCenter servers are not discovered by the VMware ESX computer system sensor. If you must discover these servers, use the VMware Virtual Center server sensor.

All computer system sensors and the SNMP MIB2 sensor ignore network interfaces that are configured to be down. TADDM does not populate the net.IpNetwork attribute on the following types of IP interfaces:
  • loopback, for example, 127.0.0.1, 0:0:0:0:0:0:0:1
  • link-local, for example, 169.254.1.1, FE80:0:0:0:0:0:0:1
  • multicast, for example, 224.0.0.1, FF00:0:0:0:0:0:0:1
  • unspecified, for example, 0.0.0.0, 0:0:0:0:0:0:0:0
Therefore, IP networks are not populated in the TADDM user interface.

For VMware ESX server version 2.5 (all releases), you can discover virtual systems only that are running.

Model objects created

The sensor creates the following model objects:

  • core.LogicalContent
  • net.IpInterface
  • net.L2Interface
  • process.CPUResourcePool
  • process.MemoryResourcePool
  • process.NetworkAdapterResourcePool
  • relation.AllocatedTo
  • relation.DonatedTo
  • sys.CPU
  • sys.darwin.Darwin
  • sys.darwin.DarwinUnitaryComputerSystem
  • sys.dos.Dos
  • sys.dos.DosUnitaryComputerSystem
  • sys.DNSResolveEntry
  • sys.FileSystem
  • sys.freebsd.FreeBSD
  • sys.freebsd.FreeBSDUnitaryComputerSystem
  • sys.linux.Linux
  • sys.linux.LinuxUnitaryComputerSystem
  • sys.Memory
  • sys.netware.Netware
  • sys.netware.NetwareUnitaryComputerSystem
  • sys.OperatingSystem
  • sys.sun.Solaris
  • sys.sun.SunSPARCUnitaryComputerSystem
  • sys.UnitaryComputerSystem
  • sys.vmware.VmwareESX
  • sys.vmware.VmwareUnitaryComputerSystem
  • sys.windows.WindowsComputerSystem
  • sys.windows.WindowsOperatingSystem