> For the complete documentation index, see [llms.txt](https://docs.platform9.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.platform9.com/private-cloud-director/copy-of-2026.4/virtualized-clusters/troubleshooting-and-log-files/hotplug-boot-from-volume-live-migration-failure.md).
# Resolve Live Migration Failures for Legacy Boot-from-Volume Hotplug VMs
## Overview
Live migration can fail for virtual machines that combine two specific characteristics:
* The VM was created using a hot-add-capable (zero-size) flavor. See [VM Hot Add CPU Or Memory](/private-cloud-director/copy-of-2026.4/virtualized-clusters/virtualmachine/vm-hot-add-cpu-or-memory.md) and [Flavorless VM Support](/private-cloud-director/copy-of-2026.4/virtualized-clusters/virtualmachine/flavorless-vms-with-hot-plug.md#zero-size-flavor).
* The VM boots from a zero-disk / boot-from-volume configuration, meaning its root disk is a persistent (block storage) volume rather than ephemeral storage. See [Live Migration of a VM using Volumes only](/private-cloud-director/copy-of-2026.4/virtualized-clusters/virtualmachine/vm-migration.md#live-migration).
This is a pre-existing issue and is not caused by upgrading. The space.vars.product\_acronym 2025.10 (October 2025) release corrected how the Compute Service generates the resource-request record for VMs of this type, but that correction only applies going forward — it is applied when the VM is created or when a hotplug operation is performed on it. VMs that were created with this combination of flavor and boot configuration before the 2025.10 release still hold the older, incorrect resource-request record, and live migration continues to fail for them until that record is corrected.
In this guide, you will identify whether a VM is affected and apply a one-time corrective step to unblock live migration for it.
## Symptoms
* A VM that uses a hot-add-capable flavor and boots from a persistent volume fails to live migrate, even though other VMs in the same virtualized cluster migrate successfully.
* The VM was created before the cluster was upgraded to the space.vars.product\_acronym 2025.10 release or later.
* The VM has not had a hotplug (hot-add CPU or memory) operation performed on it since being created.
## Identify Affected VMs
Check whether the VM uses a hot-add-capable flavor and a persistent-volume root disk:
{% tabs %}
{% tab title="Bash" %}
```bash
pcdctl server show
```
{% endtab %}
{% endtabs %}
* Confirm the VM's flavor has zero vCPU and zero RAM configured at the flavor level (hot-add-capable), and that the VM currently reports non-zero vCPU/RAM values.
* Confirm the VM's root disk is a persistent volume rather than an ephemeral disk. See [Boot VM from New Volume / Boot VM from Existing Volume](/private-cloud-director/copy-of-2026.4/virtualized-clusters/virtualmachine.md) for the boot configurations that use a volume-backed root disk.
If the VM meets both criteria and was created before the cluster's upgrade to space.vars.product\_acronym 2025.10 or later, it is a candidate for the workaround below.
## Workaround: Trigger a No-Op Hotplug
Triggering a hotplug operation on the affected VM — without changing its current CPU or memory values — regenerates the VM's resource-request record using the corrected logic. This is a one-time step per affected VM; once applied, live migration works normally for that VM going forward.
{% hint style="info" %}
**NOTE**
Re-submitting the VM's current CPU and memory values causes no actual change to the VM's resources. The VM does not need to be power-cycled for this step.
{% endhint %}
1. Select the affected VM in the VM grid view.
2. Navigate to **▷ Other Actions ▷ Hotplug**.
3. Leave the vCPU and memory fields set to the VM's current values — do not change them.
4. Click **Hotplug VM**.
After this step completes, retry the live migration.
## Next Steps
Repeat this workaround for each affected VM in your virtualized cluster. VMs created after the cluster's upgrade to space.vars.product\_acronym 2025.10 or later, and any VM that already had a hotplug operation performed on it, are not affected and do not require this step. For general live migration behavior and prerequisites, see [Virtual Machine Migration](/private-cloud-director/copy-of-2026.4/virtualized-clusters/virtualmachine/vm-migration.md).
---
# 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 current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.platform9.com/private-cloud-director/copy-of-2026.4/virtualized-clusters/troubleshooting-and-log-files/hotplug-boot-from-volume-live-migration-failure.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
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.