One VM, three witnesses

In a well-equipped environment a virtual machine is seen from several sides. The virtualization connector reads it from the hypervisor API. The network scan finds it because it has an IP and answers. The software scan reports it because an agent runs on it. Three sources, one machine.

If you do not merge them, you have it three times in your inventory. And from there nothing adds up.

Why duplicate entries cost more than they look

A duplicate asset is not merely one row too many. Protection requirements get maintained on one record, the risk analysis hangs off the second, and the vulnerability from the scan lands on the third. Each individual entry is correct, the overall picture is not. What you end up with is an asset count in a report that nobody can defend, because it depends on how many scanners you run rather than how many machines you have.

How the same machine is recognised again

So every VM found converges with the network and software scan into a single IT system. The match runs on serial number or BIOS UUID, MAC address and hostname.

Three attributes rather than one, because each has gaps on its own. A hostname changes when something is renamed and gets reused freely in test environments. A MAC address is more reliable but can show up in two machines at once after a clone. The hardware identifier is the most stable but is not supplied by every source. Only together do they hold.

The result is unspectacular and right for exactly that reason: no duplicate entries, and the VM gets the same GRC context as any other asset. Protection requirements, risks, software, vulnerabilities. No special track for virtual machines.

What else the connector creates

• Clusters as DCIM clusters, recognised reliably through the hypervisor's own ID rather than the name.
• Hypervisor hosts as IT systems with platform, vendor and management IP. If the host is also racked, it is linked to the DCIM device.
• Virtual machines with vCPUs, RAM, disk and status, linked to cluster and host.
• VM network cards with MAC address. They are the basis for the convergence above.

Detected are VMware vCenter and ESXi, Microsoft Hyper-V and Proxmox VE, each through the isidaten agent.

The same principle one level down

The connector runs exclusively on the cluster leader, as all Data Hub connectors do. Without that restriction several agents would query the same hypervisor API and deliver the same data repeatedly. Avoiding duplication therefore does not start at the matching stage but at the question of who is allowed to ask at all.

There is one hard edge: the virtualization features require an agent from version 1.40.0. Older agents do not know the scan type and report "Unknown scan type". Anyone seeing that message does not need a ticket, they need an agent update.

More on the virtualization module page.