TL;DR: The article shows how Zabbix can monitor KVM hosts, guest VMs, and related services using standard agents, proxy layouts, and discovery rules, but it also makes clear that host-level monitoring alone does not guarantee coverage of guest state or isolate failures inside the virtualisation stack, according to Cybertrust Japan. For practitioners, the real issue is governance of visibility boundaries, not just whether a monitoring tool is installed.
At a glance
What this is: Cybertrust Japan explains how Zabbix can monitor KVM environments while also showing that host monitoring does not by itself ensure full guest and workload visibility.
Why it matters: This matters to infrastructure, IAM, and operations teams because monitoring gaps in virtualized estates can hide service impact, blur responsibility, and weaken control over the systems that support identity and workload services.
Context
KVM monitoring is not just a tooling question, it is a governance problem about what level of the stack is actually being observed. In virtualized environments, host health can look normal while guest workloads, resource contention, or per-VM failure conditions remain invisible, which creates a visibility gap for operations and security teams. The identity angle is indirect but real, because many core services now run inside virtual machines that host authentication, access, and automation components.
Cybertrust Japan’s article frames that problem through Zabbix configuration patterns, including host-level monitoring, proxies, agent deployment, and discovery-based registration. The practical point is that monitoring boundaries need to match the operational boundary of the service, not just the boundary of the underlying hypervisor. That is typical in modern virtualized estates, where observability often lags behind architecture unless teams deliberately map coverage to each layer.
Key questions
Q: What breaks when teams rely on host monitoring alone in KVM environments?
A: Host-only monitoring hides guest-side failures, application degradation, and resource contention that live inside the virtual machine boundary. It can also create false confidence when the host is healthy but a guest is stalled or under-provisioned. Effective virtualisation monitoring must separate host health from guest health and treat each as a distinct failure domain.
Q: Why do guest VMs need separate telemetry from the KVM host?
A: Guest VMs need separate telemetry because host metrics cannot reliably reveal what is happening inside each operating system. A VM can be alive but unhealthy, overloaded, or losing service-specific functionality while the host remains nominal. Separate telemetry lets operators isolate faults faster and avoid mistaking platform stability for workload stability.
Q: How can security and operations teams tell if discovery-based monitoring is drifting?
A: Drift appears when the monitoring inventory no longer matches the virtualization inventory. Common signs include newly created VMs with no checks, retired guests that still appear active, and inconsistent coverage after template changes. The test is simple: every production VM should be accounted for in both inventories and tied to an owner.
Q: How should teams design monitoring for virtualized services that support identity workloads?
A: Teams should monitor the host, the guest, and the service separately, because identity-related workloads need both infrastructure and application visibility. If authentication or automation components run inside VMs, host monitoring alone cannot prove service health. A layered design reduces blind spots and gives incident responders a clearer path to isolate faults.
Technical breakdown
Why host monitoring is not enough in KVM environments
KVM separates the hypervisor layer from guest operating systems, so a healthy host does not automatically mean each VM is healthy. Host-level telemetry can show CPU, memory, and service status on the Linux system that runs KVM, but it may miss per-guest contention, degraded services inside a VM, or failures that never surface cleanly at the host boundary. That is why a monitoring model based only on the host creates blind spots. In practice, the architecture requires visibility at both the virtualization layer and the guest layer if teams want meaningful operational assurance.
Practical implication: Track guest-level signals separately from host metrics so a healthy hypervisor does not mask failed workloads.
How Zabbix agent and proxy placement changes visibility
Zabbix can collect data from the KVM host, the guest OS, and related services using agents, agentless checks, and proxy layouts. The placement decision matters because the collection path changes what can be observed and how resilient the monitoring design is. A proxy can localize collection and reduce dependency on a central server, while guest agents expose workload-specific metrics that the host cannot infer. This is not only an implementation detail. It defines the trust boundary of the monitoring design and determines whether the platform is observing the stack from outside, inside, or both.
Practical implication: Place collection points so every critical layer is measured from the right side of the boundary, not just from the central server.
Discovery and templates turn monitoring into governance
Discovery rules and templates reduce manual setup, but they also encode assumptions about what counts as a monitored asset. In a KVM estate, that means the monitoring programme can silently drift if guest creation, naming, or registration is not aligned with discovery logic. Once that happens, coverage becomes uneven and operators may think they are watching the full estate when they are only watching the parts that fit the template. Governance therefore depends on continuous reconciliation between the virtualization inventory and the monitoring inventory, especially where VMs are added, removed, or repurposed frequently.
Practical implication: Reconcile discovered VMs against the actual virtualization inventory so monitoring coverage stays complete as the environment changes.
Threat narrative
Attacker objective: The practical objective is not attacker-led compromise but operational concealment, where important failures remain hidden long enough to widen impact across the virtualized environment.
- Entry begins at the virtualization layer when host-only visibility leaves guest workloads and per-VM failures outside the operator's field of view.
- Escalation occurs when teams treat host health as a proxy for service health and miss the layered dependencies inside the virtual machine estate.
- Impact is delayed detection of workload failure, which can extend service disruption across multiple VMs before the real fault is isolated.
Breaches seen in the wild
- CISA Private-CISA GitHub leak 2026: A CISA contractor's public GitHub repo exposed AWS GovCloud admin keys, Artifactory credentials and plaintext passwords for six months.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Virtualization monitoring exposes a visibility governance gap: organisations often assume host telemetry equals workload assurance, but KVM breaks that assumption. Guest state, per-VM resource pressure, and service failures can remain hidden if the monitoring model stops at the hypervisor boundary. The practical conclusion is that observability policy must define which layer owns which signal, or coverage will be partial by default.
Monitoring coverage is a control boundary, not a dashboard feature: this article shows that discovery rules, proxy placement, and agent deployment decide what is actually governed. That makes monitoring inventory part of operational control, not just reporting. For teams running identity, automation, or platform services inside VMs, incomplete visibility can become an availability and accountability problem as much as a technical one.
KVM creates a split-brain risk between infrastructure and service ownership: the host team can believe the environment is stable while application or platform teams see local failure inside guests. That mismatch is where incident escalation slows and root cause ownership blurs. The lesson for practitioners is to align the monitoring model with the service model, especially where critical authentication or automation components run inside virtual machines.
Discovery-driven monitoring needs a reconciliation discipline: automatic host registration helps scale, but it also creates a naming and inventory dependency that can drift over time. If the virtualization inventory and the monitoring inventory are not reconciled, the estate becomes partly observable and partly assumed. Practitioners should treat that assumption gap as a governance defect, not a tooling inconvenience.
Virtualization visibility should be assessed as a resilience control: the real question is not whether Zabbix can watch KVM, but whether the organisation can prove that every important guest workload is observable under failure conditions. That is a resilience requirement tied to service continuity, and teams should verify it the same way they would test backup or recovery coverage.
What this signals
Layered observability is the real control objective: a virtualized environment should be monitored as a stack of distinct trust and failure boundaries, not as a single machine. For practitioners, that means the monitoring architecture must prove visibility into host health, guest health, and service health separately or the estate will appear healthier than it is.
Virtualization governance fails when discovery is treated as coverage: automatic registration can improve scale, but it does not guarantee completeness. The programme signal is clear: if the authoritative VM inventory and the monitoring inventory are not continuously reconciled, the gap becomes an operational risk rather than a tooling issue.
For practitioners
- Define monitoring ownership by layer Map host, guest, proxy, and service telemetry to explicit owners so each failure mode has a clear monitoring control point.
- Add guest-level checks for critical VMs Do not rely on KVM host health alone for production services; attach agent or equivalent checks to the workloads that actually carry business risk.
- Reconcile discovery with virtualization inventory Compare automatically discovered hosts and guests against the authoritative VM list on a recurring basis so hidden or orphaned systems do not escape coverage.
- Validate proxy placement against outage scenarios Test whether monitoring still sees guest and service failures when the central path is degraded, because proxy design determines observability continuity.
Key takeaways
- Host-level monitoring in KVM environments can miss guest-specific failures, so visibility must extend beyond the hypervisor boundary.
- The central governance problem is not whether a monitoring platform is installed, but whether it can prove coverage of the workloads that matter.
- Practitioners should align discovery, inventory reconciliation, and guest telemetry so monitoring reflects the real service architecture.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack surface, NIST CSF 2.0 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Anomalies and Events | KVM observability depends on monitoring the right layers for anomalous host and guest conditions. |
| PR.AA-05 — Access Permissions, Entitlements and Authorizations | Virtualization monitoring depends on controlled access to hosts, guests, and discovery surfaces. | |
| Recommendation — Map KVM host and guest telemetry to DE.CM-01 and verify each critical layer is actually monitored. Apply PR.AA-05 to restrict who can alter discovery, agent placement, and virtual machine monitoring scope. | ||
| CIS Controls v8 | CIS-5 — Account Management | KVM estates rely on managed accounts for hosts, guests, and monitoring tooling. |
| Recommendation — Use CIS-5 to keep host, guest, and monitoring accounts aligned with ownership and lifecycle changes. | ||
| ISO/IEC 27001:2022 | A.8.15 — Logging | Logging is central to proving visibility across host and guest layers in virtualized environments. |
| Recommendation — Apply A.8.15 to ensure logs from hosts and guests support fault isolation and coverage checks. | ||
| MITRE ATT&CK | TA0007 — Discovery | The article’s discovery-based monitoring model depends on accurate asset discovery and inventory matching. |
| Recommendation — Use TA0007 to hunt for asset-discovery gaps that leave virtual machines unmonitored. | ||
Key terms
- Virtualization governance gap: The mismatch between what the hypervisor can prove and what the business assumes is being observed. In practice, it appears when host-level monitoring is treated as complete coverage even though guest workloads, service health, and per-VM failures still need their own controls.
- Session-level telemetry: Security data captured from inside the browser session, such as logins, clipboard events, file transfers, extension changes, and OAuth consents. It is more useful than alert-only reporting because it preserves the context needed to explain how identity and data risks developed.
- Discovery-based monitoring: A monitoring approach that automatically finds assets and applies templates or checks to them. It scales well, but it can drift if discovery rules, naming, or inventory records are not reconciled with the actual virtualized environment.
- Inventory Reconciliation: Inventory reconciliation is the process of comparing discovered assets and configurations with the authoritative record until discrepancies are resolved. It is essential for digital twins because a model built on stale or partial inventory cannot reliably represent operational reality.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management in the context of modern security operations. It is a strong fit for practitioners who need to connect identity controls to the infrastructure that carries critical services.
Published by the NHIMG editorial team on July 12, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org