[WS10] - Recommended to defrag disk, but Utilities menu greyed out.

[sugarmonster]

When shutting down a Win7 guest, I get a message from Workstation 10 saying that a fragmented disk is impacting performance. When I go to the drive settings to defrag it, the Utilities menu is greyed out for that disk.

The VM was created in WS9 on a different host, then moved to a new PC and upgraded to WS10 if that matters.

VM Tools are up to date

The data drive is attached as SCSI 0:1 and is a single 16GB file on the host (so I'm not sure why WS thinks "hard disk contents are stored in multiple files".)

The data drive is not independent and there are no snapshots.

Any ideas?

Thanks.

[OscarDavey]

Hello,

Maybe some of VMware's processes had taken access to vmdk and did not let it free.

Try to do these

1) Restart all VMware services and then try again

2) else reboot host OS and then try again

3) Unmont and mount again vmdk and then try again

4) Remove virtual machine(without removing vmdk), create it again and then try again

Why you do not defrag from guest OS(Windows 7)?

Hope will help.

Your Oscar

[sugarmonster]

I wasn't sure if there was a difference between defragging in VMWare utilities and defragging in the guest OS. I'll try defragging the disk within windows, as well as your other suggestions and see what happens.

Thanks!

[continuum]

There is a big difference - using the VMware util is a good idea and does no harm - when the option is available.
Defragging from inside the VM is a bad idea as this will only enlarge the vmdk without any benefit !!!

The most probable reason why the option is greyed out is a suspended VM - so make sure the VM is powered off before you try again.

Please ignore the first answer you received - none of the tips listed will help you

[sugarmonster]

OK, so VM not suspended and the option to defrag the system disk is available. This is specific to the attached data drive.

I think there's something odd going on with the disk - the VMDK claims that it's a sparse disk, but the "data1-s001.vmdk" file is 24GB.

I tried converting it to a sparse file with vmware-vdiskmanager.exe. That gave me the message "VixDiskLib: Invalid configuration file parameter.  Failed to read configuration file", then proceeded to duplicate disk in the same format with a 24GB data file.

Data1.vmdk contents:

# Disk DescriptorFile

version=1

encoding="windows-1252"

CID=fdebbbd5

parentCID=ffffffff

isNativeSnapshot="no"

createType="twoGbMaxExtentSparse"

# Extent description

RW 2147483648 SPARSE "Data1-s001.vmdk"

# The Disk Data Base

#DDB

ddb.adapterType = "lsilogic"

ddb.geometry.cylinders = "133674"

ddb.geometry.heads = "255"

ddb.geometry.sectors = "63"

ddb.longContentID = "c5a78f55d00e3a78c8d09643fdebbbd5"

ddb.toolsVersion = "9408"

ddb.uuid = "60 00 C2 93 5e d3 50 46-5a b8 f3 fe 58 14 4c 05"

ddb.virtualHWVersion = "9"

Since VMWare is convinced it's already a sparse disk, I wonder what happens if I try to convert it to a monolithic one and back again... (yes, it is all backed up!)

[WoodyZ]

# Extent description

RW 2147483648 SPARSE "Data1-s001.vmdk"

Well according to this is a 1 TB (Terabyte) disk and while is says createType="twoGbMaxExtentSparse" it isn't really.

2147483648 sectors x 512 bytes = 1099511627776 bytes which is 1 TB!

[continuum]

A sparse vmdk has the keyword SPARSE in this line:
RW 2147483648 SPARSE "Data1-s001.vmdk"

A preallocated would use FLAT instead.

You got the expected vmdk when you ordered:
1. larger then 950Gb
2. split in multiple chunks

Sparse split vmdks can use any chunksize - but if the wizard creates them it will use 2Gb slices for vmdks upto 950Gb - if they get larger it uses 2040 Gb slices.
In between 950Gb and 2040 GB a single slice with the desired size is used.
So there are 3 forms of the type

createType="twoGbMaxExtentSparse"

size of name-s001.vmdk	nominal size of the virtual disk
320kb -  2047 MB:- several name*-s*.vmdk + name.vmdk	upto 950Gb -
320kb - 2040 Gb : a single  name-s001.vmdk + name.vmdk	951 Gb - 2040Gb
2040 Gb : several name-s*.vmdk + name.vmdk	2041 Gb or larger - official limit is 8 Tb - real limit is 64 Tb

[jsa]

continuum wrote:

There is a big difference - using the VMware util is a good idea and does no harm - when the option is available.
Defragging from inside the VM is a bad idea as this will only enlarge the vmdk without any benefit !!!

Wait, what? 

I could have sworn that the official VMware line was to first defrag inside the VM, to consolidate files toward the front of the

virtual drive, then to defrag via VM-Utilities, which mostly allowed release of secondary allocations no longer used.

When did it come about that defraging inside the vm Enlarged the virtual disk?

[continuum]

|==1=23=4=| 
Assume thats a growing sparse vmdk  before fragmentation.
= is  a used block and among the used blocks is one file in 4 fragments.
The size of the vmdk on disk now is 9 characters from | ... to ... |
To defragment that file you must copy it somewhere where it can be written in one piece.
So you have to enlarge the vmdk and even if its only temporarily to
|==_=__=_=1234|

Compared with preallocated vmdks the growing ones have a reducted life-span and you want to reduce any unnecessary writes.

If you to want to do maintenace work and improve performance I would suggest something else:
Power off the VM - add a brandnew blank growing vmdk of the same size.
Then boot the VM into your favorite LiveCD and partition the new vmdk and quickformat it.
Then use robocopy or rsync or similar and copy file by file.
Copy the rarely used first and everything that changes frequently last.

Or - if you dont like the manual work - create a full-clone occasionally.

> that the official VMware line was to first defrag inside the VM,

That probably was about preallocated or thick provisioned vmdks - I doubt that a lot of the experienced users defrag their growing vmdks from inside the guests.

[jsa]

That's an interesting, if contrived example.

But your typical windows defrag operation doesn't need to allocate more space, and in fact doesn't do it that way.

It attempts to consolidate fragmented files to consecutive disk sectors, by moving many smaller files

into the locations previously occupied by fragmented files, and thereby bringing all the fragments together

and eliminating small allocations of un-used space throughout the disk, and consolidating them at

the end of the disk.

I've never once defragged a real hardware and had it ask me to run out and buy a bigger disk so it

could complete the process. 

[sugarmonster]

continuum wrote:

Sparse split vmdks can use any chunksize - but if the wizard creates them it will use 2Gb slices for vmdks upto 950Gb - if they get larger it uses 2040 Gb slices.
In between 950Gb and 2040 GB a single slice with the desired size is used.
So there are 3 forms of the type

createType="twoGbMaxExtentSparse"

size of name-s001.vmdk	nominal size of the virtual disk
320kb -  2047 MB:- several name*-s*.vmdk + name.vmdk	upto 950Gb -
320kb - 2040 Gb : a single  name-s001.vmdk + name.vmdk	951 Gb - 2040Gb
2040 Gb : several name-s*.vmdk + name.vmdk	2041 Gb or larger - official limit is 8 Tb - real limit is 64 Tb

Ah - that was the missing information I couldn't find documented anywhere! That explains what is going on with the disk sizes - thanks. I did ask for a 1TB disk so that all makes sense.

[sugarmonster]

Just to answer my own question about the greyed out utilities menu... I removed the virtual hard drive and re-added it, pointing it at the new VMDK. When I did that VMWare asked me to upgrade it to the latest hardware version. After that the utilities menu appeared, the VMWare defrag operation completed and I don't get any warnings about fragmentation any more... I don't know why it was greyed out in the first place, something obviously got a bit confused when I moved everything to a different physical host.