> 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/generic/migrated-vms-are-showing-file-system-errors.md).

# Migrated VMs are Showing File System Errors

## Problem

Multiple virtual machines (VMs) failed to boot due to file system corruption on their boot volumes. Both Windows and Linux VMs exhibited boot errors, showing file system inconsistencies.

```bash
BdsDxe: loading Boot0001 "UEFI Misc Device" from PciRoot(0x0)_Pci(0x5,0x0)
BdsDxe: starting Boot0001 "UEFI Misc Device" from PciRoot(0x0)_Pci(0x5,0x0)
```

## Environment

* Private Cloud Director Virtualization - v2025.7 & v2025.8
* Self-Hosted Private Cloud Director Virtualization - v2025.7 & v2025.8
* Component: VMHA

## Workaround

1. Identify Impacted VMs:
   1. Review VM boot console output for file system errors or stuck boot sequences.
   2. Cross-check recent migrations or evacuations triggered by VMHA from the ostackhost logs (`/var/log/pf9/ostackhost.logs`) from the source host.

```bash
INFO nova.compute.manager [req-UUID masakari services] [instance: [INSTANCE_ID]] Evacuating instance
INFO nova.compute.claims [req-UUID masakari services] [instance: [INSTANCE_ID]] Claim successful on node <COMPUTE_HOST>
INFO nova.compute.resource_tracker [req-UUID masakari services] [instance:  [INSTANCE_ID]] Updating resource usage from migration <MIGRATION_ID>
ERROR nova.scheduler.client.report [req-UUID masakari services] [req-UUID] Failed to update inventory to [{'MEMORY_MB': {'total': 2063836, 'min_unit': 1, 'max_unit': 2063836, 'step_size': 1, 'allocation_ratio': 1.5, 'reserved': 512}, 'VCPU': {'total': 128, 'min_unit': 1, 'max_unit': 128, 'step_size': 1, 'allocation_ratio': 16.0, 'reserved': 0}, 'DISK_GB': {'total': 86809, 'min_unit': 1, 'max_unit': 86809, 'step_size': 1, 'allocation_ratio': 9999.0, 'reserved': 0}}] for resource provider with UUID <UUID>.  Got 409: {"errors": [{"status": 409, "title": "Conflict", "detail": "There was a conflict when trying to complete your request.\\n\\n resource provider generation conflict  ", "code": "placement.concurrent_update", "request_id": "req-UUID"}]}
ERROR nova.scheduler.client.report [req-UUID masakari services] [req-UUID] Failed to update inventory to [{'MEMORY_MB': {'total': 2063836, 'min_unit': 1, 'max_unit': 2063836, 'step_size': 1, 'allocation_ratio': 1.5, 'reserved': 512}, 'VCPU': {'total': 128, 'min_unit': 1, 'max_unit': 128, 'step_size': 1, 'allocation_ratio': 16.0, 'reserved': 0}, 'DISK_GB': {'total': 86808, 'min_unit': 1, 'max_unit': 86808, 'step_size': 1, 'allocation_ratio': 9999.0, 'reserved': 0}}] for resource provider with UUID <UUID>.  Got 409: {"errors": [{"status": 409, "title": "Conflict", "detail": "There was a conflict when trying to complete your request.\\n\\n resource provider generation conflict  ", "code": "placement.concurrent_update", "request_id": "req-UUID"}]}
```

2. Temporarily Disable VMHA:
   1. Disable VM High Availability (VMHA) across the affected clusters to prevent automatic evacuations.
   2. Confirm no ongoing evacuation events in logs (`/var/log/pf9/ha/ha-agent.log`) from the source host.
3. Recover the VMs:
   1. For Linux VMs: Boot into recovery mode and run `fsck -y /dev/<BOOT-VOLUME>`
   2. For Windows VMs: Mount the volume to a helper instance, restore critical registry files, and reattach to the original VM or using a file system [checker](https://support.microsoft.com/en-us/topic/use-the-system-file-checker-tool-to-repair-missing-or-corrupted-system-files-79aa86cb-ca52-166a-92a3-966e85d4094e) tool.
4. Validate Cinder and NFS Mounts:
   1. Check all Cinder hosts for correct NFS mount configurations as per the cluster blueprints.

## Cause

VMHA (Virtual Machine High Availability) evacuation events triggered by network connectivity issues resulted in multiple VM instances simultaneously accessing the same storage volumes, causing data corruption.

## Resolution

The long-term fix is available on **PCD-October** [release](https://platform9.com/docs/private-cloud-director/private-cloud-director/october-2025-release) (tracked under PCD-4211, PCD-4212).


---

# 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/generic/migrated-vms-are-showing-file-system-errors.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.
