Blog: VMware

VMware PowerCLI is a set of Windows PowerShell snapins that provide access to the VMware infrastructure just like the vSphere client.  It has 165 commandlets.  This will connect directly to hosts just like the vSphere client will, so it can be used to manager smaller installations.  While very powerful scripts can be used for doing just about anything, here are some simple examples:

• copying ISOs to and from the datastore
• powering on or off machines
• rebooting machines
• seeing how much space a machine is taking up

There are many scripts already written and available on the net, so search around before going to very much trouble to write your own. [more]

You can download PowerCLI from http://communities.vmware.com/community/vmtn/vsphere/automationtools/powercli.  This page has several links, including a link to a getting started guide.

After installing the 2482017 and/or 2467023 Microsoft patches you will be unable to connect from the VMware View Connection Server if your View Client  has a build number lower than 353760.  Connection attempts to the VMware View Connection Server will fail.  To fix this problem you can either uninstall the Microsoft patches or upgrade your View Client to a newer version. [more]

Click here to download the VMware View Client patch.

Click here to read the VMware knowledge base article concerning this issue.

On any VMware virtual machine running Windows 2008 or 2008 R2 that was created using v4.1, the advanced configuration parameter disk.enableUUID is set to TRUE. Basically, this enables application-level quiescence in the VM. If the VM was created on ESX prior to v4.1, the advanced configuration setting does not exist. So, if you want to get application consistency on a VADP (vStorage API style) initiated backup, it won’t happen if that setting isn’t set to TRUE. This is a problem because a number of vendors (CommVault included) don’t support this feature yet. Since it is a default for new VMs, they won’t back up correctly.

The bottom line is... make sure you are absolutely sure you are getting application consistent backups by checking the app logs on the VM when doing the backup. You may not be getting as consistent of a backup as you think.

I run a Windows 7 virtual machine when I need to connect to customer sites.  From this VM I frequently create an RDP session on a customer server then run the vSphere client to connect to the console of multiple VM's.  I ran into a problem where the vSphere client would "capture" my mouse/keyboard in the console session.  Normally you would press Ctrl-Alt to release the mouse, but unfortunately when running from a desktop VM, this releases for the VM and not the connected RDP session.  The only way to get out of this is to force logoff of your RDP session from different session.

My workaround was to create a new key combination through VMware Fusion to send Ctrl-Alt to the VM.  I believe this same technique will work for VMware Workstation also.

I had an IT consulting customer email me requesting assistance with extending the system partition on a Windows 2003 virtual machine. The partition had been running low on disk space for a while. The customer had extended the vmdk using VMware, but was unable to extend the partition using diskpart. This is normal behavior for a Windows 2003 system so I scheduled downtime so that I could use VMware Converter to fix the problem.

I have done this operation a number to times in the past. You simply tell Converter to convert the VM and target the same ESX cluster with the imported copy. During the operation, VMware gives you the option to change the partition size. Windows recognizes the partition size change at first boot and you are good to go. However, the customer failed to tell me that they had un-marked the c:\ drive partition as active while trying to get the disk to extend. When I shut the VM down to clone it, it never came back up. Neither did the imported copy. Both were completely useless. They would boot to an “Operating System not found” error. [more]

I tried fixboot and fixmbr from the recovery console but neither worked. I ended up restoring from a CommVault backup. Later, based on some comments from coworkers, I decided to see if I could fix this problem by mounting the disk to another VM and adding back the “active partition” status. I mounted the vmdk that was broken to a Windows 2008 server and using disk manager re-marked the partition as active. Sure enough, after dismounting from the temp VM the original VM booted up no problem. Just one more reason to use virtual machines.

During this last maintenance window for a customer, I needed to update and recompose their linked clones and then log in and test the various applications to make sure everything was working properly. After the recompose had completed, I fired up the View client only to be greeted with an error message that said “The View Connection Server connection failed (null).” This was obviously a problem. After some quick searches on the VMware KB, I found an article which states “View Client 4.5.0 or earlier fails to connect to View Connection Server if Internet Explorer 9 Beta or Windows 7 SP1 Beta is installed on the same client system.”

I had IE9 Beta installed. After removing it (and rebooting), the client connected up just fine and all was good again.

One of our new customers using VMware has not been happy with the performance of some of their virtual machines that had been setup before they were our client. Specifically, a couple of their Citrix VMs and a SQL Server 2005 VM have been “sluggish since they were built” according to the IT staff. I did some basic diagnostics on the SQL Server VM and it did seem to have some performance problems. However, since they had already bought a new physical server and started moving the databases to the new install we didn’t spend much time trying to make the VM run well. We decided to upgrade to VMware vSphere v4.1 upgrade before attempting to address any of the performance issues, since less than stellar performance on virtual terminal servers was normal on VMware v3.5.

During the upgrade, I needed to vMotion some of the VMs around to take down one of the ESX hosts. I kept getting a very generic error on several of the VMs and the migration would fail. I lmust have ooked at every setting a dozen times until I finally just shut the VM down and opened up the VMX file to see what might be causing the issue. The problem was that the person who had built the VMs originally had included processor affinity settings in the VMX file. This binds a VM to a specific subset of the physical processors/cores on the ESX hosts. For example, on the SQL Server VM, it was bound to cores 0 & 1. With this setting, ESX was forced to schedule core 0 & core 1 for all operations even though the server had 8 cores. Additionally, on ESX, the service console has processor affinity on cores 0 & 1, but it holds the highest priority. So basically the SQL Server VM (and the other VM I found that was co-scheduled on cores 0 & 1) were fighting with the service console for processor cycles. After removing the processor affinity, the CPU wait time counter in vCenter for that VM dropped 6x. I ended up finding 10-12 VMs with processor affinity set, so that explained why the performance was terrible. 

The moral of this story is to not manually schedule the processors when you configure ESX or Virtual Machines.  Chances are the ESX schedule will be much better than any manual configuration you could put together.

I was doing a physical to virtual conversion on a Windows 2003 Small Business Server. After the conversion, I shutdown the old physical server and booted the virtual server. I started the VMware tools installation and it got an error warning that it could not locate the path to My Documents to write temp files. Since no network interfaces (NICs) were available it did not load the SYSVOL and therefore could not find domain shares. I also could not change the My Documents redirection because it would not allow me to load the Domain Group Policy. The flexible NICs I initial tried to use did not work since VMware Tools could not install and the system did not have a driver available. The system did have a driver available for Intel E1000 NICs, I changed the NIC type to E1000 and rebooted. Windows installed the driver allowing the SYSVOL to load and allow me to install VMware Tools.

Not too long ago I had a problem updating my virus definitions on a VMware virtual machine.  When I tried to update my Symantec virus definitions on my virtual machine, I kept getting an error message saying my machine could not access a long-named vmdk file.  It said if this file was on a remote computer, I should check my connection, and if it was not, I should check my hard drive (or something along those lines).  The message gave me the option to Retry, Abort, or Continue.  Retry and Continue both made the same error message pop up, and Abort shut my vm down (without deleting some lck files, preventing me from restarting my vm until I manually deleted those).  I tried running different versions of VMs (XP and two Windows 7 machines) and got the same error.   I also didn’t get the error when running Microsoft Updates…only Symantec LiveUpdate.  I had to reinstall VM Workstation to get it to work and I haven’t gotten that error since.