KVM and Proxmox, evidence beyond vCenter.

Red Hat audit teams build their evidence playbook around the most common hypervisor in the field, which is VMware. When the customer estate runs KVM, libvirt managed RHEL hypervisors, or Proxmox VE, the audit team's opening evidence request frequently arrives in language that asks for the equivalent of a vCenter export. The equivalent does not exist in the same form; KVM exposes topology through virsh and libvirt APIs, and Proxmox exposes it through the PVE cluster API and the web management interface. The defended response produces evidence in the form the hypervisor actually emits and explains the mapping in an accompanying memorandum.1

The practice's reading is that the audit team's vCenter shaped request is partly an artifact of habit and partly an attempt to push the customer into producing more evidence than the audit clause permits. The defended response does not contort the evidence to fit a vCenter shape; it produces what the hypervisor actually emits and constrains scope by the audit clause. The parent service note on Red Hat audit defense treats the general evidence posture; the present note treats the non VMware hypervisor application.

KVM on libvirt managed RHEL hypervisors exposes inventory through the virsh command and the libvirt API. virsh list, virsh nodeinfo, and virsh dominfo provide host CPU topology, virtual machine state, virtual machine CPU allocation, and guest operating system identification where the guest has reported it. Aggregating virsh output across a fleet of libvirt managed hypervisors produces a structured CSV or JSON inventory that the audit team can consume.

The libvirt inventory does not have the rich field set that vCenter produces. The audit team that asks for fields KVM does not expose is asking for evidence that does not exist; the defended response explains the limitation and produces what the platform actually provides. RHEL hypervisor counting under socket pair entitlements depends on host CPU socket count, which virsh nodeinfo provides directly. The companion note on VMware vCenter inventory as evidence treats the contrast.

Proxmox VE exposes cluster topology through the PVE API and the pvesh command line. Cluster status, node count, virtual machine count per node, virtual machine CPU and memory configuration, and guest type identification are accessible through the API. Proxmox VE clusters frequently mix RHEL guests, other Linux guests, and Windows guests; the defended response filters the inventory to the RHEL guests that are actually in scope.

Proxmox is a frequent destination for customers leaving VMware after the Broadcom era pricing changes. Audit teams encountering Proxmox in customer estates for the first time may produce evidence requests that misunderstand the platform's topology; the defended response invests in the memorandum that explains how Proxmox organises nodes, clusters, and storage, and how RHEL guests on Proxmox map to socket pair or other entitlement models. The companion note on RHEL virtual datacenter deep dive treats the counting models in depth.2

A subset of audit defenses encounter the legacy Red Hat Virtualization platform, now end of life, and oVirt installations that ran on it. The RHV engine SDK and the oVirt API produce structured inventory that maps cleanly to host and VM counts. The wrinkle in RHV evidence is that the audit team frequently treats RHV hosts as ordinary RHEL hosts when the entitlement structure was actually different. The defended response produces the engine export and references the RHV specific entitlement terms.

RHV customers are typically in active migration to OpenShift Virtualization or Proxmox or a non Red Hat hypervisor. The audit posture sits at the intersection of an end of life platform and a migration in flight; the defended response treats the migration trajectory as part of the framework. The companion note on RHV end of life planning treats the platform side; the audit application is that the platform's end of life status frequently constrains the audit team's reach.

The bridge between non VMware evidence and Red Hat entitlement counting is the accompanying memorandum. The memorandum explains how the hypervisor's host concept maps to the audit clause's host concept, how the hypervisor's CPU socket count maps to socket pair entitlements where relevant, and how the hypervisor's guest enumeration maps to virtual machine counting. The audit team that reads the memorandum first interprets the evidence correctly; the audit team that reads only the raw export will frequently misinterpret it.

The defended production also addresses the cluster boundary question. KVM and Proxmox clusters are organised differently from VMware clusters; the defended response makes the cluster boundary explicit and identifies which entitlement model applies at the cluster level. The companion note on audit clause anatomy and negotiation treats the contractual scope that wraps all evidence productions.

OpenShift Virtualization (KubeVirt) exposes virtual machine inventory through Kubernetes Custom Resources and the OpenShift API. The audit team that asks for vCenter inventory on an OpenShift Virtualization estate is asking for evidence that does not exist in that form. The defended response produces OpenShift VM custom resource lists, node lists, and namespace structure. The cross link into Lane 11 on OpenShift edge deployment licensing treats one application; the broader OpenShift Virtualization audit story is a separate evidence track from VMware and from KVM.

The practice begins non VMware evidence engagement by identifying the platform, the inventory tools that platform exposes, and the entitlement model that applies. The defended production then assembles the platform native inventory and the mapping memorandum. The audit team's expectation of a vCenter shaped production is corrected in the first written reply; the memorandum explains the platform and the mapping in the language the audit team needs. The parent practice note on RHEL licensing treats the product side that the hypervisor evidence feeds into.

Across non VMware audits in the practice's trailing twelve months, defenses that produced platform native evidence with mapping memoranda settled at materially lower percentages of the initial Red Hat finding than defenses that attempted to contort their evidence into a vCenter shape. If the audit notice asks for hypervisor inventory and the estate is not VMware, the first useful hour is a call with the desk. The companion notes on vCenter host inventory, subscription manager output, and audit clause anatomy treat parallel pieces of the evidence picture.

Preparing a response? The practice keeps a one-page Red Hat audit response checklist — what to acknowledge, what to preserve, and what not to volunteer in the first fourteen days after the letter arrives.