Posts Tagged ‘vmware’

Problem :

I experience this snapshot error with VEEAM backup and replication. For both  the error ,one single solution worked for me .

Error :

1) Consolidating virtual machine snapshots fails with the error: Change tracking target file already exists 


2) Creating Snapshot failed : The virtual disk is either corrupted or not a supported format.


Resolution :

To resolve this issue, the CBT files need to be moved out of the working folder of the affected virtual machine(s).

To move the CBT files and consolidate snapshots:
  1. Connect to the ESXi host that the virtual machine is running on using SSH.
  2. Navigate to the virtual machine folder using this command:

    cd /vmfs/volumes/datastore/virtual_machine/

  3. List the contents of the directory using the ls command and look for .ctk files.
  4. Create a temporary directory for the CBT files.

    For example:

    mkdir tmp

  5. Move the CBT files to this directory with this command:

    mv *-ctk.vmdk tmp/

  6. Run the snapshot  again.

Error :

Today was trying to do a V2V convertion with Vmware VConverter standalone edition . I have done that 100’s of time but today it stopped in the state of “Retrieving Source machine Information ” While checking on the converter server agent log , it was basically stopped in “uname -m” State . Whith some time spending with error log and vmware community site I have came up with the following  solution and it worked for me .Thought,  I need to share this with you.

Solution :

Log Location : /var/log/vmware-vcenter-converter-standalone


  • Converter Standalone stops responding for 10 minutes while displaying Retrieving source machine information.
  • Converter Standalone displays the following error message when you click Next on the Specify Source page: Unable to query the live Linux source machine.


This article describes the process of troubleshooting an issue where you might be unable to perform a P2V conversion of a powered-on Linux source machine. You can follow the given steps to eliminate a specific cause for your problem by verifying that your login environment does not include an incompatible command.


You must perform both troubleshooting steps listed below. Each step provides instructions or a link to a document, in order to eliminate possible causes and take corrective action as necessary. The steps are ordered in the most appropriate sequence to isolate the issue and identify the proper resolution.

If you perform a corrective action in any of the following steps, attempt converting the Linux source operating system again.

  1. Verify that the Linux source operating system is accepting ssh traffic and that the user name and password used in Converter are correct and result in a functional shell prompt.
    1. From the Linux source operating system, open a shell prompt, type ssh localhost, and press Enter. Log in using the same user name and password used in the Conversion wizard.
      If this does not result in a successful login, correct the problem.

      : For more information on opening a shell prompt, see Opening a command or shell prompt (1003892).
    2. From the computer running Converter, open a command prompt, run telnet xxxx nn, where xxxx is replaced by the host name or IP address of the Linux source operating system and nn is replaced by the port being used for SSH.
      If this does not result in information being displayed, a firewall might be preventing the computer running Converter Standalone from connecting to the Linux source operating system. Correct this problem.
  2. Confirm that the .bashrc file of the user name being used for authentication does not contain an echo command.

    If authenticating as root, use a text editor to edit /root/.bashrc. If authenticating as a different user, use a text editor to edit /home/user name/.bashrc, where user name is replaced by the user name being used for authentication.

    If a line in the file begins with echo, either delete it or change it to #echo.   <<<—– This was my Problem 🙂

3.   Ensure that the /tmp directory on the source machine is writable. If it is not, then the Converter agent will not be able to write to it and it will fail.

Ref :

After transferring and/or trying to restart a VM in ESX you may be presented with the error message “Unable to access a file since it is locked”.

Now what you need to do is work out what is actually locking this file and then (unsurprisingly) find a way to unlock it. Generally the problem will be caused by one of three things.

VMware ESX Unable to  access a file since it is locked

1. Process Lock: There is a process on the ESX server that still has hold of a file(s) used by the VM.  This is one of the most common causes.  To resolve this there have been a couple of good VMware Forum postings here and here that have been consolidated to this useful posting over at (*Note: It is worth checking out the comment by Kent at the bottom of the posting). Also, check out Tecumseh’s posting here.

2. Disk Naming Conflict: Two or more disks with the same VMDK name. This can be caused by another disk with the same VMDK file name being referenced by the VM.  This may have occurred due to a VM move where the VM used have disks located on different LUN’s or similar which have now been moved onto the same LUN and VM directory.  If this is the case rename one of the matching VMDK files (preferably not the one used as the boot drive) and with the VM powered down remove the renamed disk and reattach it (using its new name).

3. Corrupt VMX file: There is a possibility that the VM’s VMX file has corrupted.  You can look through the VMX file and try and troubleshoot the issue though it is quite often quicker to recreate a new VMX file.  This can be achieved by creating a new VM and attaching the existing disks to it (ie: rather than creating a new VM with new a new disk).

So here are three potential problem areas that you may want to consider when getting a “Unable to access a file since it is locked” within ESX.

Solution 3 works for me most of the Time.

Ref :