move a VMDK within (!) a datastore to another folder

[wuestenfuchs]

Hello,

I have a question:

Recently we upgraded a number of virtual servers from Windows 2003 to 2012. Actually, in each case we installed a new VM, detached the data disks from the old 2003 VM and attached it then to the new 2012 VM. Of course, this way the VMDK file remains in the folder of the old VM. When I then delete the old VM, the new one has its folder with its normal config files and the VMDK where the OS is installed and the data VMDK remains in the folder of the old VM which is empty otherwise.

At some suitable occasion (reboot for Windows updates) I would like to shutdown the new VM and physically move the data VMDK to the new VM's private folder and then restart it.

Unfortunately, when I do so with the datastore browser of the vSphere client, then it acuatlly copies the VMDK to the new folder and then deletes it from the old folder.

Since it is a substantial amount of data (several hundred GB), I would like to avoid this, of course.

I have not found a "GUI" method of really _moving_ a VMDK from one folder to another folder within the same datastore without copying it.

I can SSH into an ESXi host that has access to the datastore and then use "mv" on the shell level. This seemed to work fine with some small test VM(s).

But is it safe to do it this way? Is there some other (official) way?

Thanks for sharing your insight or opinion!

Kai-Uwe

[wila]

The supported/safe way to do this is using either GUI or the vmkfstools command.

It is strongly discouraged to use the mv command as it is unsupported and does not behave in the expected way. It might actually seem to work, but there are no guarantees.

I just verified for you on vSphere 5.1 that a vmkfstools -E (vmkfstools rename) does indeed update the file restructure the way you want. It just updates the directory structure without actually copying the data, just like a unix mv would do.

--

Wil

[wuestenfuchs]

Unfortunately, the vmkfstools command does not seem to work:

C:\>vmkfstools -h esx2.ars.de -E "[Test] Test/PXE-Boot-Test.vmdk" "[Test] Test/Test.vmdk"

Attempting to move disk [Test] Test/PXE-Boot-Test.vmdk

Unable to move virtual disk :

The source name exists, the target name in this case is even in the same folder and the disk is not attached to any VM.

Yet it still fails and does not even say why! This is totally useless, I would even say embarrassing for VMware.

It is strongly discouraged to use the mv command as it is unsupported and does not behave in the expected way. It might actually seem to work, but there are no guarantees.

It still looks like I have not other option. Unfortunately, your warning - in this vague form, without citing documentation or even a technote - is useless, too. Could you please elaborate, WHY you think so?

[wila · Accepted solution]

Hi,

The command vmkfstools is a command to be run at the server command line, not from windows.

like:

vmkfstools -E /vmfs/volumes/datastore1/foo/test.vmdk /vmfs/volumes/datastore1/bar/test.vmdk

wuestenfuchs wrote:

It is strongly discouraged to use the mv command as it is unsupported and does not behave in the expected way. It might actually seem to work, but there are no guarantees.

It still looks like I have not other option. Unfortunately, your warning - in this vague form, without citing documentation or even a technote - is useless, too. Could you please elaborate, WHY you think so?

My warning is vague because a quick google didn't give me an exact point in the documentation.

Here's an oldie thread on it: Re: renaming VMDK Files

I do however am 100% sure that the mv command isn't supposed to be used for moving virtual disks.

There are several reasons:

The vmkfstools command was especially written to create/copy/clone/rename virtual disks. This command takes the  hosts management resources into account. Also will write the blocks are written in the most optimal way. This is also the command that is fully aware of mechanisms like thin disks and sparse disks.

This is also the only command that VMware will support if you end up getting into trouble.

[wuestenfuchs]

The vmkfstool is also available via VCLI. Since you did not write anything about WHERE to use it, using VCLI was the logical next step.

It is supposed to work there the exakt same way. I will give it a try via SSH on the host, though.

And since I only want to move/rename a VMDK, block order does not play any role in any way!

[wuestenfuchs]

I tried vmkfstools -E via SSH on the host and sure it works there. Just like mv would do.

I am happy with using vmkfstools -E on the host just like I would have been with mv, I justs did not know about it.

Thanks for solving the confusion on my side!

However, vmkfstools as a remote VCLI command is definitely broken, at least in 5.5 that we run.

It SHOULD work similarly (just with different path name syntax) too, in theory.

[wila]

Yes I noticed you used VCLI and agree it should work.

I also know I've had problems with getting the syntax exactly right (using the [store] ) in the past myself.

As you mention, it's kinda picky and the error messages aren't always clear.

Using it directly at the host however I never had that problem.

re. does the same as mv. Yes in a way it does, I know. The problem is that the vmfs file system is a black box and not too much about it is easy to find. The VMware engineers always recommend to use vmkfstools for managing the virtual disks on the vmfs filesystem.

I also read that vmkfstools writes metadata in the main folder, but again ... no official documentation on that which I can find now. In a case like that, mv appears to work fine, unless you need that meta data at some point in time. Wish I had some solid documentation to point you towards on those nitty gritty details, but I'm not even sure that it is publicly available.

--

Wil