> 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/unable-to-create-clone-volumes-from-source-volume.md).

# Unable to Create Clone Volumes From Source Volume

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

The VM shows an attached bootable volume in the PCD UI. However, the actual disk file being used by the hypervisor does **not** match the volume registered in the storage service.

This resulted in Failure when creating a clone of the volume present in the Cinder but without having a valid backend file.

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

* Private Cloud Director Virtualization - v2025.6 and Higher
* Private Cloud Director Kubernetes – v2025.6 and Higher
* Self-Hosted Private Cloud Director Virtualization - v2025.6 and Higher
* Self-Hosted Private Cloud Director Kubernetes - v2025.6 and Higher
* Component - Block Storage

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

This issue is caused by a metadata inconsistency between the Compute service and Block storage service which likely occurred during a failed volume operation. The file mapped for `/dev/vda` bootable volume as per `virsh dumpxml` does not exist in Block storage, and therefore is not manageable by Block Storage APIs.

Meanwhile, the Cinder-registered volume has no backend file present on the Shared mount used for tintri, confirming metadata drift between Compute Service and Block storage service .

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

The following command outputs confirm the mismatch between the control plane metadata and the data plane reality.

1. **Verify the Volume Status:** This shows that the reported boot volume is `in-use`, but a search for the actual disk file will fail in the Block storage backend:

   ```
   openstack volume show <VOLUME_UUID_1> --fit
   +--------------------------------+----------------+
   | Field                          | Value          |
   +--------------------------------+----------------+
   | name                           | [VOLUME_NAME]  |
   | status                         | in-use         |
   +--------------------------------+----------------+
   ```
2. **Inspect the VM XML on the Hypervisor:** Log in to the compute host where the VM is running and inspect the VM domain XML. This reveals the actual disk file in use. \
   **Note:** The output shows the *serial* matching the Cinder-reported ID, but the *source file* uses the unmanaged ID

   <pre class="language-bash" data-title="Hypervisor Host"><code class="lang-bash">$ sudo virsh dumpxml &#x3C;VM_UUID> | grep -B5 -i volume
   &#x3C;...>
     &#x3C;disk type='file' device='disk'>
       &#x3C;driver name='qemu' type='raw' cache='none' io='native'/>
       &#x3C;source file='/path/to/volume-&#x3C;VOLUME_UUID_2>' index='2'/>
       &#x3C;backingStore/>
       &#x3C;target dev='vda' bus='virtio'/>
   &#x3C;...>
   </code></pre>
3. **Confirm the Actual Volume is Unmanaged:** Searching for the volume ID found in the `virsh dumpxml` confirms that **Block storage service** does not know about this active disk.

   ```bash
   $ openstack volume show <VOLUME_UUID_2> --fit
   No volume with a name or ID of '<VOLUME_UUID_2>' exists.
   ```
4. **Check the Disk Format:** Inspecting the file on the hypervisor confirms it is a `raw` disk

   <pre class="language-bash" data-title=""><code class="lang-bash">$ qemu-img info /path/to/volume-&#x3C;VOLUME_UUID_2>
   volume-&#x3C;VOLUME_UUID_2>
   image: /path/to/volume-&#x3C;VOLUME_UUID_2>
   file format: raw
   virtual size: 160 GiB (171798691840 bytes)
   disk size: 162 GiB
   </code></pre>

The Nova domain XML on the compute host points to the correct, functional disk file (ID **\<VOLUME\_UUID\_2>**), but that volume is missing from the **Cinder** database, leaving it an **unmanaged** resource. The original Cinder volume record **\<VOLUME\_UUID\_1>** is a ghost record with no physical file, which is why attempts to clone or snapshot fail.

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

The resolution involves directly recovering the active disk file, converting it to a standard image format, and creating a new Cinder-managed volume and instance from that recovered image.

1. On the compute hypervisor, copy the active, **raw** disk file to a temporary location.

   ```bash
   $ cp /path/to/volume-<VOLUME_UUID_2>  /tmp/volume-<VOLUME_UUID_2>.raw
   ```
2. Convert the **raw** disk image to the recommended **qcow2** format using **qemu-img** to save space and enable sparse image features.

   ```bash
   $ qemu-img convert -f raw -O qcow2 /tmp/volume-<VOLUME_UUID_2>.raw /tmp/<VOLUME_UUID_2>.qcow2
   ```
3. Upload the recovered *.qcow2* file to **Image Library**.

   ```bash
   $ openstack image create --disk-format qcow2 --container-format bare \
   --property os_type='windows' \
   --file /tmp/<VOLUME_UUID_2>.qcow2 \
   "<IMAGE_NAME>"
   ```
4. Launch a new instance using the newly created **Image Library Service** image to create a boot volume.
5. Verify that the new instance, boots successfully and operates normally.

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

* This recovery method bypasses the corrupted Block Storage metadata by extracting the live, functional disk data from the hypervisor.
* The cleanup of the original instance and its associated volume records is required to fully resolve the metadata corruption.
* If the original instance has a second attached volume, the secondary non-bootable volume should be carefully detached and re-attached to the recovered instance if it contains user data.


---

# 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 dynamically 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/unable-to-create-clone-volumes-from-source-volume.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 `build a script that syncs our docs to a CMS` 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.