SVmotion of one disk in VMs with multiple disks fails (insufficient disk space on datastore) while same situation in VMs with single disk, works...why?

[NicolaB]

Hi all,

in one of my customers I had to relocate all C:\ drives of the virtual machines to new LUNs (actually every single C:\ drive has its own LUN on a FC disk and we have to relocate them on sata disks, please don't ask me why it's like that )

We have most of the VMs with single C:\ drive (one has a single C:\ drive plus a RDM) and all of them could be svmotioned succesfully.

Unfortunately I have a problem with svmotion with other 2 VMs: both of them have a C:\ drive, a RDM and a D:\ drive - which (the D:\ drive) has not to be migrated

The svmotion of C:\ drive of these 2 VMs fails with this error (copied from CLI):

Use of uninitialized value in concatenation (.) or string at C:/Programmi/VMware/VMware VI Remote CLI/Perl/lib/VMware/VICommon.pm line 1502, line 10.

Received an error from the server: Insufficient disk space on datastore 'sata_SRV_S5_DiscoC'.

I read that the problem could be caused by low free space on source datastore 'cause svmotion does it using snapshot and actually this is free space situation on source datastores of the 2 VMs that fails:

32G 31G 828M 97% /vmfs/volumes/SRV_EXC_DiscoC

23G 23G 355M 98% /vmfs/volumes/SRV_S5_DiscoC

the source free space is very low, but I had the same % of free space in the VMs that svmotioned succesfully, so I don't think this can be a valid reason for the error.

Also the destination datastore has the same size of the source one, and this gave no errors on other VMs (same situation).

The only difference from the VMs that svmotioned succesfully and these VMs is the fact that these 2 that fails have D:\ drives, but with svmotion.pl --interactive I did svmotion only C:\ drive and answered no to the question of svmotion other disks.

Also removing D:\ drive from the VMs before trying to svmotion C:\ drive gave me the same error.

What could be the cause?

Do you have any hints?

Thank you.

[kjb007]

Very true. Makes me think the d drive is not getting removed from the config and/or the perl script is still including it in the size calculation. Can you try to remove the d: drive again, and then make sure the reference in the .vmx file is actually getting removed as well. Also, after removing the D drive, and starting the vm, make sure the flat file vmdk timestamp for the d drive is not being updated.

-KjB

[NicolaB]

I think I'll have to setup a testing environment for all these tests, since I cannot do all this on the customer system...it would also be interesting to know which VM API is used by the script to estimate the size needed on the destination datastore..

[NicolaB]

finally, after waiting for a never arrived answer from VMware Technical Support, I found the issue...

I tried to do svmotion with full CLI and not the interactive way and I understood that if I want to place individual disks I have to specify every disk even if I don't want to move it from the actual location. In my situation I had a VM with:

C: disk in SRV_EXC_DiscoC datastore

😧 disk in SRV_EXC_DiscoD datastore

and I had to move C: to sata_SRV_S5_DiscoC datastore

the problem was that I only specified the change for C: disk, but trying to svmotion in this way will move all unspecified disks to the location of the VMX file, in fact when I specified also 😧 disk in the command line, saying he had to stay in the same datastatore that it was, the whole thing went succesfully.

The bad thing of all this is that svmotion is not so well documented and the vmware support didn't give me any hints in 2 months even if I wrote them the exact commands I typed to do the svmotion.

Thanks anyway to all who tried to help me :smileyblush: