Hyper-V SCOM architecture
The Hyper-V System Center Operations Manager (SCOM) product is an independent, sealed Management Pack suite that discovers supported standalone hosts and failover clusters, evaluates their health, and presents one service-oriented Distributed Application (DA) for each monitored boundary. This page is the architecture map; the linked pages define each contract in implementation detail.
The design follows Microsoft's Management Pack model: classes represent managed objects, discoveries create their instances, monitors establish health, rules collect or react to data, Run As profiles provide explicitly assigned credentials, and views, knowledge, reports, and tasks complete the operator experience. See What is in an Operations Manager management pack?.
Architecture at a glance
Design goals
- Cover supported standalone Hyper-V hosts, Windows Server Failover Clusters, and explicitly approved SCVMM/SDN-managed variants without assuming Azure connectivity.
- Make topology and ownership first-class so alerts identify the affected host, cluster, virtual machine (VM), storage, or network component.
- Produce useful health with low alert noise, explicit recovery, maintenance awareness, and no silent Healthy state when telemetry is stale.
- Keep agent, management-server, operational-database, and data-warehouse cost within documented budgets at the supported maximum scale.
- Ship operator-ready knowledge, views, diagnostics, reports, service-level objective (SLO) targets, overrides, upgrade guidance, and self-monitoring.
- Remain independently installable, upgradeable, and removable from the Azure Local SCOM product and the Microsoft Hyper-V 2019 Management Pack.
Architectural planes
Supported topology shapes
The architecture supports multiple shapes through explicit topology classification. Optional branches are discovered only when their authority and prerequisites are proven.
Network ATC is the preferred baseline for eligible Windows Server 2025 Datacenter Hyper-V clusters unless SCVMM/SDN is the selected authority. The MP must never populate overlapping network authorities into one DA branch.
Runtime data flow
Document map
| Contract | Design document |
|---|---|
| Product boundaries, requirements, and runtime planes | This page |
| Sealed MP decomposition and dependency graph | Management Pack structure |
| Classes, keys, hosting, containment, and mobility | Class and relationship model |
| Staged discovery, data sources, cookdown, and workflow placement | Discovery and workflow architecture |
| Health dimensions, state, alerting, recovery, and suppression | Health and alert architecture |
| Service roots, DA membership, and dependency rollup | Distributed Application |
| Naming, localization, knowledge, overrides, and authoring rules | Authoring standards |
| Least privilege, execution boundaries, and self-observability | Security and operability |
| Static, lab, scale, lifecycle, and release gates | Validation and release |
Non-functional requirements
| Attribute | Required design behavior | Acceptance evidence |
|---|---|---|
| Reliability | No single script failure may falsely mark the platform Healthy | Fault injection and stale-data tests |
| Scale | Workflow and data-volume budgets defined by target class and interval | Maximum-fixture performance test |
| Performance | Expensive providers queried once and shared through cookdown where safe | Workflow trace and HealthService measurements |
| Security | Local least privilege first; explicit Run As only where proven necessary | Permission matrix and negative-access tests |
| Maintainability | Stable IDs, modular fragments, product knowledge, and traceable catalog rows | Static analysis and design review |
| Upgrade safety | Stable class keys and element IDs; additive change preferred | In-place upgrade and override-preservation tests |
| Operability | Every alert explains impact, evidence, validation, remediation, and recovery | Knowledge-content quality gate |
| Portability | No Azure Local or legacy Hyper-V MP runtime dependency | Reference-graph and side-by-side import tests |
Decision status
This is a proposed implementation baseline. ADRs 0022, 0025, and 0026 are already accepted. The package, object/discovery, and health/DA refinements in ADRs 0027–0029 remain proposed until the research and lab gates provide supporting evidence. Proposed identifiers may be refined; the product boundaries and independent Hyper-V DA requirement may not.