Convert vmdk disk from Auto-growth to Preallocated

I made the unfortunate decision not to preallocate my 100GB C: on my SharePoint development machine. Since it was set to auto grow, only after a few months I had no less than 9 vmdk files, and the drive had ballooned out to over 200GB. With SSD space precious I had to try and compact this VM. Using the "Compact" tool within the VM settings didn't seem to make much of a difference at all. What I needed to do, so I thought, was "shrink" the vmdks. After reading a lot of very out of date help/forums from VMWare, it looked like I needed to fire up the vmware-vdiskmanager.exe and shrink the vmdk files via that. All good so far. Instructions lead me to believe I had to mount the disks first and prepare them. Since I am running Workstation 8, I think these instructions were quite out-of-dated. If you are interested you can mount/map a vmdk files to your host and browse it's contents (without the VM started!) - pretty cool! But this was not going to help my issue. Turns out I could skip the "mount and prepare" steps and lunch straight into the "shrink".

I located the vmware-vdiskmanager.exe at C:\Program Files (x86)\VMware\VMware Workstation and ran the command (-k is for shrinking a vmdk):

vmware-vdiskmanager.exe -k d:\MyVM\MyVeryLargeDisk.vmdk

Shrinking began, and I thought I was in the home straight now. On the first of the 9 vmdk files, the shrinkage was extremely poor (your mileage may vary). It only shrink about 2%. I tried this on the remaining vmdk files and the result was the same. Shrinking had not solved my problem, and in my case the overall VM reduced from 240BG to 235GB. I have no idea why shrinkage was so ineffective, especially as I knew I had a good 30% of free space within the VMs themselves. Plan B.

Since my D drive was preallocated at 50GB, there was 1 nice file of size 52,428,800kBs (50 x 1024 x1024). I need to convert my ballooned C drive into a prealloacted drive. I tried the follow command:


vmware-vdiskmanager.exe -r d:\MyVM\MyVeryLargeDisk.vmdk -t 2 d:\MyVM\newsmallerdisk.vmdk

The console app started ...
..."Creating disk 'd:\MyVM\newsmallerdisk.vmdk'" ...

And eventually (after about 3 hours on a SATA drive)
  Convert: 100% done.
  Virtual disk conversion successful.

Last steps were to :

1. go into VMware Workstation
2. open the VM (not power on)
3. remove the non-preallocated hard drive
4. add the new pre-allocated hard drive (newsmallerdisk.vmdk)
5. Save and Start.

Done. I could then backup and delete those remaining old 9 vmdk files and happy days. Moved everything back to my modest SSD.

PS - some of those options like "-t 2" ... related to the disk type:

  Disk types:

      0                   : single growable virtual disk

      1                   : growable virtual disk split in 2GB files

      2                   : preallocated virtual disk

      3                   : preallocated virtual disk split in 2GB files

      4                   : preallocated ESX-type virtual disk

      5                   : compressed disk optimized for streaming

      6                   : thin provisioned virtual disk - ESX 3.x and above

SharePoint Dev Exam - 70-573 - Study Links

This excel spreadsheet contains links to useful articles that may help you whilst studying for the Microsoft SharePoint 2010, Application Development Exam.

Most of this is based off the list Becky Bertram put together so a big thanks to her.

I used this list to also track my progress, kind of like a timetable.

Hope it helps. You can download the spreadsheet here.

Site Provisioning Techniques

Whilst researching provisioning techniques, these are some notes I recorded.

Feature stapling

• Extend the existing site definition.
• DISADV: Only activated on provisioning time – so won’t affect already existing sites.
• DISADV: Can’t provide NEW site definitions with feature stapling
• DISADV: Feature stapling is activated before module or list element is activated in ONET.xml – can cause issues
• DISADV: Doesn’t work if provisioning Site Templates or Web Templates

Site Templates

• Creates a solution package (WSP)
• ADV: Can be moved between any environment bring with it all the libraries, lists, and optionally content
• ADV: Can provision sites using alternate xml definitions (using WebTemplate element and CustomSchema attribute for ListInstance element)
• ADV/DISADV: Can be imported into Visual Studio and tweaked, but there are an enormous amount of files.
• DISADV: Not supported when publishing features are enabled.

Web Templates

• Uses the WebTemplate element in Elements.xml, together with onet.xml site definition file
• DISADV: Cannot use feature stapling ... BUT since we can modify onet.xml directly and deploy a new version anytime, there’s no need to feature staple.
• DISADV: Variations won’t work with Web Templates BUT workarounds do exist.
• DISADV: No VS2010 template, but once a copy of onet.xml (from /site templates/*) is made then just add elements.xml. Not to hard.
• ADV: Supports both FARM Sandboxed Solutions. (site collection scoped for sandboxed solution)
• ADV: Feature based
• ADV: Supports Cloud deployment
• ADV: Can utilise the Publishing Feature in web templates (unlike site templates)
• ADV: Can easily change onet.xml and redploy it to affect all new sites. (won’t affect old ones since there is no runtime reference to them)
• ADV: Upgrades to SP2015?
• ADV: Hierarchies can be easily created using Feature Receivers.

Site Definitions

• Consist of WebTemp*.xml (how the definition is visible) and ONET.xml (contains the actual definitions for site provisioning)
• Site created off site definitions store identity in: SPWeb.Template, SPWeb.Configuration, and SPWeb.TempalteId
• ADV: Deploy via Farm Solutions, files located on the file system, but can’t do sandboxed solution (so that could be a disadvantage)
• ADV: Site Collection features are not activated in sub sites (unlike in SP2007)
• ADV: Can feature staple
• ADV: Visual Studio 2010 has a site definition template.
• ADV: Variations will only work with Site Definitions (not web templates, site templates etc)
• ADV: Hierarchies can be easily created using XML formats.
• DISADV: Not allowed to change the ONET.xml file after it has been used to provision a site. Never ever. Not supported.
• DISADV: No support for Cloud solutions
• DISADV: A lot of messy XML to deal with.
• DISADV: Potentially upgrade issues to deal with. They won’t upgrade automatically as OOB site defs will, so extra costs involved. MS will advise not to use Site Definitions going forward. Our MOSS RAP highlighted our current site defs needed to be remediated. (A bit over kill maybe)

Provisioning Providers

• Replace the onet.xml file with Code, and only use WebTemp*.xml.
• Use an OOB site definition as a starting point
• Inherit from Microsoft.SharePoint.SPWebProvisioningProvider
• Uses SPWeb.ApplyTemaplate()
• ADV: Supports using PortalProvisioningProvider (not foundation) which creates portal site templates (hierarchy files)
• DISADV: Not support for Cloud solutions
• DISADV: Indications from Microsoft are that it won’t be supported going forward and will soon be deprecated.
• DISADV: Can cause an infinite loop when using CallBack.