VCF Operations natively sees VMware. Our management packs extend it across servers, storage, SAN, network, security, facility, backup and applications - so hardware faults, capacity risks and service degradation land on the same objects your team already works with. The MCP servers that make all of it available to AI agents are part of the same subscription - not a separate product and not a separate licence.
When a business service slows down or stops, the cause is usually somewhere nobody is looking. Database slows down due to disk failure. A firewall quietly refusing connections to your application. Temperature climbing in your Data Center for unknown reasons. Each of those belongs to a different team, with a different console and a different definition of normal - and none of them will tell you that ERP is the thing at risk.
Every layer reports healthy, because every layer is healthy by its own definition. Nobody owns the question the board is asking. The packs relate these objects to each other, so the failing component and the service it threatens appear in one place - with the cause marked.
Without the packs: separate investigations, separate tools, a separate clock running on each - and nobody able to say which service is at risk.
Your most expensive engineers spend incidents ruling layers out. That time is invisible in any budget line, and it is the largest one.
When a business-critical application is unavailable, the cost starts immediately: lost revenue, damaged reputation and customers who remember it. The length of that outage is decided by how fast you find the cause - which is the part you can actually influence.
A service running without redundancy after one path quietly failed. A workload with no valid restore point because nobody added it to a backup job. Each changes nothing today and everything about your exposure.
VCF Operations is a required component of every VMware deployment, not an optional analytics tool you deploy if you have time. It is already running, already paid for, and increasingly the console from which the platform itself is operated. It knows the VMware world thoroughly. Everything else in your infrastructure that touches VMware is what we add - so the picture is complete rather than partial.
A required component of every VMware deployment of VCF or VVF.
Included in VCF and VVF. No new licence, no sizing exercise.
Your administrators work in it daily regardless.
Patching, upgrades, certificates and fleet-wide policies.
You do not need to deploy a monitoring platform, size it, license it or train your team on it. The only open question is whether that console shows you the VMware layer alone - or your entire infrastructure. That is exactly what management packs decide.
The monitoring software you already own. Licensed, deployed and staffed - and it knows the VMware software stack thoroughly.
Visibility: the VMware software stack
Management packs for everything the stack actually runs on. No second platform, no second console, no second licence - the same screen, looking further down.
Visibility: the full stack - every layer that touches VMware, not just the VMware layer
Don’t worry: you do not have to throw anything away, and there is no migration project. Management packs add the layers your current tool cannot connect to the services they support - and that connection is what turns an alert into a decision.
Adds the layers nobody connects to your business services today, inside a platform you already own.
Same team, same dashboards, same contracts. Alerts and data flow onward into whatever you use today - no migration, no side to pick.
Alerts and data can flow onward into Zabbix, Nagios or any other monitoring, SIEM or ITSM solution you already use. We are not asking you to pick a side in a monitoring war - there are dozens of good platforms, and replacing one is rarely the problem you actually have.
VCF Extensions are plugins and software appliances dedicated to the VCF platform, extending it with capabilities in the scope of security, infrastructure, applications and business services. Features are developed in response to customer needs reported since 2021. Full integration with the VCF platform: dashboards, relationships, alarms, workflows and blueprints. Covered by technical support under a subscription and/or managed services. Developed by an authorized VMware by Broadcom partner holding Technology Alliance Partner and Broadcom Premier Advantage Partner statuses.
That is what turns separate facts into a single diagnosis. Because pack objects are related to the services they affect, a failing fan or a rebuilding storage pool appears next to the business service it is putting at risk - not in a tool someone has to remember to open.
Every one of these already emits data, and something already collects it. Four systems, four definitions of normal, and none of them knows the others exist. A management pack does not add data. It adds the relations - which is why one failed disk and a degraded ERP stop being six separate tickets and become one finding.
Three stages. The middle one is where the value sits.
Each pack talks to the device or platform over its own management interface - no agent on the monitored system in most cases, and collection continues out-of-band even when the system itself has stopped answering.
Collected objects are related to what they actually affect - an array to the datastore it backs, a switch port to the host behind it, a load balancer member to the virtual machine answering the request. Those relations are what let a component fault be expressed as a risk to a named service.
Ready on install. Alerts arrive enriched with environment context rather than as raw traps, so noise from development or non-critical resources can be suppressed by policy instead of ignored by habit.
Collection through management interfaces and APIs - most integrations require nothing installed on monitored systems.
No platform to size or deploy. A pack is installed into a system that is already running.
Every integration and every AI Extension is covered by a single subscription - no per-pack shopping list to assemble before you can start. A trial runs against your own infrastructure first.
Pick the layer that is currently a blind spot for you.
Hover a layer to see what stops being a blind spot, which platforms are covered, and one scenario from practice.
Component-level health from the server's own management controller, related to the workloads running on it - so a failing component is visible as a service risk, not as a line in a hardware portal.
Dell PowerEdge · HPE ProLiant and Synergy · Lenovo ThinkSystems - via Redfish, the open industry standard, so other platforms can be added without a new pack.
In practice: a DIMM fails and the host stops answering. vCenter reports “host not responding” and stops collecting. The pack keeps reporting out-of-band - you know it is hardware before anyone starts investigating storage or the network.
Pools, volumes, controllers and physical media - related to the services they ultimately carry. The two questions the virtualisation layer cannot answer on its own.
NetApp ONTAP and E-Series · Dell PowerStore and PowerScale · Huawei OceanStor - Hitachi One - HPE Alletra - Pure Storage - IBM FlashSystem
In practice: storage reported at 82% looks comfortable. If the thin-provisioned pool underneath is at 97%, it is not - and the services on top are days from stopping. Both figures sit on related objects with a forecast of days to full, turning a capacity discussion into a purchase decision made in advance.
Fabric, switch, port and optics health, related to both ends of the path - and onward to the services that depend on that path staying up.
Brocade · Cisco MDS 9000
In practice: multipathing did its job - one of two paths went down, the service kept running, nobody raised a ticket. It has been running without redundancy ever since, one failure away from an outage. A silent loss of redundancy becomes a visible risk against the service it protects.
Switch, router and access-point health with per-interface detail, correlated against the systems and services that depend on them.
Cisco · Juniper Junos Space - Aruba · H3C · Huawei CloudEngine - Arista
In practice: one site reports intermittent failures and the network team sees nothing wrong. The pack shows errors climbing on the specific port carrying that traffic, alongside a configuration change two hours earlier. The conversation moves from opinion to timestamp.
Distributed Firewall policy built from measured traffic, with a measurable answer to the only question that matters: when is it safe to start blocking.
Check Point · Palo Alto Networks · Fortinet FortiGate · VMware NSX Distributed Firewall · F5 Advanced WAF
In practice: every policy ends with catch-all rules that allow and log whatever the detailed rules missed. A hit means traffic nobody described. Counters flat across a full observation window mean the application is ready for enforcement - the decision stops being a judgement call.
Circuit quality and node availability with SLA accounting computed on the object itself - daily, monthly and annually. When the contract review comes, the number already exists instead of being reconstructed in a spreadsheet.
Cisco Catalyst SD-WAN Manager (vManage) · Palo Alto GlobalProtect · Fortinet SD-WAN / FortiManager
In practice: a branch reports degradation and nobody can prove anything. Jitter above threshold and packet loss on the MPLS circuit for forty minutes, with the SLA clock running against the contracted class - that report is the difference between a credit claimed and a credit forgotten.
Shelf, card and port health on the transport carrying replication between datacentres - the first thing blamed when inter-site performance degrades, and the last thing anyone can actually measure.
Infinera
In practice: replication between sites slows down. Storage blames the network, the network blames storage, and the optical transport in between belongs to neither. Card temperature and threshold breaches on the same timeline as replication lag settle it in minutes instead of days.
Virtual servers, pools and members resolved down to the workloads behind them, so a degraded application resolves to which members failed and what they are running on. Certificate expiry on a virtual server becomes a threshold rather than an unplanned outage.
F5 BIG-IP - our own management pack on the iControl REST API: virtual servers, pools, members, node state and SSL certificate expiry. Built and maintained by us, under the same subscription and support as everything else in the catalogue.
In practice: two of six pool members are failing health checks and the remaining four are saturated. The application is degraded, not down - and the fix is entirely different. Because members resolve to the workloads underneath, you see immediately which hosts and datastores those two sit on.
Directory synchronisation, authentication availability and certificate lifetime as monitored objects. This is the failure that presents as an infrastructure outage and consumes the infrastructure team first.
Microsoft Entra ID / Azure AD Connect
In practice: directory sync has been failing for fourteen hours and a token signing certificate expires in three days. Both are cheap to monitor, invisible by default, and reliably produce an outage that two teams investigate before anyone thinks to check identity.
Power, cooling, environment and physical inventory - related to the racks and to the services running inside them.
SCS-Win · UptimeDC · AKCP · Geist · Kentix
In practice: a cluster slows down every afternoon because CPUs are throttling. The cause is temperature climbing in one rack since a cooling alarm that lives in a system nobody in IT logs into. On one object tree the correlation takes seconds; across two departments it takes a week.
The question backup consoles are not designed to answer: which business-critical workloads do not currently have a valid restore point.
Veeam · Commvault · Dell EMC NetWorker · Quantum DXi - IBM - HPE
In practice: a backup console reports per job - succeeded, failed, warning. What it cannot report is the workload created three weeks ago that was never added to any job. Here the gap is visible as an absence, because the inventory comes from the platform rather than the backup catalogue - so you learn which services are unprotected before you need the restore.
Application behaviour and endpoint availability related to everything underneath. This is the chain that makes the whole catalogue worth having: a symptom your users can feel at the top, a failing component at the bottom.
Flopsar · Uptime Kuma - Dynatrace
In practice: response times degrade and exceptions rise on one application instance. Follow the chain down and the server underneath reports a failing fan and a rising thermal margin. One console, one timeline - and an answer instead of a bridge call.
Cluster, node, pod and persistent-volume health related down to the physical media underneath - two worlds that normally live in separate tooling, owned by separate teams.
Sarkan / SaunaFS - VCF Sarkan Insight
In practice: a persistent volume turns read-only and the application fails. The cause is one failing disk on one node. Without that relation it is a platform-team investigation on one side and an invisible hardware fault on the other.
Subnet utilisation and allocation as a capacity metric with thresholds, sitting in the same place as compute and storage capacity rather than in a spreadsheet somebody maintains.
phpIPAM - VCF IPAM Insight
In practice: automated provisioning works, then does not, then does. The pool is at 98% and allocation only succeeds when something is released. As a threshold this is a warning weeks earlier; without it, an intermittent fault chased through automation logs.
Not device integrations - capabilities of the catalogue itself. Service models built automatically from object tags, per-tier health, stretched-cluster redundancy as a metric, agent health, and a route into the platform for anything the catalogue does not cover.
VCF Business Services Insight · VCF Universal Insight · VCF Agent Management · Stretch Performance Monitoring
In practice: service definitions maintained by hand are wrong within a quarter - something is rebuilt, a node is added, and the model quietly stops describing reality. Here the model is compared against the environment on every cycle, so the definition follows the estate instead of the other way round.
VCF Extensions ships MCP servers for VCF Operations and VCF Operations for Logs, with capabilities beyond the open-source alternatives. Your operational data becomes available to AI agents without building an integration from scratch. Diagnosing a business service takes minutes instead of hours.
Advanced features include per-request credentials and token caching, Write Guard two-phase confirmation, over 100 built-in tools and a fast Go implementation. Development is backed by unit tests, a fixture-backed end-to-end suite, a CI pipeline and a Helm chart, with 24/7 support.
Tested in production on Topthor AI Hub.
An AI agent queries VCF Operations through the MCP server: which business services are at risk, what changed before an incident, and which workloads have no valid restore point.
Bound to the systems and services you already monitor - not an isolated silo.
Vendor, model, serial number, firmware - usable for audit and warranty, not just monitoring.
Symptoms and alarms enriched with environment context, not raw traps.
Overview and alert views, ready on install.
Monthly availability, capacity and SLA evidence.
Complex calculation on multiply property and metrics from different object and endpoints across whole it stack.
“It is not the network.” “The array is fine.” Both are usually true in the tool the person is holding. Shared objects on a shared timeline replace opinion with a timestamp - and end the bridge call sooner. Teams also start seeing the layer next door, which is how expertise spreads without a training budget.
Alerts arrive with environment context instead of as raw traps, so noise from development can be suppressed by policy rather than ignored by habit. Thresholds are learned from each object's own trend. Out-of-band collection keeps reporting even when the monitored host has stopped responding.
No new platform to buy - you are extending one that is already paid for. Fewer tools means fewer renewals, administrators and training days. Service availability becomes one number per service, reported daily, monthly and annually. And capacity planning runs on a days-to-full forecast instead of an incident at 02:00.
Inventory, availability and protection status are recorded continuously across every layer - vendor, model, serial and firmware for audit and warranty, one availability figure per service, and which workloads currently have no valid restore point. When a regulator asks, the answer is a scheduled report rather than three weeks of spreadsheet work. The same record shortens incident handling, because what changed before this broke is always the first question afterwards.
| Asset | Serial | Firmware | Last restore point |
|---|---|---|---|
| srv-db-01 | J7K2M91 | 2.14 ? | 12 Mar |
| srv-db-02 | - | - | ? |
| san-sw-a | ask Marek | - | |
| array-02 | 8FN4021 | outdated? | - |
Last updated four months ago · assembled by hand across three teams
| Asset | Serial | Firmware | Last restore point |
|---|---|---|---|
| srv-db-01 | J7K2M91 | 2.61 · current | 22 Sep, 01:14 |
| srv-db-02 | L9P4T20 | 2.61 · current | 22 Sep, 01:14 |
| san-sw-a | BR7781X | 9.2.1 · current | n/a - fabric |
| array-02 | 8FN4021 | 4.0.3 · update available | 22 Sep, 00:40 |
Every object the packs discover · no assembly, no reconstruction
Devices, addresses, DNS names, applications and agents are discovered and related automatically, so what the platform knows does not depend on anyone remembering to update a diagram. Configuration and inventory work that used to consume administrator days runs in the background. And where a task is repeatable it can be scripted, scheduled and version-controlled from the same console - so the platform does not only tell you what is wrong, it can act on it.
Nobody outside IT has ever asked about a specific it component. The board asks whether the service is working, and what it costs when it is not.
A business service is composed automatically from the virtual machines that deliver it - discovered by vSphere tags, so the definition stays current as the estate changes - together with the infrastructure those machines depend on. A second tag places each object in its architectural tier - access, application, database or infrastructure - so each tier carries its own health. Services defined by hand go stale within a quarter; tag-based membership does not: tag a machine when it is provisioned and it joins the service, its tier, its dependencies and its reporting automatically.
The result answers both directions: which services are affected by this degraded array, and which components are behind this service being down. “This host has failing hardware” becomes “ERP and authentication are currently running without redundancy.”
One failing disk in one array. Two services affected - one visibly, one not at all. Neither of them is a host, and neither appears on a hardware dashboard.
Storage array SAN-02 - pool rebuilding after a disk failure
Storage array SAN-02 - one path lost, running without redundancy
All tiers healthy
All tiers healthy
Technology used by
No - the opposite. Everything here runs inside VCF Operations and depends on you having it. We extend the platform; we do not compete with it.
No. The packs sit alongside whatever you run today and add the layers it cannot relate to your business services. Alerts and data can flow onward into your existing monitoring/ITSM/SIEM systems.
In most cases no. Collection happens through management interfaces and APIs, which also means reporting continues even when the monitored system itself has stopped responding.
Days rather than months, because there is no platform to size or deploy - a pack is installed into a system already running in your environment.
Every catalogue has an edge. If a device exposes data in any scriptable form, Universal Insight turns it into objects, metrics, thresholds and dashboards in VCF Operations, without waiting for a dedicated pack to be built. If you need a dedicated management pack, write to us.
Yes. Since version 9.1, VMware vSphere Foundation is managed from VCF Operations, so the packs work there in the same way.
Physical cores licensed under VCF or VVF, read straight from VCF Operations. One subscription covers everything in the catalogue and everything released while it runs - and under 200 cores the infrastructure packs are free to run in production, with no time limit.
Thirty minutes on your infrastructure: which packs apply, what lands on which object, and what the correlation looks like for the failures you actually get.
Book a demo