Hyper-V Distributed Application design
The Hyper-V SCOM product ships a Hyper-V-owned Distributed Application (DA) with no dependency on the Azure Local MP. One DA represents one operational failure boundary: a failover cluster or a standalone Hyper-V host. The working root is HybridSolutionsCloud.HyperV.Deployment; ADR 0028 must accept its final namespace, stable key, and class hierarchy before authoring.
A DA organizes and presents health. It does not replace correctly targeted unit, aggregate, and dependency monitors. Microsoft describes Distributed Applications as grouped monitored objects whose overall health is calculated for service-oriented alerts, views, and reports. See Use the Authoring workspace in Operations Manager.
Service boundary rule
SCVMM management does not merge unrelated clusters or hosts into one required DA. A future fleet view can aggregate DAs through presentation content or a separately packaged integration MP.
Cluster DA
Standalone-host DA
Cluster-only objects are absent rather than Healthy placeholders in a standalone DA. The optional Management plane branch appears only when an accepted topology makes that plane operationally required.
Component contract
| DA branch | Membership | Default root impact |
|---|---|---|
| Compute and cluster | Host role or cluster, quorum, nodes, clustered roles/resources, and required virtualization services | Availability-critical; redundancy-aware for clustered hosts |
| Virtual machines | VMs classified as actionable by expected-state policy | Population-aware; intentional Off/Saved/template states do not penalize availability |
| Storage and Replica | CSVs, approved storage paths, disks, VHD/VHDX dependencies, and Replica relationships | Availability or data-integrity critical where the dependency is required |
| Networking | Physical-to-virtual topology under exactly one selected authority | Availability-critical for required paths; configuration drift can be lower impact |
| Management plane | Optional SCVMM, Network Controller, and authoritative management dependencies | Topology-specific; absent when not selected |
| Monitoring pipeline | Agent, required discovery freshness, workflow health, and required collection paths | Root-impacting so missing telemetry cannot look Healthy |
Dynamic membership
The DA is authored in XML and populated from discovered classes and typed relationships. Operators must not recreate it manually with the Distributed Application Designer.
Membership rules:
- Start from the stable DA boundary key, not an estate-wide group or name pattern.
- Traverse only product-owned or explicitly approved typed relationships.
- Give every required member exactly one canonical health path to avoid double weighting.
- Do not put the same networking object under Network ATC and SCVMM/SDN branches.
- Retain intentionally non-impacting objects in state/inventory views when useful, without adding them to an availability dependency rollup.
- Treat empty required branches as topology or monitoring-pipeline faults, not Healthy success.
Membership reconciliation
Health propagation
Worst state is a starting point, not an unconditional algorithm. Redundant hosts, VM populations, maintenance, node drain, planned migration, intentional power states, and monitoring freshness need topology-aware policies validated through lab research.
Failure examples
Operator surfaces
Every surface scopes through stable DA membership or product-owned classes. Reports and dashboards do not reimplement topology with display-name queries.
Microsoft permits service-level objectives to target a class, group, or Distributed Application. The product provides DA-oriented guidance and validates the selected target in pre-production. See Service-level objectives.
Required product artifacts
- Hyper-V-owned DA root and component-group class XML;
- deterministic dynamic membership discoveries for cluster and standalone boundaries;
- topology-aware aggregate and dependency monitors;
- localized diagram, state, alert, event, performance, and task views;
- availability and performance report/SLO guidance;
- optional SquaredUp Dashboard Server content targeting only Hyper-V classes; and
- import, empty-topology, population, move, failover, fault, recovery, scale, upgrade, coexistence, and removal tests.
Acceptance gates
Before DA authoring, the research and proposed ADRs must prove:
- stable cluster and standalone-host root keys;
- deterministic membership and execution placement across HealthServices;
- correct VM identity and membership during migration, drain, failover, rename, and removal;
- exclusive Network ATC, manual, or SCVMM/SDN authority membership;
- actionable expected-state and population rollups for VMs;
- redundancy-aware host and cluster rollups;
- Unknown/stale-data behavior and recovery;
- acceptable membership and rollup cost at supported maximum scale; and
- correct views, reports, dashboards, and SLO targeting.