> For the complete documentation index, see [llms.txt](https://platform9.com/kb/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://platform9.com/kb/pcd/gpu/windows-gpu-vm-stops-automatically-after-deployment-due-to-guest-acpi-standby-policy.md).

# Windows GPU VM Stops Automatically After Deployment Due to Guest ACPI Standby Policy

## Problem

A Windows virtual machine deployed with a vGPU profile stops automatically within minutes to hours of deployment or after a Windows Update reboot, with no user-initiated action. The VM transitions to a `SHUTOFF` state and the Compute Service reports the instance as stopped. The issue is intermittent in appearance — the VM is running immediately after deployment but stops silently once the guest becomes idle.

## Environment

* Private Cloud Director Virtualization - All versions
* Self-Hosted Private Cloud Director Virtualization - All versions
* Component: Compute Service, vGPU (NVIDIA L40S or equivalent SR-IOV vGPU profile)
* Guest OS: Windows 11 (any build) or Windows Server

## Cause

The Windows guest has ACPI S3 deep sleep (standby) enabled in its power plan. When the guest sits idle beyond the configured standby timeout — the Windows default is **15 minutes on AC power** — the guest silently transitions to ACPI S3 sleep state.

The Compute Service periodically synchronises the guest power state with the hypervisor. When the hypervisor reports `vm_power_state=7` (libvirt `PMSUSPENDED`), the platform interprets this as an unexpected suspension and automatically calls the instance stop API. The VM is then forcibly shut down by the hypervisor and transitions to `SHUTOFF` state in the platform.

This is expected and documented platform behaviour — the platform treats an unsolicited guest suspend as an anomaly and stops the instance to return it to a consistent state. The root cause is the Windows guest power policy, not a platform defect.

## Diagnostics

{% stepper %}
{% step %}
**Step 1 — Check the VM event log for unexpected stop events**

Retrieve the event history for the stopped VM. Look for a `stop` action with no corresponding user-initiated request.

{% code title="OpenStack CLI" %}

```bash
$ openstack server event list <VM_UUID>
```

{% endcode %}

{% code title="Sample Output" %}

```bash
+------------------------------------------+--------------------------------------+--------+----------------------------+
| Request ID                               | Server ID                            | Action | Start Time                 |
+------------------------------------------+--------------------------------------+--------+----------------------------+
| [REQ_UUID]                               | [VM_UUID]                            | stop   | [TIMESTAMP]                |
| [REQ_UUID]                               | [VM_UUID]                            | start  | [TIMESTAMP]                |
+------------------------------------------+--------------------------------------+--------+----------------------------+
```

{% endcode %}

A `stop` action that appears without a preceding user-initiated action, shortly after deployment or after a Windows Update reboot, is consistent with this issue.
{% endstep %}

{% step %}
**Step 2 — Confirm PMSUSPENDED state in the Hostagent log**

On the compute host where the VM was running, search the Hostagent log for the `PMSUSPENDED` power state detection.

{% code title="Compute Host" %}

```bash
$ sudo grep -i "<VM_UUID>" /var/log/pf9/ostackhost.log | grep -iE "power_state|suspended|pmsuspend"
```

{% endcode %}

{% code title="Sample Output" %}

```bash
[TIMESTAMP] INFO nova.compute.manager [REQ_UUID] [VM_UUID] During _sync_instance_power_state the DB power_state (1) does not match the vm_power_state from the hypervisor (7). Updating power_state in the DB to match the hypervisor.
[TIMESTAMP] WARNING nova.compute.manager [REQ_UUID] [VM_UUID] Instance is suspended unexpectedly. Calling the stop API.
```

{% endcode %}

`vm_power_state=7` is the libvirt `PMSUSPENDED` state. The warning `Instance is suspended unexpectedly. Calling the stop API.` confirms the platform stopped the VM in response to the guest entering ACPI sleep.
{% endstep %}

{% step %}
**Step 3 — Verify the Windows guest power policy (inside the VM while running)**

Start the VM and connect to the Windows guest before the standby timeout elapses. Run the following command in an elevated Command Prompt or PowerShell to confirm the current standby timeout values.

{% code title="Inside VM" %}

```powershell
powercfg /query SCHEME_CURRENT SUB_SLEEP STANDBYIDLE
```

{% endcode %}

{% code title="Sample Output" %}

```
Power Scheme GUID: [SCHEME_UUID]  (Balanced)
  Power Setting GUID: [SETTING_UUID]  (Sleep after)
      Current AC Power Setting Index: 0x00000384
      Current DC Power Setting Index: 0x00000258
```

{% endcode %}

`0x00000384` = 900 seconds = 15 minutes (Windows default AC timeout). `0x00000258` = 600 seconds = 10 minutes (Windows default DC timeout).

Any non-zero value means the guest will eventually enter standby and trigger the platform stop. A value of `0x00000000` means standby is disabled.

Also confirm whether S3 sleep state is available:

{% code title="Inside VM" %}

```powershell
powercfg /a
```

{% endcode %}

{% code title="Sample Output" %}

```
The following sleep states are available on this system:
    Standby (S3)
    Hibernate
```

{% endcode %}

If `Standby (S3)` appears as available, the VM can enter ACPI sleep.
{% endstep %}
{% endstepper %}

## Workaround

### **Method 1 — Disable Standby on the Running VM (Immediate Fix)**

Connect to the Windows guest and run the following commands in an elevated Command Prompt or PowerShell to disable all sleep-related timeouts immediately.

{% hint style="warning" %}
These commands modify the active power plan settings. Confirm the correct power scheme is active with `powercfg /list` and `powercfg /getactivescheme` before proceeding if the VM uses a custom power plan.
{% endhint %}

{% stepper %}
{% step %}
**Step 1 — Disable standby and hibernate timeouts**

{% code title="Inside VM" %}

```powershell
powercfg /change standby-timeout-ac 0
powercfg /change standby-timeout-dc 0
powercfg /change monitor-timeout-ac 0
powercfg /change monitor-timeout-dc 0
powercfg /hibernate off
```

{% endcode %}

{% code title="Sample Output" %}

```
(no output on success)
```

{% endcode %}
{% endstep %}

{% step %}
**Step 2 — Confirm the timeouts are now zero**

{% code title="Inside VM" %}

```powershell
powercfg /query SCHEME_CURRENT SUB_SLEEP STANDBYIDLE
```

{% endcode %}

{% code title="Sample Output" %}

```
      Current AC Power Setting Index: 0x00000000
      Current DC Power Setting Index: 0x00000000
```

{% endcode %}

Both AC and DC values must show `0x00000000`. The VM will no longer enter standby and the platform will not stop the instance due to an unexpected suspension.
{% endstep %}
{% endstepper %}

### **Method 2 — Enforce via Group Policy (Fleet-Wide Fix)**

For environments where multiple GPU VMs are deployed from the same image or are domain-joined, enforce the sleep policy through Group Policy to prevent recurrence across the fleet.

Apply the following Group Policy setting on the domain controller or local policy editor:

```
Computer Configuration
  → Administrative Templates
    → System
      → Power Management
        → Sleep Settings
          → Specify the system sleep timeout (plugged in): 0
          → Specify the system sleep timeout (on battery): 0
```

Setting both values to `0` disables standby system-wide and survives reboots, Windows Updates, and power plan resets.

### **Method 3 — Bake into the Windows Golden Image (Permanent Prevention)**

To prevent the issue on all future GPU VM deployments, disable standby in the Windows base image before deploying new VMs.

{% stepper %}
{% step %}
**Step 1 — Boot the golden image VM and disable standby**

Connect to the Windows source image VM and run the same commands as Method 1:

{% code title="Inside VM" %}

```powershell
powercfg /change standby-timeout-ac 0
powercfg /change standby-timeout-dc 0
powercfg /change monitor-timeout-ac 0
powercfg /change monitor-timeout-dc 0
powercfg /hibernate off
```

{% endcode %}

{% code title="Sample Output" %}

```
(no output on success)
```

{% endcode %}
{% endstep %}

{% step %}
**Step 2 — Verify the settings are applied**

{% code title="Inside VM" %}

```powershell
powercfg /query SCHEME_CURRENT SUB_SLEEP STANDBYIDLE
```

{% endcode %}

{% code title="Sample Output" %}

```
      Current AC Power Setting Index: 0x00000000
      Current DC Power Setting Index: 0x00000000
```

{% endcode %}
{% endstep %}

{% step %}
**Step 3 — Snapshot or re-image from this golden image**

Shut down the VM cleanly, create a new snapshot or volume image, and use this updated image as the base for all future GPU VM deployments. All VMs created from this image will have standby disabled from first boot.
{% endstep %}
{% endstepper %}

## Resolution

This is expected platform behaviour — no platform fix is required. The resolution is to disable ACPI standby in the Windows guest power policy using one or more of the methods above. Applying Method 3 (golden image update) is the permanent fix for environments deploying GPU VMs at scale.

## Additional Information

**Related articles:**

* [NVIDIA vGPU Guest Driver Installation Causes BSOD on Domain-Joined Windows VM](/kb/pcd/gpu/nvidia-vgpu-guest-driver-installation-causes-bsod-on-domain-joined-windows-vm.md) — covers `nvlddmkm.sys` BSOD stop codes `0x50` and `0xD1` during NVIDIA guest driver installation, caused by domain Group Policy interference. Applicable when a Windows GPU VM BSODs during initial driver setup rather than stopping silently.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://platform9.com/kb/pcd/gpu/windows-gpu-vm-stops-automatically-after-deployment-due-to-guest-acpi-standby-policy.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.