amit_dhane
Contributor
Contributor

Error "Failed to lock the file" occured while trying to restore the VMDK file on new virtual machine.

Hi,

I'm trying to migrate my virtual machine present on private cloud environment (Nephoscale) to the local environment.  Since automated disk image exporting feature is not available in their enviornment, we have took the 'dd'/'raw' full byte copy of the instance's disk and converted it into VMDK as mentioned in the steps given in the link

https://jima.cat/convert-raw-dd-image-to-vmdk-vmware/

I have then attached this VMDK to my local Virtual Machine vSphere as a "Existing Hard Disk" but when I tried to power on the VM then it is throwing following two errors.

a. "Cannot open the disk '/vmfs/volumes/53671f4a-5bfc16da-6053-002590e74eac/img/hard_disk.vmdk' or one of the snapshot disks it depends on."

b. "Failed to lock the file"

Can you please help me with the steps to restore this VMDK to my new VM.

Also, what is the meaning of above 2 errors and in which case it occurs?

Thanks in advance.

0 Kudos
6 Replies
a_p_
Leadership
Leadership

From what I understand qemu creates a .vmdk file format that's usable for VMware Workstation, Player, or Fusion. Such .vmdk files are not supported by ESXi (anymore).

  • Do you still have the raw file?
  • What's it's exact size in bytes?
  • What type of disk controller was used for the original disk (SCSI, IDE, ...)?

If I understand this correctly, it's only a matter of renaming the raw file, and creating an appropriate descriptor file (see Convert dd-Image (SAS, Windows) to ESXi6 VMDK ).

André

0 Kudos
amit_dhane
Contributor
Contributor

Thank You André.

We need to deploy it only on ESXi. We tried renaming the raw file as suggested by you, but it didn't show up while attaching as "Existing Hard Disk".

   Do you still have the raw file?

    >> Yes, I have the raw file.

   

    What's it's exact size in bytes?

    >> Raw file size is 151GB

   

    What type of disk controller was used for the original disk (SCSI, IDE, ...)?

    >> Disk type is SSD.

   

    [root@cnesst ~]# cat /proc/scsi/scsi

    Attached devices:

    [root@cnesst ~]#

       

    [root@cnesst ~]# parted --list

    Model: Virtio Block Device (virtblk)

    Disk /dev/vda: 161GB

    Sector size (logical/physical): 512B/512B

    Partition Table: msdos

    Number  Start   End    Size    Type     File system     Flags

     1      1049kB  263MB  262MB   primary  ext3            boot

     2      263MB   159GB  159GB   primary  ext3

     3      159GB   161GB  2147MB  primary  linux-swap(v1)

See attached screenshots where the renamed file is not visible while attaching it to VM.

0 Kudos
a_p_
Leadership
Leadership

We need to deploy it only on ESXi. We tried renaming the raw file as suggested by you, but it didn't show up while attaching as "Existing Hard Disk".

You seem to have overlooked the part with creating a descriptor .vmdk file, which is why I've asked for the details.

   What's it's exact size in bytes?

    >> Raw file size is 151GB

I need the exact size in bytes, not GB. What I'm confused about is that the file size seems to be ~150GB, but it's 161GB according to the parted command!? It seems as if the downloded raw file is not complete.

    What type of disk controller was used for the original disk (SCSI, IDE, ...)?

    >> Disk type is SSD.

The original virtual disk may have been stored on an SSD, but what's important is how the virtual machine's controller was configured. I assume it was some sort of SCSI controller!?

André

0 Kudos
amit_dhane
Contributor
Contributor

Hi André,

Thanks for your prompt response.

Below are the answers for your questions-

I need the exact size in bytes, not GB. What I'm confused about is that the file size seems to be ~150GB, but it's 161GB according to the parted command!? It seems as if the downloded raw file is not complete.

>>> Below is the output from the source vm where it shows vda disk size is 150GB i.e

157286416 KB = 157286416000 Bytes (in decimal)

157286416 KB = 161061289984 Bytes (in binary)

[root@test~]# df

Filesystem     1K-blocks      Used Available Use% Mounted on

/dev/vda2      152518244  15362644 129409028  11% /

tmpfs            4030728         0   4030728   0% /dev/shm

/dev/vda1         247919     58627    176492  25% /boot

/dev/vdb       206293688 157347100  48946588  77% /mnt

[root@cnesst ~]# lsblk

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT

vda    252:0    0   150G  0 disk

├─vda1 252:1    0   250M  0 part /boot

├─vda2 252:2    0 147.8G  0 part /

└─vda3 252:3    0     2G  0 part [SWAP]

vdb    252:16   0   200G  0 disk /mnt

After converting it into raw the file size is also 150GB-

[root@amit img]# du 317_175889_1.raw

157286416       317_175889_1.raw

The original virtual disk may have been stored on an SSD, but what's important is how the virtual machine's controller was configured. I assume it was some sort of SCSI controller!?

>> Below is the copy of this exact virtual machine libvirt config file.

This file is enough to answer all questions related to what virtual hardware is/was provided to the instance in question by the libvirt/qemu/kvm hypervisor.

I've also included node OS and qemu version.

Hope this helps.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

zev@node1008855:~$ cat /etc/libvirt/317_175889_1

<domain type='kvm'>

<name>317_175889_1</name>

<uuid>ff1693a7-2c54-4461-9594-2e0e94e612ff</uuid>

<memory>8388608</memory>

<currentMemory>8388608</currentMemory>

<vcpu>4</vcpu>

  <os>

    <type arch='x86_64' machine='pc'>hvm</type>

    <boot dev='hd'/>

  </os>

  <features>

    <acpi/>

  </features>

  <clock offset='utc'/>

<on_poweroff>destroy</on_poweroff>

<on_reboot>restart</on_reboot>

<on_crash>restart</on_crash>

  <devices>

<emulator>/usr/local/bin/qemu-system-x86_64</emulator>

    <disk type='block'>

     <source dev='/dev/vg1/317_175889_1'/>

      <target dev='hda' bus='virtio'/>

    </disk>

    <disk type='block'>

     <source dev='/dev/vg1/ticket226905'/>

      <target dev='hdb' bus='virtio'/>

    </disk>

<interface type='bridge'>

<mac address='00:16:3e:17:81:7d'/>

<source bridge='nbr_fe_5087'/>

<model type='virtio'/>

</interface>

<interface type='bridge'>

<mac address='00:16:3e:17:81:81'/>

<source bridge='nbr_be_5087'/>

<model type='virtio'/>

</interface>

    <input type='tablet' bus='usb'/>

    <graphics type='vnc' port='-1' autoport='yes' listen='0.0.0.0' passwd='XXXXX'/>

  </devices>

</domain>

zev@node1008855:~$ lsb_release -a

No LSB modules are available.

Distributor ID: Ubuntu

Description: Ubuntu 10.04.4 LTS

Release: 10.04

Codename: lucid

zev@node1008855:~$ /usr/local/bin/qemu-system-x86_64 -version QEMU emulator version 2.0.0, Copyright (c) 2003-2008 Fabrice Bellard

zev@node1008855:~$ sudo lvdisplay /dev/vg1/317_175889_1

  --- Logical volume ---

  LV Name                /dev/vg1/317_175889_1

  VG Name                vg1

  LV UUID eGg8xs-gCqY-s97n-M0DN-uA8W-kLms-rbSwF1

  LV Write Access        read/write

  LV Status              available

  # open                 1

  LV Size                150.00 GiB

  Current LE             38400

  Segments               1

  Allocation             inherit

  Read ahead sectors     auto

  - currently set to     256

  Block device           252:9

zev@node1008855:~$ sudo fdisk -l /dev/vg1/317_175889_1

Disk /dev/vg1/317_175889_1: 161.1 GB, 161061273600 bytes

255 heads, 63 sectors/track, 19581 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk identifier: 0x0006d3db

                 Device Boot      Start         End      Blocks Id  System

/dev/vg1/317_175889_1p1 *           1          32      256000 83  Linux

/dev/vg1/317_175889_1p2              32       19321 154932224   83  Linux

/dev/vg1/317_175889_1p3           19321       19582 2097151+  83  Linux

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

0 Kudos
a_p_
Leadership
Leadership

Ok, it should be possible to create a .vmdk descriptor file by following the instruction in continuum​'s solution in the link I posted in my first reply.

I've created one (see attachment) with the information you've provided.

What you need to do is to:

  1. rename raw file to "317_175889_1-flat.vmdk"
  2. upload the attached descriptor "317_175889_1.vmdk" to the datastore

Please ensure that you have a backup copy of the raw file!

André

0 Kudos
continuum
Immortal
Immortal

According to:

Number  Start   End    Size    Type     File system     Flags

     1      1049kB  263MB  262MB   primary  ext3            boot

     2      263MB   159GB  159GB   primary  ext3

     3      159GB   161GB  2147MB  primary  linux-swap(v1)
I believe that the original raw image is truncated.
I expect problems with reading the ext3 Partition.
I would recommend to recreate the original raw image via
ddrescue /dev/sda import-flat.vmdk copy.loc

And then reate the descriptorfile according my formula directly for import-flat.vmdk.
DO NOT USE THAT QUEMU TOOL

Do you need support with a recovery problem ? - send a message via skype "sanbarrow"
0 Kudos