Skip to main content

VMware VM power off (by name)

Last updated on

VMware VM power off (by name) is a VMware chaos fault that powers off the VMs whose names are listed in VM_NAMES for TOTAL_CHAOS_DURATION seconds, then powers them back on. The fault resolves VM names through the ESXi host enumeration and supports running targets in parallel or serial (SEQUENCE).

Use this fault to test how a workload behaves when a VMware VM disappears: whether replicas absorb the load, whether DNS/load-balancer health checks remove the VM cleanly, whether monitoring detects the outage within the alerting SLA, and whether on-call alerts fire correctly. Use this variant when working with VM names is more convenient than tracking Managed Object IDs.

Run your first experiment

If you have not configured the chaos infrastructure yet, go to Quickstart to install the chaos infrastructure and run an experiment end to end.

Use cases​

  • VM disappearance: When a VM is powered off, do replicas absorb the load inside the SLO budget?
  • Health-check fidelity: Does the load balancer detect the unhealthy VM inside the failover SLA?
  • Stateful workloads: Does a clustered stateful workload (database, message broker) recover correctly when one node disappears?

Prerequisites​

  • Kubernetes version: 1.21 or later for the chaos infrastructure cluster.
  • vCenter reachable: The chaos infrastructure can reach GOVC_URL over port 443.
  • VM names known: You know the exact name of each VM you want to power off (as it appears in vCenter).
  • vCenter chaos role: The vCenter user (GOVC_USERNAME) is mapped to the chaos role described in VMware permissions, including Virtual Machine → Interaction → Power Off and Power On.

Supported environments​

PlatformSupport status
Linux VMs hosted on vSphere / vCenterSupported
Windows VMs hosted on vSphere / vCenterSupported (this fault is OS-agnostic since it acts on the VM, not the guest)
Standalone ESXi (no vCenter)Not supported

Permissions required​

This fault is classified as Basic. Map GOVC_USERNAME to the chaos role described in VMware permissions. The role needs at minimum:

  • Virtual machine → Interaction → Power Off
  • Virtual machine → Interaction → Power On

Authentication​

TunableDescription
GOVC_URLvCenter server URL or hostname.
GOVC_USERNAMEvCenter user mapped to the chaos role.
GOVC_PASSWORDPassword for GOVC_USERNAME.
GOVC_INSECURESkip SSL certificate verification when set to true. Set to true only for self-signed certificates.

Store each credential as a text secret in Harness Secret Manager and reference the secret identifier when configuring the experiment.

Fault tunables​

Required parameters

TunableDescriptionDefault
VM_NAMESComma-separated list of target VM names as they appear in vCenter.(required)

Chaos parameters

TunableDescriptionDefault
TOTAL_CHAOS_DURATIONTotal duration of the fault in seconds. The VMs stay powered off for this period.30
CHAOS_INTERVALDelay in seconds between iterations when running for more than one cycle.30
SEQUENCEparallel (power off all listed VMs at once) or serial (power off one VM at a time).parallel
RAMP_TIMEWait period in seconds before and after the fault. Go to ramp time to read how it is applied.0

vCenter authentication

TunableDescriptionDefault
GOVC_URLvCenter server URL or hostname.""
GOVC_USERNAMEvCenter user mapped to the chaos role.""
GOVC_PASSWORDPassword for GOVC_USERNAME.""
GOVC_INSECURESkip SSL certificate verification when set to true.true

Tunables that apply to every fault are documented in common tunables for all faults.

Fault execution in brief​

Authenticates to vCenter (GOVC_URL), resolves each name in VM_NAMES to a VM, powers each VM off (in parallel or serial per SEQUENCE), waits TOTAL_CHAOS_DURATION seconds, then powers them back on.

Expected behavior during fault execution​

  • Each VM in VM_NAMES transitions to poweredOff state.
  • Workloads on those VMs become unreachable; replicas (if any) absorb the load.
  • After the duration ends, each VM is powered back on and the guest OS boots up.
When the fault ends

The chaos pod powers each VM back on through vCenter. Guest OS boot time depends on the workload and is not included in TOTAL_CHAOS_DURATION.

Signals to watch​

  • VM power state: Use a command probe running govc vm.info <vm-name> and assert the state.
  • Workload health: Use an HTTP probe on a user-visible endpoint served by other replicas.

Verify the fault execution effect​

  1. Inspect VM power state in vCenter.

    In vCenter UI, find each VM by name. The state should be Powered Off during the chaos window and Powered On afterwards.

  2. Confirm guest OS recovery.

    After the fault ends, SSH (or RDP) into each VM to confirm the OS booted and the workload restarted.

Recovery and cleanup​

  • End of duration: The chaos pod powers each VM back on.
  • Abort: Stopping the experiment from Chaos Studio also triggers power-on.
  • Manual recovery: If a VM remains powered off, power it on from vCenter UI or via govc vm.power -on <vm-name>.

Limitations​

  • Name uniqueness: VM names must be unique inside the vCenter inventory. If duplicate names exist, behavior is undefined; use VMware VM power off (by MOID) instead.
  • Boot time not counted: Guest OS boot time after power-on is not included in the duration.
  • Hard power off: This is a hardware-level power off, not a graceful guest shutdown. Workloads must tolerate sudden disappearance.

Troubleshooting​

VMware VM power off by name fails with VM not found in Harness Chaos Engineering

VM_NAMES must match the names exactly as they appear in vCenter. Run govc find -type m to enumerate VM names, then update VM_NAMES.

VMware VM power off by name fails with SSL certificate verification failed

If your vCenter uses a self-signed certificate, set GOVC_INSECURE=true. For production, trust the vCenter CA in the chaos infrastructure image instead.