Checking for disk corruption on the destination server after using VMware Converter
search cancel

Checking for disk corruption on the destination server after using VMware Converter

book

Article ID: 330170

calendar_today

Updated On:

Products

VMware vSphere ESXi

Issue/Introduction

This article provides steps to check for data corruption or skipped files during the conversion process and how to correct or repair the damage on the destination.

Symptoms:
  • Using VMware Converter you have performed a conversion without any visible errors.
  • The resulting virtual machine fails to start the operating system.
  • Certain applications report corrupted files or libraries and may not start.
  • Database-oriented applications report corrupted tables or database files.
  • Files from the source are missing on the destination virtual machine.
  • You may receive one or more of these errors:
    • A disk read error occurred
    • NTLDR is missing
      Press any key to restart
    • Windows could not start because the following file is missing or corrupt:
      C:\windows\system32\hal.dll
      Please re-install a copy of the above file.
    • Windows could not start because the following file is missing or corrupt
      C:\windows\system32\config\system
      C:\windows\system32\config\security
      C:\windows\system32\config\default
      C:\windows\system32\config\sam
      C:\windows\system32\config\software
    • STOP 0xC000021A FATAL_SYSTEM_ERROR
    • The Windows Logon Process system process terminated unexpectedly.

cannot-open-disk corrupt-virtual-disk system-disk-error virtual-disk converter converting-virtual-machine-fails converting-virtual-machine-corrupt-disk

Environment

VMware vCenter Converter Standalone 4.3.x
VMware vCenter Converter 4.1.x
VMware vCenter Converter 4.2.x
VMware vCenter Converter 4.0.x
VMware Converter 3.0.x
VMware vCenter Converter Standalone 4.0.x

Resolution

Issues may arise with a virtual machine after performing a seemingly successful conversion with VMware Converter. Issues reading files or files becoming locked during the process of conversion can cause corruption inside your virtual machine. Some files can be locked if they are in use during conversion. VMware Converter attempts to convert the file, but it may determine that it is unable to do so and skip the file.
 
The same condition can occur if there are bad blocks on the drive or corrupted files on the source system. VMware Converter attempt its best to convert the file, but end up skipping files if necessary. The result shows that the conversion appears to be successful, but you may have erratic behavior upon the boot-up of the converted virtual machine, or applications do not perform as expected. Perform these steps to troubleshoot this behavior:

Determining if data corruption or a skipped files event has occurred

To determine if data corruption or a skipped files event has occurred:
  1. Open the Converter log files from the conversion session. The location is indicated during conversion, or in the lower panel of VMware Converter. If you are using Converter Enterprise plug-in, the logs are located in %UserProfile%\Application Data\VMware.
     
  2. Examine the log files for these messages:
    • [Pcopy] error Can not write stream data: The process cannot access the file because it is being used by another process (32)
    • Error copying destination file
    • Image processing task has failed with PlatformError fault: 23
    • sector could not be read
       
  3. If any of the above messages are noted, files were not completely or correctly copied into the new virtual machine. Proceed to the Recovery Options section of this article to determine the best course of action.

Recovery options

When you encounter a data corruption issue, you have a number of choices depending on your situation. Each section below demonstrate different ways of recovering from the situation. Review the methods below and select the one most appropriate to your situation.
 
Recovering from data corruption with a new conversion
 
To recover from data corruption with a new conversion:
  1. If possible, run the chkdsk utility on the source server before attempting to convert again.
    1. Open a command prompt. For more information, see Opening a command or shell prompt (1003892).
    2. Type chkdsk c: /f and press Enter.

      Note: To complete this command you must restart the server. press y when prompted to schedule the check on restart.

       
    3. Repeat step b, substituting c: for any other local drive letters that must be captured by the conversion.
       
  2. If the server is running any database applications, Active Directory, or Microsoft Exchange, shut down the services prior to conversion to ensure a proper copy. If this is not possible, you must re-index the database tables in the virtual machine after conversion is completed to ensure data integrity.

    Note: If the source server is running Active Directory, start up the server in "Directory Service Restore Mode" to prevent the services from starting.

     
  3. Perform another conversion with VMware Converter and specify that the disk sizes be adjusted even by a small amount. This forces a file system only clone and may avoid copying corrupted blocks from the source hard drive.
Recovering from data corruption using the new virtual machine

To recover from data corruption using a new virtual machine:

  1. From the new virtual machine, boot the Windows Setup disc and start the Recovery Console. Log in to the damaged operating system.
  2. Repair the master boot record. Type fixmbr and press Enter.
  3. Repair the boot sector. Type fixboot and press Enter.
  4. Check the disk for corruption in the file system. Type chkdsk c: /p and press Enter.
  5. Exit the recovery console. Type exit and press Enter.

    Warning: If you do not use the exit command to quit the Recovery Console, your changes may be discarded.

     
  6. After the virtual machine is bootable, review the files skipped in the Converter log files and re-copy the files from the source server.
  7. If the source server was running any database applications, Active Directory, or Microsoft Exchange, shut down the services prior on the source and copy the files into the new virtual machine. If this is not possible, you must reindex the database tables in the virtual machine to ensure data integrity.

    Note: If the source server is running Active Directory, start up the server in "Directory Service Restore Mode" to prevent the services from starting.


Additional Information

For related troubleshooting information, see: