Loading

×Sorry to interrupt
CSS Error

Refresh

Cookie Preference Center

General Information on cookies

When you visit our website, we use cookies to ensure that we give you the best experience. This information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies by clicking on the different category headings to find out more and change your settings. However, blocking some types of cookies may impact your experience on the site and the services we are able to offer. Further information can be found in our

Cookie Policy.

Strictly Necessary

Strictly Necessary

Always Active

Strictly Necessary

Strictly necessary cookies are always enabled since they are essential for our website to function. They enable core functionality such as security, network management, and website accessibility. You can set your browser to block or alert you about these cookies, but this may affect how the website functions. For more information please visit www.aboutcookies.org or www.allaboutcookies.org.

Cookie Details‎

Performance

Performance

Performance

Performance cookies are used to analyze the user experience to improve our website by collecting and reporting information on how you use it. They allow us to know which pages are the most and least popular, see how visitors move around the site, optimize our website and make it easier to navigate.

Cookie Details‎

Please confirm your settings by refreshing the page.

Functional

Functional

Functional

Functional cookies help us keep track of your past browsing choices so we can improve usability and customize your experience. These cookies enable the website to remember your preferred settings, language preferences, location and other customizable elements such as font or text size. If you do not allow these cookies, then some or all of these services may not function properly.

Cookie Details‎

Advertising

Advertising

Advertising

Advertising cookies are used to send you relevant advertising and promotional information. They may be set through our site by third parties to build a profile of your interests and show you relevant advertisements on other sites. These cookies do not directly store personal information, but their function is based on uniquely identifying your browser and internet device.

Cookie Details‎

Advertising Cookies

Consent Leg.Interest

Select All Vendors

Select All Vendors

Select All Hosts

Select All

Clear Filters

Information storage and access

Apply

Confirm My Choices Reject All Allow All

Skip to main content

My Subscriptions

Loading

Knowledge Base

In ESX 3.5.x Storage VMotion fails with the error: Failed to unstun VM after disk reparent (1003874)

Last Updated: 2/14/2020Categories: Total Views: 9270Language:
English

Subscribe to get an email
newsletter with new updates

Please provide article feedback:

Details

Storage VMotion fails for a virtual machine

You see the error:

Failed to unstun VM after disk reparent.

The virtual machine is partially migrated and powered off. Generally, the virtual machine cannot be powered on again.

This issue affects:

Virtual machines converted in-place (not deployed or cloned) from template virtual machines with compact disks.

Virtual machines cloned from a virtual machine of the above type (as well as virtual machines cloned from those virtual machines, and so on).

Virtual machines with disks created with the following command:

vmkfstool -i <source> <destination> -d thin

Virtual machines created through the SDK with at least one disk created using the RelocateSpec.transform parameter set to sparse.

Solution

This issue affects these types of virtual machines because when a disk that is thin-provisioned (or is flat but was cloned from a virtual machine that thin-provisioned disks) is copied to the target datastore as part of Storage VMotion, the disk's content ID (CID) value is not preserved (although the content of the disk is correctly copied). When the virtual machine attempts to open the disk, it notices the CID is different from what it expects and fails to resume because it believes the disk is corrupted. In reality, the disk is not corrupted, only the CID is incorrect. So not only does the virtual machine end up powered off, but it cannot be powered back on because the CID is still incorrect.

Patch Fix

Patch ESX350-200802411-BG fixes this issue. For more information about the patch, see VMware ESX Server 3.5, Patch ESX350-200802411-BG: Enhanced Validation Checks, and Fixes for Storage VMotion and Lab Manager (1003458). Download the patch at http://www.vmware.com/download/vi/vi3_patches_35.html.

Pre-Patch Workaround

Step 1: Download the Required Scripts and Copy Them to the Appropriate Location

This article includes as attachments the following scripts:

isVMAffectedByKB1003874.pl checks if the virtual machine has a mis-matched CID value and therefore can be fixed with the next script. Copy this script to the Remote CLI host, into the location where you run svmotion.pl. For Windows Remote CLI installations, the default location is C:\Program Files\VMware\VMware VI Remote CLI\bin. For Linux Remote CLI installations, the default location is the home directory or /usr/sbin for the appliance.

completeSVMForVMAffectedByKB1003874.pl fixes the CID issue on the virtual machine disk file. Run this script after checking if your system is affected, using the previous script. Copy this script to the service console of your ESX host in the /root directory.

To download these files:

Find the links to the scripts under the Attachments section at the bottom of this article.

Right-click each link and save the file to your machine.

Note: If the host where you intalled the Remote CLI has a Web browser, you can save the files directly to that host. Then you need to copy only one file to another system (the ESX host).

To copy the files to the Remote CLI (for a Linux host or appliance) or to the service console from a different machine, use scp or WinSCP. If the Remote CLI is installed on a Windows host, follow the file transfer methods with which you are familiar (for example: FTP, Network File Share, or other).

Step 2: Verify Your Virtual Machine Is Affected

To verify your virtual machine belongs to the affected group of virtual machines described in the Details section of this article, run isVMAffectedByKB1003874.pl from the same directory where svmotion.pl is located.

For example, on a Windows Remote CLI host if you copied the script to the default location:

Open a Command Prompt window.

Change to the directory:

cd "C:\Program Files\VMware\VMware VI Remote CLI\bin"

Run the command:

isVMAffectedByKB1003874.pl

Similarly for a Linux Remote CLI host, if you copied the files to the default Remote CLI scripts location for the appliance, run the command:

perl /usr/sbin/isVMAffectedByKB1003874.pl

The output looks similar to the following example for an affected virtual machine:

************************** Attention! ****************************
The virtual machine "Compact WinXP 2" IS AFFECTED by KB 1003874!

If you attempted to Storage VMotion this VM, refer to KB 1003874
for instructions on completing the Storage VMotion and enabling
your VM to power on again.

Otherwise, do not Storage VMotion this VM until you have installed
patch bundle ESX350-200802411-BG. If you have already installed
this patch bundle, then your VM is safe to Storage VMotion and you
can disregard this message.
******************************************************************

The output looks similar to the following example for an unaffected virtual machine:

The virtual machine "VirtualCenter XP" is NOT affected by KB 1003874.
You can safely Storage VMotion this VM.

Notes:

You can also run this script as a precautionary measure on virtual machines that have not encountered this problem, before moving them with Storage VMotion.

If the script indicates that the virtual machine is not affected by this issue, the next step does not fix the problem. You need to perform additional analysis and other troubleshooting steps with the help of documentation, the forum community, or Technical Support (if appropriate). For related information, see Snapshot Operations Submitted Directly to an ESX Server Host During Storage VMotion Corrupt Virtual Machine Data (1003114).

Step 3: Repair the Problem Virtual Machine

To complete the Storage VMotion process and enable your virtual machine to power on again:

Log in to the service console of the ESX Server host where you copied the script.

Run the script completeSVMForVMAffectedByKB1003874.pl, specifying the name of the affected virtual machine as a command-line argument, surrounded by single quotes.

For example:

[root@esxhost root]# perl completeSVMForVMAffectedByKB1003874.pl 'Compact WinXP 2'

The output looks similar to the following:

Configuring your virtual machine to complete Storage VMotion...

**************************** Success! ******************************
The script has modified the VM so that it is able to complete the
Storage VMotion, as described in KB 1003874.

Please follow the rest of the steps in the KB to complete the
Storage VMotion and power-on your VM.

Do not attempt to Storage VMotion this VM again until you have
installed patch bundle ESX350-200802411-BG.

Original copies of all modified files have been placed in
/vmfs/volumes/477e63a9-a760d731-eecc-000e0c819981/Compact WinXP 2_1/backups.
********************************************************************

Using VMware Infrastructure Client, create a snapshot of the virtual machine.

In the snapshot manager, select Delete All. This collapses the snapshot you just took with any remaining DMotion-* files on the source datastore into the disks on the target datastore.

Power on the virtual machine. This powers on the virtual machine using all the files on the target datastore, allowing the virtual machine to complete its migration.

Warning: This issue still affects the virtual machine even after running the script on it. Do not attempt to move this virtual machine again with Storage VMotion until you have downloaded and installed patch ESX350-200802411-BG (now available). After you have installed the patch, you can safely move this virtual machine with Storage VMotion. This patch is listed on the 3.5 patch downloads page at http://www.vmware.com/download/vi/vi3_patches_35.html.

Detectable by VMware SkylineTM

Actions

Copy

link to clipboard
copied!

Print

Language:
English

Attachments

completeSVMForVMAffectedByKB1003874.pl

isVMAffectedByKB1003874.pl

Additional Resources

KB
•
End Of General Availability of the Free vSphere Hypervisor (ESXi 7.x and 8.x) (2107518)

Result 1 of 1

Ask The Community

Get answers quickly from VMware experts in the community

Post Subject

CONTINUE IN COMMUNITIES

Related Products:

VMware ESX Server

Related Versions:

VMware ESX Server 3.5.x

Take Our Survey

Was this article helpful?

YES

NO

Copyright © 2005-2024 Broadcom. All Rights Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries.

Terms of Use

Your California Privacy Rights

Privacy

Accessibility

Cookie Settings

Support Assistant