Windows and Virtualization Tips and Tricks

              Optimal design of a VMware View environment must take several factors into consideration. One of the most important factor is the Storage design. When proper storage design planning is not done, it invariably leads to performance issues in the environment. The most prominent example would be having linked clones in an environment in multiple SATA drives with very little cache space. There is a solution for avoiding such performance issues and that is to have fully deployed (thick disk) desktop. Having fully deployed desktops means spreading the I/O over many spindles instead of crowding all requests to one spindle.

This can be done in two methods:

• Cloning the Desktop VM
• Storage VMotion the Desktop VM

Cloning the Desktop VM

Steps:

  1. From VCenter, right click on desktop VM. Select ‘Clone’

  2. Keeping continuing with the wizard till the point of selecting what to do with the disk

  3. Now select ‘Same Format as Source’

These steps can be done when the desktop is on or off (hot or cold). In a nutshell, the linked clone is read (the latest snapshot of vmdk file that includes all changes down to base disk) and  stand-alone disks are created which are independent of the linked clone storage structure. Thus the file created from the cloning is the thick vmdk file which can now be used as base.

The advantage with this method is that one can verify that the cloning is complete before removing the linked clone VM in the View Manager. The new one can be manually added after verification.

Storage VMotion the Desktop VM

Steps:

  1. From VCenter, right click on Desktop VM. Select ‘Migrate’

  2. Select ‘Change Datastore’

  3. Follow the next steps and select ‘Same Format as Source’ in disk section

The VMs are converted just in the same way as the first method with the only benefit that this can be done without any downtime for the desktop.

This method also has the disadvantage of having no verification mechanism and the necessity of free space to be available on another datastore.

VM Snapshots are not backups. They are just a change log of the original virtual disk. These cannot be considered as backup. There are a number of different reasons that one might use a snapshot for. One of the most used reasons would be for a software upgrade as using a snapshot allows an easy rollback to the machine state prior to the upgrade. If you have some other reasons leave a comment.

• The maximum supported amount in a chain is 32. However, VMware recommends only using 2-3 snapshots in a chain.
• No single snapshot can be used for more than 24-72 hours.
  • This prevents snapshots from growing so large. This is because large snapshots cause issues when deleting/committing them to the original virtual machine disks. So the best method is to take the snapshot, make the necessary changes to the virtual machine, and delete/commit the snapshot as soon as proper working state of the virtual machine is verified.
  • Be especially careful and decisive with snapshot use on high-transaction virtual machines (such as email and database servers). These snapshots tend to grow in size very quickly, filling datastore space. Commit snapshots on these virtual machines as soon as you have verified the proper working state of the process you are testing.
• If using a third party product that takes advantage of snapshots (such as virtual machine backup software), regularly monitor systems configured for backups to ensure that no snapshots remain active for extensive periods of time.
  • Snapshots should only be present for the duration of the backup process.
  • Snapshots taken by third party software (called via API) usually may not show up in the vCenter Snapshot Manager. Routinely check for snapshots via the command-line.
• Lot of snapshots in a chain or large sized snapshots cause decrease in the virtual machine and host performance.

1. Make complete backup, then shutdown Increase_Space_VM.
2. Open ssh session to ESX host containing the Increase_Space_VM.  Change directory to /vmfs/volumes/<specific-LUN-holding-VMdisk-files>/<Increase_Space_VM>/
3. Run command:  vmkfstools –X 25G Increase_Space_VM.vmdk

   -X specifies to extend the disk.  25G is the new *complete* size.  In my example, I started with a 10gig C: drive and I wanted to make it 25gig (25G).  

4. Power off Spare_VM.  Edit settings on Spare_VM, adding Increase_Space_VM.vmdk as a second hard disk
5. Power on Spare_VM.  Once booted into Windows, open a command prompt
6. Once at the command prompt, run disk partition tool DISKPART. (see screenshot at end).

   Note, Disk 1 is shown at 25 GB, with 15GB free.  This is Increase_Space_VM’s C: drive, mounted as E: on Spare_VM.  10GB is in use, and can now be extended to 25GB total.  In the screenshot, you’ll see the syntax for selecting the proper disk, proper volume, and then typing extend.  Quit out of DISKPART and power-off Spare_VM

7. Once Spare_VM is powered-off, Edit the settings to remove the 2^nd hard-drive.
8. Power on Increase_Space_VM.  Once booted up, C: will now be the full 25GB instead of 10GB.