thelowercasew.com
7Feb/112

VMware Tools Shrink Option Unavailable?

In my recent post on using svMotion to reclaim disk space, I talked about using SDelete to zero out blocks for free space reclamation.  Another way to do this is to use the Shrink option which is part of the VMware Tools.  Duncan's post here gives details on using the VMware Tools Shrink option so I won't go into much detail, but it essentially accomplishes the same goal as SDelete.

I saw a post earlier this week in the VMTN forums that mentioned the Shrink option wasn't available and so I wanted to clear one thing up.  The Shrink option is only available in the VMware Tools if the guest is using thick provisioned disks.  If you're trying to use the Shrink option on a thin provisioned VM (or if you have snapshots on a thick provisioned disk), you'll see the following message in the VMware Tools Shrink tab:

Shrink is disabled for this virtual machine. Shrinking is disabled for virtual disks not used in persistent mode and other factors. For more information, see the documentation for your VMware product.

VMware Tools Shrink Disabled

On a VM that is thick provisioned, you'll see a Shrink tab that looks like the following:

VMware Tools Shrink Enabled

Hope this helps someone who is confused about why they can't use the Shrink option in VMware Tools.

1Dec/104

Watch Your Guest Maintenance When Using VM Monitoring in HA, or “Why does my VM keep rebooting?!”

I'm taking the vSphere Design Workshop class this week, and during class one of my classmates mentioned a scenario he encountered that I hadn't heard of.  The situation involves using VM Monitoring as part of VMware HA and performing guest maintenance.

VM Monitoring is a feature of HA that will automatically restart virtual machines when the VMware Tools heartbeat is lost for a certain period of time.  Normally the heartbeat isn't lost unless something bad has happened to the guest, like a blue screen or other crash.  In that case HA will restart the VM in an attempt to get it back online.

The scenario that was brought up in class involved this feature combined with guest maintenance.  Suppose you need to reboot your VM and keep it running but not booted into the OS for an extended period of time.  Things like booting from an ISO to use imaging software, booting from a GParted ISO to resize a partition, or even going into a VM's BIOS are valid examples of when you might do this.

As you might expect, when the VM is booted from the ISO there are no VMware Tools heartbeats and so HA detects this as a failure and restarts the VM.  I confirmed this behavior in my lab with a test VM by booting with a Windows 2008 R2 ISO and letting it sit at the install screen.  Sure enough after 30 seconds or so the VM rebooted and I saw the following event for this VM (the screenshot is a nice touch):

This virtual machine reset by HA. Reason: VMware Tools heartbeat failure. A screenshot is saved at /vmfs/volumes/493973c5-a2392745-74e6-001d0-97282e4/TestVM/TestVM-screenshot-.png

Seems like an obvious thing but it might take some people by surprise.  At best it's just an annoying distraction or at worst the reboot interrupts some kind of system repair that causes damage to the guest.  There are configurable values to determine how long HA will allow a VM to stay up without receiving heartbeats as well as how many times HA will restart the VM when it has no heartbeats.  So this might not always affect everyone but could still be an issue if you're not careful.

The moral of the story - if you're using VM Monitoring with HA, remember to temporarily disable it if you need to do guest maintenance in which the VM will be down for an extended period of time.

16Aug/104

More vSphere 4.1 Enhancements – Welcome Back PVSCSI Driver!

As I keep digging into documents and KB articles I keep finding more and more things to like about vSphere 4.1.  Today's find has to do with the PVSCSI driver.

With the release of vSphere 4.0, VMware added a new paravirtualized SCSI driver into the VMware Tools that provides better virtual disk performance than the standard LSI driver.  The PVSCSI driver promised to deliver better performance and lower overall CPU utilization for workloads that had high I/O demands.  Unfortunately the PVSCSI driver wasn't supported on virtual machine boot volumes, so folks held off on making this the default SCSI driver for all virtual machines.

After vSphere 4 Update 1 was released, VMware lifted the restriction and now supported the PVSCSI driver on boot volumes.  Folks began considering adopting the PVSCSI driver in all virtual machines similar to how the VMXNET driver is a standard for nearly all virtual NICs.  Soon afterwards VMware came out with a knowledgebase article stating that virtual machines that did not have heavy I/O demands could actually experience worse performance using the PVSCSI driver.  They recommended only using the driver for workloads that had I/O demands in excess of 2,000 IOPS.

With the release of vSphere 4.1 that is no longer a problem and you can use the PVSCSI driver in all circumstances. Want details?  Read on!

26Jul/104

Issues updating VMware Tools with Update Manager

I recently updated a lab environment to vSphere 4 Update 2 and wanted to upgrade VMware Tools on several VMs at once.  I decided to use Update Manager to push out the VMware Tools update, and during the process discovered an issue between Update Manager and newer versions of Windows.  I didn't try any of the following with vSphere 4.1.

I remediated a folder of about seven VMs and to my surprise I saw that only a few of them actually updated.  The others simply sat there and never updated the tools, rebooted, or did much of anything.  Sorting the folder by Guest OS I noticed something - all of the VMs that did not update were running either Windows Server 2008 or Windows 7.

   
Go to top ↑