The network team is planning to move a port group to a new distributed switch. On paper it is a routine configuration change in vCenter. In practice someone from operations asks: “Which applications run on that port group?” The virtualisation administrator opens the console and starts going through virtual machines. The network engineer works out which uplinks and leaf switches carry the traffic. The service owners find out about the change when something stops responding.
Why the virtual network is usually missing from the CMDB
A classic CMDB records servers, applications and physical network devices. The virtual network sits between them and changes often: port groups appear with new projects, VLANs are regrouped, hosts get new uplinks. Manual records cannot keep up with such a layer, and automatic discovery often stores it only as an attribute of a virtual machine rather than as an item in its own right, with relationships.
The result is a gap in the dependency map. The impact of a change is calculated on the servers, but not on the network that connects them. And network changes are among those that hit the most services at once.
How Stilla handles it
In Stilla, virtual switches and port groups are CMDB items in their own right, with their relationships:
- Virtual switches – distributed and standard, linked to the hosts that use them.
- Port groups and VLANs – which switch they are on, which VLAN they carry and which virtual machines and VMkernel adapters are connected to them.
- Host uplinks – which physical network cards carry the traffic and into which leaf switches.
The dependency map therefore runs without a break from the business service through the application and virtual machine down to the port group, uplink and physical switch. The impact calculation for a change or an outage uses the same graph as everything else in the product – incidents, changes, patch plans and monitoring situations.
Disks belong to the server, shared disks are items of their own
We organised storage the same way. A virtual machine’s disks are recorded in the server inventory, where they naturally belong, and during discovery they are automatically linked to the datastore they sit on. Only a disk with a life of its own is a separate CMDB item: a cluster’s shared disk or an RDM disk mapped directly from the array. This keeps the map from growing by thousands of items with no information value, while still showing which servers and services depend on a specific datastore or LUN.
The “Disks and storage” data quality check flags inconsistencies – for example a disk with no link to a datastore, or a shared disk that only one cluster node can see.
What this means for operations
The next time the network team plans to move a port group, they create a change and, before it goes for approval, Stilla shows:
- which virtual machines and VMkernel adapters depend on the port group,
- which uplinks and leaf switches carry the traffic,
- which applications and business services will be affected and whether redundancy protects them,
- which service owners the outage concerns and when their maintenance windows are.
Service owners approve the outage with the concrete impact in hand, not with a generic “network maintenance” notice. And if something goes wrong after the change, monitoring situations are matched to the change that probably caused them, thanks to the same topology.
How to get the data into the CMDB
The virtual network can be loaded into Stilla through the discovery API – including matching to existing items, full synchronisation and retiring what no longer exists in vCenter – or by importing CSV and Excel files. A connector that will collect the data from vCenter automatically is in preparation.
A map that ends at the server answers only half the question. A map that runs all the way to the physical switch lets you plan network changes with peace of mind.
Stilla Standard
For organisations that want a reliable CMDB and managed ITSM processes.