Move virtual disk to new virtual machine

I am trying to move a virtual disk from vm1 to vm2 but receive the following error:

c4hsas.png
There are no snapshots and I have powered the vm down before I attempted to move it.  The virtual disk is 400GB and I have made sure there is sufficient space on the receiving folder.
NytroZAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Zephyr ICTCloud ArchitectCommented:
You could check your /var/log/vmware/vpx/vpxa.log to see if you have the same error as mentioned here and try the solution mentioned...
Andrew Hancock (VMware vExpert / EE MVE^2)VMware and Virtualization ConsultantCommented:
this suggests, there is an issue copying it to the client and back to the datastore.

a quicker method would be to do this at the console. (e.g. at the keyboard of the host, or remotely via SSH)

There could be a lock on the file.
NytroZAuthor Commented:
Do you have a KB that explains how to do this from the console?
Big Business Goals? Which KPIs Will Help You

The most successful MSPs rely on metrics – known as key performance indicators (KPIs) – for making informed decisions that help their businesses thrive, rather than just survive. This eBook provides an overview of the most important KPIs used by top MSPs.

NytroZAuthor Commented:
I tried moving it to a different folder on the same data store and receive a locked error.


c4hsas.png
Andrew Hancock (VMware vExpert / EE MVE^2)VMware and Virtualization ConsultantCommented:
vmkfstools -i <source datastore> <destination datastore>

Open in new window


see here

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=900
Andrew Hancock (VMware vExpert / EE MVE^2)VMware and Virtualization ConsultantCommented:
Okay, I suspected it was locked....

you will need to find the lock, and this is like chasing the tail on a donkey, and often leads to not finding it and wasting time...

try the following in order

1. check it's not in use e.g. backup program is backing up the file.

2. restart network management agents on the host.

3. restart vCenter Server service

(2 & 3 do not affect VMs on the host).

finally...

4. Reboot the Host server.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
NytroZAuthor Commented:
I see there is a file with _1-ctk.vmdk associated with this disk.  What is this?
NytroZAuthor Commented:
I tried the 4 steps but still the file is locked.
Andrew Hancock (VMware vExpert / EE MVE^2)VMware and Virtualization ConsultantCommented:
You've reboot the host ?

CTK File -

from Anton Gostev from Veeam on CBT:

In essence, CBT is all about CTK files, these are the files which contain change tracking information of the corresponding VMDK file.

The concept is pretty simple, and if you are familiar with AD DirSync control, or Exchange ICS (public folders change tracking) – it is essentially the same: global USN (Update Sequence Number) for each object. CTK file describes the state of each block for tracking purposes, and contain USN for each block in the corresponding VMDK. After any block is updated, it is assigned the new global USN (which is previous USN value that was used on previously processed block plus 1). This way, any application can ask VMware API “tell me if this block was changed since THIS moment”, and the API will easily tell that by simply comparing the provided sequence number with the actual USN on each block. If provided USN is smaller than actual for particular block, it means that the block was changed (and needs to be backed up, replicated or otherwise processed). So multiple processes cannot conflict with each other anyhow. Each process just memorizes the USN corresponding to the snapshot that the application created during processing, and next time it will use the memorized USN to query for changed blocks.

There should be one CTK file per VMDK file, and CTK file cannot grow out of proportion with number of blocks in VMDK (as it stores only 1 record per VMDK block). CTK file is also thousands time smaller than actual VMDK, because it stores only a few bytes of information (USN) for each corresponding 256KB VMDK block (I am 90% sure it is 256KB, used to calculate it once using CTK debug/stats data, just don’t remember for sure – unimportant info escapes my head automatically to prevent overload with useless facts ;) . For the same reasons, I/O overhead is barely noticeable with CBT: change few extra bytes to write for each 256000 bytes of data.

The CTK files are permanent, and should not be deleted after backup/replication.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
VMware

From novice to tech pro — start learning today.