> 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/storage/vm-evacuation-fails-due-to-volume-stuck-in-attaching-state.md).

# VM Evacuation Fails Due to Volume Stuck in attaching State

## Problem <a href="#problem" id="problem"></a>

Evacuation of a VM fails, leaving the instance in `ERROR` state. One of the attached volumes remains stuck in the `attaching` state, preventing Nova from completing the evacuation. The VM cannot boot because the required volume is not successfully attached.

## Environment <a href="#environment" id="environment"></a>

* Storage Service
* Private Cloud Director Virtualization - v2025.4 and Higher
* Private Cloud Director Kubernetes – v2025.4 and Higher
* Self-Hosted Private Cloud Director Virtualization - v2025.4 and Higher
* Self-Hosted Private Cloud Director Kubernetes - v2025.4 and Higher
* Component: Storage Service

## Cause <a href="#cause" id="cause"></a>

The evacuation fails because one of the attached volumes is stuck in the `attaching` state. During evacuation, Nova requests volume service to attach all required volumes to the target compute host. If any volume does not reach `available` or `downloading` state and remains stuck, Nova cannot proceed with booting the instance, resulting in `ERROR` state.

### Diagnostics <a href="#diagnostics" id="diagnostics"></a>

* **Check the VM state:**

  ```bash
  $ openstack server show <VM_ID>
  ```

The status field shows ERROR and  `volumes_attached` lists all volumes; one may be stuck in `attaching` state.<br>

* **Check volume status**:

  ```bash
  $ openstack volume show <VOLUME_ID>
  ```

Events show `Invalid volume` error for volumes stuck in `attaching` <br>

* **Verify volume attachment attempts**:

  ```bash
  $ openstack server event show <VM_ID> <REQUEST_ID>
  ```

Shows traceback with `Invalid volume` due to `attaching` state

## Resolution <a href="#resolution" id="resolution"></a>

1. Reset volumes to `available`&#x20;

   ```
   $ openstack volume set --state available <BOOT_VOLUME_ID>
   $ openstack volume set --state available <VOLUME_ID_1>
   $ openstack volume set --state available <VOLUME_ID_2>
   $ openstack volume set --state available <VOLUME_ID_3>
   $ openstack volume set --state available <STUCK_VOLUME_ID>
   ```
2. Recreate the VM from the bootable volume

   ```
   $ openstack server create \
     --flavor <FLAVOR_ID> \
     --volume <BOOT_VOLUME_ID> \
     --nic net-id=<NETWORK_ID> \
     --availability-zone nova \
     <NEW_VM_NAME>
   ```
3. Reattach all data volumes

   ```
   $ openstack server add volume <NEW_VM_ID> <VOLUME_ID_1>
   $ openstack server add volume <NEW_VM_ID> <VOLUME_ID_2>
   $ openstack server add volume <NEW_VM_ID> <VOLUME_ID_3>
   $ openstack server add volume <NEW_VM_ID> <STUCK_VOLUME_ID>
   ```

## Validation

1. Confirm VM status is ACTIVE:

   ```bash
   $ openstack server show <NEW_VM_ID> | grep status
   ```
2. Log into the guest OS and verify:
   1. VM boots successfully
   2. All data volumes are visible and mounted correctly

### Additional Information <a href="#additional-information" id="additional-information"></a>

* This issue occurs when Cinder volumes remain in transitional states (`attaching`/`reserved`) due to incomplete detach/attach operations.
* Using `openstack volume set --state available` resets the volumes safely when no I/O is in progress.
* Preventive measures include monitoring volume states during evacuation and ensuring no stale Block Device Mappings exist in Nova for critical volumes.
* Similar issues may occur if live migration or evacuations are attempted while volumes are actively performing operations.


---

# 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/storage/vm-evacuation-fails-due-to-volume-stuck-in-attaching-state.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.