We've detected that your browser language is Chinese. Would you like to visit our Chinese website? [ Dismiss ]
By: Emma

When a Hyper-V VM goes missing from Hyper-V Manager after a reboot, the virtual hard disk and configuration files are often still intact.

The cause may be a stopped Virtual Machine Management Service (VMMS), a storage path that became inaccessible, a permissions issue, or a VM that lost its registration with Hyper-V. Before attempting anything else, check whether those files still exist — it could save you from unnecessary work or accidental data loss.

Why Did My Hyper-V VM Disappear After Reboot?

A Hyper-V VM can go missing from Hyper-V Manager for several reasons. Check these common causes before making any changes.

  • VMMS service or management connection issues: If the Virtual Machine Management Service (vmms) fails to start after a reboot, or Hyper-V Manager is pointed at the wrong host, the VM list may appear empty or incomplete.
  • VM registration loss: Hyper-V keeps a registration entry for each VM. If that entry is missing or corrupted, the VM will not appear in the console even though its files are still on disk.
  • Inaccessible VM storage: A VM stored on a separate volume, external drive, SMB share, or SAN may become unavailable after a restart if the storage has not mounted or the network path is down.
  • Incorrect folder permissions: Changes to access control lists (ACLs) may prevent Hyper-V from reading the VM configuration file or virtual disk. This can happen after a Windows Update, a policy change, or a manual permission edit.
  • Antivirus or software changes: An antivirus scan or security policy update may quarantine or block access to VM files, affecting registration or storage availability.
  • Cluster or replication configuration issues: A clustered or replicated VM may be managed through Failover Cluster Manager rather than appearing in a standalone Hyper-V Manager session.

hyper-v-vm-disappeared-from-manager-after-reboot

Before You Start: Check Whether Your VM Files Still Exist

These checks help you identify the cause before applying a fix.

Check the VM Configuration and Virtual Disk Files

  1. Open File Explorer and navigate to the VM’s previous storage location.
  2. Also check the default path: C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines\.
  3. Look for .vmcx or .xml configuration files and .vhdx virtual disk files.
  4. If the VM uses a network share or separate volume, confirm that the path is currently accessible.

If the VHDX files still exist, do not delete or overwrite them. They may allow you to recover the VM without rebuilding its virtual disks.

Run Get-VM in PowerShell to Check Registered VMs

  1. Open PowerShell as Administrator on the Hyper-V host.
  2. Run: Get-VM
  3. To query a remote host: Get-VM -ComputerName "HOSTNAME"
  4. If the VM appears here but not in Hyper-V Manager, verify the console is connected to the correct host.
  5. If the VM is absent from the output, check its files and storage before attempting to re-register it.

Verify the VM Storage Paths and Service Status

  1. Check the VMMS service: Get-Service vmms If the result is not Running, investigate before proceeding.
  2. Check the host’s default storage paths: Get-VMHost | Select-Object VirtualMachinePath, VirtualHardDiskPath
  3. Confirm that the drive, volume, or network share where the VM files are stored is accessible and that the mount point has not changed since the last reboot.
  4. Note any custom storage paths before moving on to the fixes below.

How to Fix Hyper-V VM Disappeared from Manager After Reboot

Once you have confirmed that the VM files and storage are available, apply the fixes below in order.

Start with the management service and host connection before attempting to re-register or recreate the VM.

Fix 1: Verify the VMMS Service and Hyper-V Manager Connection

If the VM list is empty or incomplete after a reboot, the Virtual Machine Management Service may not be running, or Hyper-V Manager may be connected to the wrong host.

  1. Open PowerShell as Administrator and check the VMMS service: Get-Service vmms
  2. If the service is stopped, start it: Start-Service vmms If it fails to start, open Event Viewer and check Applications and Services Logs > Microsoft > Windows > Hyper-V-VMMS for error details.
  3. Open Hyper-V Manager and check the server listed in the left pane. Confirm it matches the host where the VM was registered.
  4. To connect to a different host, right-click Hyper-V Manager in the left pane and select Connect to Server. Choose Local computer or enter the correct remote host name, then click OK.
  5. Select the host and press F5 to refresh, or run Get-VM in PowerShell to confirm whether the host recognizes the VM.

If the VM reappears, the issue was with the service or management connection. If VMMS is running and the VM is still absent from both Hyper-V Manager and Get-VM, continue to the storage and permissions checks below.

Fix 2: Restore Access to the VM Storage Location

If the VM disappeared because its storage became unavailable after a reboot, Hyper-V cannot access the files needed to display or manage it. This commonly affects VMs stored on a secondary drive, external device, SMB network share, or SAN volume.

  1. Check the VM’s storage location using the paths noted during your initial diagnosis. If nothing was recorded, inspect the expected configuration and VHDX directories in File Explorer.
  2. Open Disk Management and confirm that the relevant disk is online and its volume is mounted. If the VM is on an external drive, check the connection. For network storage, verify connectivity and access to the shared folder.
  3. Confirm that the drive letter, mount point, or UNC path has not changed since the last reboot. A VM configured to use D:\Hyper-V\VMs\ will become inaccessible if that volume is no longer mounted as D:.
  4. If the VM uses an SMB share, open the configured path (for example, \\FileServer\HyperV) from the Hyper-V host and confirm that access is available. In production environments, verify the share and NTFS permissions for the account Hyper-V uses, not just interactive administrator access.
  5. Once storage is accessible, run Get-VM to check whether the VM has reappeared. If it does, refresh Hyper-V Manager. If it is still missing, confirm the configuration files exist and continue to the permissions check.
Note: Do not initialize, format, or recreate a storage volume because it appears offline. Those actions can destroy existing data. Restore access to the original storage first, then reassess the VM’s registration status.

Fix 3: Check and Correct VM Folder Permissions

If the VM files exist and storage is accessible, incorrect folder permissions may prevent Hyper-V from reading the configuration or virtual disk files. This commonly happens after files are moved, restored from backup, or copied to another host.

  1. In File Explorer, navigate to the folders containing the VM’s .vmcx and .vhdx files.
  2. Right-click each folder, select Properties > Security, and review the listed accounts. Look for missing or unexpected permission entries.
  3. Check for the VM’s per-VM security identity. Each Hyper-V VM uses a unique service SID in the format NT VIRTUAL MACHINE\<VM ID> to access its files. To retrieve the VM ID for a registered VM, run: Get-VM -Name "VMName" | Select-Object Name, VMId If the VM is no longer registered, the VM ID may still be visible in its configuration files or host records.
  4. If the required permission entry is missing, use icacls to restore access. For example: icacls "D:\Hyper-V\VMs\VMName" /grant "NT VIRTUAL MACHINE\<VMId>":(OI)(CI)F Replace the path and VM ID with the actual values. Apply permissions to both the configuration folder and the virtual disk folder.
  5. Refresh Hyper-V Manager or run Get-VM to check whether the VM has reappeared. If it is still missing, correcting permissions alone will not restore its registration — continue to the next fix.
Note: Do not recursively replace permissions across the entire Hyper-V directory without understanding the existing security configuration. Incorrect ACL changes can affect other VMs on the same host.

Fix 4: Review Antivirus Exclusions and Recent Software Changes

Antivirus software or recent system changes can interfere with access to Hyper-V configuration files or VM storage. If the VM disappeared after a reboot, review security alerts, quarantine events, and recent updates before modifying anything.

  1. Open your security software and check recent alerts or quarantine records involving Hyper-V files, virtual disks, or VM-related processes.
  2. Go to Settings > Windows Update > Update history and check whether a recent update coincides with the issue. Also check Event Viewer under Applications and Services Logs > Microsoft > Windows > Hyper-V-VMMS for errors logged around the time of the reboot.
  3. If your security vendor recommends exclusions for specific Hyper-V paths or processes, confirm those exclusions are in place. Do not disable antivirus protection or exclude broad system directories without a clear technical reason.
  4. If a legitimate VM file was quarantined, verify the detection with your security team before restoring it. Do not restore a file solely because it has a .vmcx or .vhdx extension.
  5. After resolving a confirmed security block, run Get-VM to check whether the VM has reappeared. If it is still missing, verify that the original configuration files are intact before proceeding.

If no security event or recent change explains the disappearance, do not add speculative exclusions. Continue to Fix 5, which covers re-registering a VM from its existing configuration files.

Fix 5: Re-register the VM from Its Existing Configuration Files

If the VM’s configuration files and virtual disks still exist but Get-VM does not list the VM, its registration may be missing. You can re-register it through Hyper-V Manager without creating a new virtual machine.

  1. Locate the VM’s configuration folder and confirm that a .vmcx file is present. Verify that the associated virtual disks are also available before proceeding.
  2. In Hyper-V Manager, select the host, then click Import Virtual Machine in the Actions pane.
  3. Click Next, browse to the folder containing the VM configuration files, and select the VM when it appears.
  4. On the Choose Import Type screen, select Register the virtual machine in-place (use the existing unique ID). This option registers the VM using its current file locations without copying or moving anything.
  5. Review the summary and complete the wizard. Once the import finishes, check that the VM appears in Hyper-V Manager and verify its virtual disk paths and network settings before starting it.
  6. If the import fails, check Event Viewer under Hyper-V-VMMS for the specific error. Verify file access, confirm the configuration files are not corrupted, and check whether the VM is already registered elsewhere on the host.

Do not select an import option that copies or duplicates the VM unless that is your intention. The existing VHDX files should not be overwritten during this process.

If the configuration files are missing or cannot be imported, proceed to Fix 6, which rebuilds the VM configuration while reusing the existing virtual disk.

Fix 6: Re-create the VM Configuration and Reattach the Existing VHDX

If the original VM configuration files are missing or cannot be imported, you can create a new VM configuration and attach the existing VHDX. This restores access to the VM’s data without creating a new virtual disk, but you will need to recreate the hardware settings manually.

  1. Locate the .vhdx file and confirm it is accessible. If possible, make a backup copy before proceeding. Do not overwrite or modify the original disk.
  2. In Hyper-V Manager, select the host and click New > Virtual Machine in the Actions pane.
  3. Enter the VM name, choose a storage location, and select the correct generation. Match the original VM’s generation, memory, processor, and network settings as closely as possible. Generation 1 and Generation 2 VMs are not interchangeable.
  4. On the Connect Virtual Hard Disk page, select Use an existing virtual hard disk and browse to the original .vhdx file.
  5. Complete the wizard, then open Settings to verify the processor, memory, network adapter, boot order, and disk attachment. For a Generation 2 VM, confirm that Secure Boot settings are compatible with the guest OS.
  6. Start the VM and check whether the guest OS boots normally. If it does not, review the generation, boot order, and disk attachment before making further changes.

A new VM configuration does not restore every original setting. Virtual switches, checkpoints, virtual TPM, and Secure Boot details may need additional attention. If the VM uses multiple virtual disks or checkpoints, verify the full disk chain before reattaching anything.

If the VM still does not start, investigate the specific error rather than rebuilding the configuration again. The next section covers scenarios where only one VM is affected, multiple VMs disappeared after a Windows Update, or VMs are missing from a clustered or replicated environment.

Troubleshooting Specific Hyper-V VM Disappearance Scenarios

The cause of a missing VM often becomes clearer when you consider how many VMs are affected and what changed before the reboot. Use these scenarios to narrow down the issue without repeating fixes that do not apply to your situation.

Only One VM Disappeared After Reboot

If only one VM is missing while others remain visible, the issue is most likely specific to that VM’s configuration, storage path, or registration. A host-wide VMMS failure is unlikely if the other VMs are working normally.

Run Get-VM to confirm whether the VM is registered. If it is not listed, locate its .vmcx and .vhdx files and use the Import Virtual Machine wizard to re-register the existing configuration.

Multiple VMs Disappeared After a Windows Update

If several VMs disappeared after a Windows Update, check for host-level changes before attempting to recover each VM individually. A service startup failure, storage mount issue, or permission change could affect multiple VMs at once.

Check the VMMS service status and review Hyper-V-VMMS events in Event Viewer.

Confirm that the volumes containing the VM files are accessible and check Windows Update history to identify recent changes. Do not uninstall updates without clear evidence that a specific update caused the issue.

Replicated or Clustered VMs Are Missing from Hyper-V Manager

VMs managed through Failover Clustering or Hyper-V Replica may not appear in a standalone Hyper-V Manager session. A clustered VM may be owned by another node, while a replica VM is not intended for normal production use on the replica host.

For clustered VMs, open Failover Cluster Manager and check the Roles view for the VM’s status and current owner node. Use the cluster tools to investigate or recover the resource rather than registering a duplicate directly on an individual host.

For Hyper-V Replica, verify the replication relationship and the status of both the primary and replica VMs before taking any action. Starting a replica independently or changing its registration can affect replication consistency.

VM Files Exist but the VM Cannot Be Registered

If the .vmcx and .vhdx files exist but the Import Virtual Machine wizard fails, the configuration may be corrupted, incompatible with the current host, or blocked by a permissions issue. The import error and Hyper-V-VMMS logs can help identify the specific cause.

Confirm that the configuration files belong to the intended VM, that storage is accessible, and that the host supports the VM’s configuration version. If the configuration cannot be recovered, create a new VM and attach the existing virtual disk as described in Fix 6. Preserve the original files and check any checkpoint disk dependencies before making changes.

Use i2Backup to Back Up and Restore Hyper-V VMs

Recovering a missing VM is possible when its files are intact — but if the configuration or virtual disk is lost or corrupted, recovery becomes significantly harder. Keeping a dedicated backup of your Hyper-V VMs ensures you have a known-good restore point before problems occur.

i2Backup is an enterprise backup solution that protects Hyper-V environments without requiring agents installed on each VM. It uses native virtualization platform APIs to back up VMs directly at the host level, with no impact on running workloads.

Key features for Hyper-V protection:

  • Agentless VM backup: Backs up Hyper-V VMs without installing software inside each guest, reducing management overhead and avoiding compatibility issues.
  • Instant VM recovery: Mounts a VM backup directly to the Hyper-V host for near-immediate recovery, without waiting for a full restoration to complete.
  • File-level recovery: Restores individual files or folders from a VM backup without recovering the entire virtual machine.
  • Broad platform compatibility: Supports Hyper-V alongside VMware, OpenStack, and other mainstream virtualization platforms, as well as physical servers and databases.
  • Flexible storage destinations: Saves backups to local disks, NAS, tape libraries, object storage, or cloud targets to avoid a single point of failure.

If a VM disappears after a reboot and its configuration or disk files cannot be recovered, a recent i2Backup job gives you a clean restore point to work from — without rebuilding the VM from scratch.

FREE Trial for 60-Day

How to Prevent Hyper-V VMs from Disappearing After Reboot

These practices reduce the risk of VM registration and storage problems after a host restart.

  • Keep VM files on reliable storage. Use stable storage paths and confirm that required volumes, network shares, and SAN connections are available when the Hyper-V host starts.
  • Monitor the VMMS service. Check the vmms service after planned maintenance or unexpected reboots. Investigate recurring startup failures and review relevant events in Event Viewer.
  • Maintain folder permissions. Avoid unnecessary changes to VM folder ACLs. When moving or restoring VM files, verify that Hyper-V still has the access it needs to read configuration files and virtual disks.
  • Review updates and security changes. Monitor host updates, antivirus alerts, and security policy changes. Test significant changes in a non-production environment before applying them to critical hosts.
  • Document VM settings and storage paths. Record each VM’s generation, virtual disk locations, memory, processor, network connections, and checkpoint dependencies. This makes recovery faster if the original configuration is lost.
  • Back up VM data and test restores. Maintain a backup process that protects both virtual disk data and the configuration needed to rebuild the VM. Verify that backups can actually be restored, not just that backup jobs complete without errors.
  • Check host health after reboots. After planned maintenance, confirm that critical VMs appear in Hyper-V Manager or the appropriate cluster console, that storage is accessible, and that key workloads start normally.

Conclusion

A Hyper-V VM that disappears from Manager after a reboot is usually recoverable, provided its configuration files and virtual disks are still intact. Start by checking whether the VMMS service is running and whether the storage location is accessible before attempting to re-register or rebuild the VM configuration.

If the files are present, re-registering the VM through the Import Virtual Machine wizard is the least disruptive option. If the configuration is missing or cannot be imported, you can create a new VM and reattach the existing VHDX, though you will need to recreate the hardware settings manually.

To avoid this situation in the future, keep VM files on stable storage, document each VM’s configuration, and maintain a tested backup. For enterprise Hyper-V environments, a dedicated backup and recovery solution ensures you have a reliable restore point when manual recovery is not an option — visit Info2soft to learn more.

Emma is the bridge between complex engineering and the people who need it. As a content creator at Info2soft, she spends her days translating "tech-speak" into clear, actionable stories about data resilience. She’s not just documenting software; she's uncovering how data replication and recovery actually change the way businesses run.

More Related Articles

Ready to Enhance Business Data Security?

· Enterprise & Mid-market Customers Worldwide.

· Support team available to assist you throughout your trial.

· Start a 60-day free trial or view demo to see how Info2soft protects enterprise data.

Please fill out the form and submit it, our customer service representative will contact you soon.
By submitting this form, I confirm that I have read and agree to the Privacy Notice.
{{ isSubmitting ? 'Submitting...' : 'Submit' }}