VMware Converting from Thick to Thin

Background

When you create a virtual disk in VMware you are offered to provision it as "thick" or "thin".  Thick meaning a 120GB virtual hard drive will result in a 120GB vmdk file.  Thin meaning the vmdk file will grow based on the actual used space of the virtual hard drive.

As I began creating and converting physical machines or from VMware Workstation to our VSphere servers, I didn't really pay attention to whether they were set for Thick or Thin provisioning.  But as I started exploring backup options of our virtual server farm it quickly became obvious that we needed to convert those machines that were configured as Thick drives to Thin ones so that we could save on backup storage space and decrease the amount of time it was taking to back them up over the network.


But how do you convert one to the other?  Apparently going from Thin to Thick is easy, but doing the opposite is not as straight forward.

From what I've read if you have VMware VCenter, you simply right-click on the machine and convert it, but we don't have that.  Even in VMware workstation there doesn't seem to be an easy option.  I also found some rather elaborate scripts that people have written, but I wanted something a little more fool-proof and something I could control rather than trusting my soul to a script I didn't write.


In the end I found that I could do it using the free VMware vCenter Converter Standalone Client.

How-To

The following are the steps I went through to convert the disks in a virtual machine from Thick to Thin.  In this case I was working with a virtual machine that is running on a VSphere 5 server.  This step-by-step also assumes you're already familiar with the Standalone converter.


1) First shutdown the virtual machine.

2) Open VMware Converter and choose the "Convert Machine" button and follow the wizard.  You will select your source and target.  For my source the virtual machine name was FLAKE so I made my target name be FLAKE_X.  This means my source vmdk file for drive C: happens to be FLAKE.vmdk but my converted one will be named FLAKE_X.vmdk.  Just name your new machine with a suffix you'll recognize later.  

This machine also has a drive D: so the original vmdk file is FLAKE_1.vmdk and after the conversion it will be FLAKE_X_1.vmdk.  You might also consider browsing your Datastore in the vCenter Client before you begin to get a sense of how the current vmdk files are named.

To do this, click on the root (or top) of the list of Virtual Machines, then click the Configuration tab, under Hardware click Storage, then right-click on the Datastore you want and choose Browse Datastore.

3) In my case I'm converting to the same VSphere server (target) but the original virtual machine was on Datastore2 and there isn't enough free space on that volume to hold the converted disks.  So for the target destination I chose Datastore1.  The point here is you might want to do some math to make sure you have enough free space to do the conversion.  If you have sufficient space, choose your target to be the same Datastore as the source as this will save you time when you move the vmdk files later.


4) In the wizard when you get to the Options screen on the section that says Data to copy, choose the Edit button.  In there you will see the pull-down options under the Type column to choose Thin for each drive. After this, no other changes are needed so click to Finish the wizard and the conversion will begin.  Even on a modest sized drive(s) this will take some time, so go to lunch.  My conversion of drives that total 200GB in size estimated 9 hours, so I went to bed.


Another side note of interest.  When running the vCenter Converter client on XP it gives you a percentage of your progress and a time estimate.  When running this on a Windows 7 machine it just says it is running and no time estimate or progress bar so you're left guessing how long it takes.


5) Once the conversion is complete you can move the newly created vmdk file(s) to the same location as the original.  If you created your new VM on the same datastore this will only take a few seconds.  This is that time-saving step I mentioned before.  In my case, since I had a minimal amount of space on the original Datastore I left the new vmdk files alone for now.

To relocate the vmdk files open the vSphere Client, click on the root (or top) of the list of Virtual Machines, then click the Configuration tab, under Hardware click Storage, then right-click on the Datastore you want and choose Browse Datastore.  Drill down until you find your new vmdk file(s) and right-click on it and choose Move to.


6) Now edit the Virtual Machine settings of your original VM (the source) and remove each hard disk from the configuration and then add them back but point to the new "Thin" disk files.  

As a side note, after you click to remove the drives do not click OK on the configuration screen before you add the new drives.  Otherwise it will also remove your disk controller (typically a SCSCI controller) and if you had a unique controller defined you would need manually to redefine it the same as it was before.


7) Start your virtual machine and verify that it boots correctly.


8) Then you can browse the datastore and delete the old "Thick" vmdk files.  

In my case (because of my storage space issues), I powered down the VM again, deleted the Thick files from Datasore2 and then moved the "Thin" vmdk files from the Datastore1 to Datastore2.  Then I edited the VM again to point the drives to the new locations of the vmdk files.

9) When you are finished you can right-click on the newly created VM (the target or FLAKE_X in this example) and choose to Delete From Disk.


Conclusion


Although this is a time-consuming process I estimate we are saving close to a Terabyte in storage space across our VSphere servers and even more on our backup devices.


I just wish I could find a tool for my waistline to convert it from Thick to Thin.


Happy Thinning!!

VMware Converter - SQL_CANTOPEN Error

While working with the VMware vCenter Converter Standalone Client (in my case version 5.0) I kept getting the following error while trying to convert machines:

A general system error occurred: SQL_CANTOPEN: unable to open database file

After some research I find this error message has been around for awhile and also happens with previous versions of the Converter.  Some say network errors can cause it.

In my case it was the CrashPlan backup client that was causing it.  Forcing CrashPlan to sleep during my conversions corrected my issues.  I also read that for some disabling antivirus software corrected it for them.

So basically anything that could be locking files on the computer your running the VMware Converter software on is where you should look and not the machine being converted.  It was driving me crazy and I thought it was the target VSphere Server that was the issue.

Windows 7 - Preparing your computer for first use

After using Symantec System Recovery 2011 (aka Symantec Backup Exec System Recovery) to restore an image backup of a physical Windows 7 machine to a virtual machine using the "Restore Anywhere" option, I was left with a machine that was stuck on the message: "Setup is preparing your computer for first use"

The "Restore Anywhere" option is a way of saying I am restoring to disimiliar hardware.  Also, I tried the restore to VMware VSphere 5 and VMware Workstation 7 and I had the same results.

Below are some steps that helped me resolve this.

While you see the message "Setup is preparing your computer for first use" you can press Shift F10 on the keyboard and you will see a command prompt.
Type in taskmgr.exe and you will get the Windows Task Manager
Look for a process called windeploy.exe and kill it (End Task)
Then you are taken to the Windows Logon screen where you can login normally.

Then follow these steps:

1. Within Windows, Click Start - Run, type 'regedit.exe' and press Enter.
2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\Setup
3. Within HKEY_LOCAL_MACHINE\SYSTEM\Setup you will need to change the following values:

Here is an example of what the registry values could look like
"SetupType"=dword:00000000
 "SystemSetupInProgress"=dword:00000002
 "SetupPhase"=dword:00000004
 "CmdLine"="C:\OOB\Windeploy.exe"
 "OOBEInProgress"=dword:00000001

This is what the values needed to be changed to:
"SetupType"=dword:00000000
 "SystemSetupInProgress"=dword:00000000
 "SetupPhase"=dword:00000000
 "CmdLine"="" (This field should be Blank )
 "OOBEInProgress"=dword:00000000
 
Now click START and run MSCONFIG.EXE

On the General tab you may see it set for Selective Startup, and on the Boot tab you will see a reference to a Windows installation that is in "Recovery".



This is where it is confusing, but on the General tab, under Selective Startup, check the box that says "Use original boot configuration", and you will see it immediately uncheck the "Selective Startup" and check the "Normal Startup".  Also if you now look at the Boot tab you will see another bootable installation.

Now reboot, and you'll likely get a nasty message from the Boot Manager that says it cannot boot.  So you boot from your Windows 7 CD and choose the Repair Option.  It will detect the issue, correct it, and reboot.

And now finally you should have a working Windows 7 machine again.
 

Lock Out

I want to tell a story of a customer that called me yesterday.  I'm sharing this story in hopes that these steps can be of help to someone else in the future.  Their Active Directory domain administrator password was changed somehow and there was no way to login to the primary server (Domain Controller).  This customer is in another state, and I mention this only to point out that my only access to them was from remote across the Internet.

Since I had previously done work for them on their Web Server, I at least had a way to remote in to that server, but since the domain admin credentials were not working I had to authenticate using the Web Server's local admin credentials.  Once connected I used VNC to get to the primary server's console, and we tried various password combinations but could not login as Administrator.

I found a free tool called ADManager Plus, and once installed on their Web Server I was able to query Active Directory and get a list of User Names and could at least see the last time those Users had authenticated.  I knew from my previous work that some of the accounts that existed were disabled, but this tool did not show which ones were active versus disabled. 

ADManager Plus can be found here:
http://www.manageengine.com/products/free-windows-active-directory-tools/download.html

Since we could see at least one account in the list that I recognized as being used by their primary application vendor and knowing that account likely already had Admin privileges, my hope was to login with that account and then reset the Administrator password.  The application vendor was very helpful and gave me several password combinations to try, but unfortunately none of them worked.

The customer also contacted a local IT Vendor and once on site, they tried a procedure similar to the one found here:

HOW TO: Reset your Lost 2003 Active Directory Admin Password
http://www.geeksaresexy.net/2009/03/12/how-to-reset-your-lost-2003-active-directory-admin-password/

The above steps basically have you wrap a password reset tool into a service and it attempts to change the password as the server is booting up.  Unfortunately this didn't work either.  It has worked for many others, which is why I wanted to still reference it as an option.

After some research, I thought perhaps I could use the Net.exe commands in Windows to reset the password, but in order to try I would need some way to get to the primary server's command prompt.

So I downloaded PSEXEC to their Web Server.  PSEXEC is a utility now owned and maintained by Microsoft that allows you to execute remote commands to another machine on the network.

Download PSEXEC here:

http://technet.microsoft.com/en-us/sysinternals/bb897553

So let's say the Primary Server's name in this example is ALPHA.  I issued the following command from the Web Server's command prompt:

psexec \\ALPHA cmd

This allowed me to run cmd.exe (the command console) on the ALPHA server.  And now I could issue commands on the Primary Server.  This is also the step in which we were very lucky (or Blessed).  Typically in order for PSEXEC to do its magic it has to authenticate to the remote machine.  How is it I was able to issue this command when the Administrator account was inaccessible?  I can only assume that this server had previously authenticated before the Administrator password was changed and thus still had a valid security token.  I can't help but wonder that if we had rebooted this Web Server before now, if this step would have been impossible.

I tried using the Net.exe commands on the Primary Server but then realized that for some reason, Net.exe didn't exist on this server.  I'm not sure why since this is Server 2003 it should have been there.  After further reading, using the Net.exe commands might not have worked anyway since this is a Domain Controller.  I still wanted to mention this, as it could prove useful to someone in another scenario.

In the example below, the username whose password we are trying to reset is sunrise and the new password we want is Password2, and the /domain switch is supposed to indicate that we want to change it for the domain user called sunrise as opposed to a local user called sunrise.

net user sunrise Password2 /domain

More information about How to Use the Net User Command can be found here:  http://support.microsoft.com/kb/251394

I then came across some Active Directory commands such as:

dsquery - Query Acive Directory
dsadd - Add Users
dsmod - Modify Users

Please see How To Use the Directory Service Command-Line Tools to Manage Active Directory Objects in Windows Server 2003 here:
http://support.microsoft.com/kb/322684

I also found this site which gives some great examples on using these commands:
http://www.sadikhov.com/forum/index.php?/topic/84286-examples-for-dsadd-dsquery-dsget-dsmove-dsmod-dsrm/

In the end, we had success when I issued the following command:

dsmod user "CN=sunrise,CN=Users,DC=acme,DC=local" -pwd Password2

In the above example:
The username we wanted to change the password for is: sunrise
The Domain Name is: acme.local
The container that holds the username sunrise is: Users
The new password we want is: Password2

Once the sunrise password was changed, I logged into the Primary Server and then was able to change the Administrator password.

So to recap the successful steps:

Open a Remote Console on the Domain Controller
psexec \\ALPHA cmd 

Change the password of an account that already has Administrator Priviledges
dsmod user "CN=sunrise,CN=Users,DC=acme,DC=local" -pwd Password2

Malware hides all files and shortcuts

On several occasions we are called in to look at a computer that has been infected with malware or a virus.  And the malware has hidden every file (and shortcut) on the entire hard drive.  You notice this right away when you click on the START menu and nothing is there.  And when you open the C: drive in Windows Explorer, you also see nothing.

I wanted to document this fix for this for my own quick reference and hope it can be of help to others as well.

From a Command Prompt use this command:

attrib -r -h c:\*.* /s /d

This changes the attributes of each file to not be read-only or hidden and does this for all files and folders including subdirectories. 

Malware can also sometimes mess with file associations and leave you with inability to run EXE files or open documents or shortcuts.  I found this great website with a ready reference of fixes for these types of issues:

http://www.dougknox.com/xp/file_assoc.htm