Eric Siebert has once again started a poll to ask people to vote for their favorite VMware & Virtualization blogs. On his vSphere-Land page you can see the results of the previous voting. This year Eric has added some extra categories for which you can vote.

When casting your votes please keep the following in mind about the blogs.

• Longevity - Anyone can start a blog but it requires dedication, time & effort to keep it going. Some bloggers start a blog only to have it fall to the wayside several months later. Things always come up in life but the good bloggers keep going regardless of what is happening in their life.
• Length - It’s easy to make a quick blog post without much content, nothing wrong with this as long as you have good content in the post that people will enjoy. But some bloggers post pretty long detailed posts which takes a lot of time and effort to produce. The tip of the hat goes to these guys that burn the midnight oil trying to get you some great detailed information.
• Frequency - Some bloggers post several times a week which provides readers with lots of content. This requires a lot of effort as bloggers have to come up with more content ideas to write about. Frequency ties into length, some do high frequency/low length, some do low frequency/high length, some do both. They’re all good and require a lot of time and effort on the bloggers part.
• Quality - It all comes down to whats in the blog post regardless of how often or how long the blog posts are. After reading a blog post if you come away with learning something that you did not previously know and it benefits you in some way then you know you are reading a quality post. Good quality is usually the result of original content, its easy to re-hash something previously published elsewhere, the good bloggers come up with unique content or put their own unique spin on popular topics.

To try and influence your vote a little, I have listed my best-read posts from 2011 for you

1. How to run ESXi stateless with vSphere Auto Deploy.
2. vSphere 5 licensing with vRAM isn’t that bad at all.
3. Enabling VMware View 4.6 PCoIP with dynamic IP address.
4. Changing NetApp Storage policies from Non-Alua to Alua.
5. To USB or not to USB, how do you boot your ESXi host?

My all time best-read posts:

1. How to run ESXi stateless with vSphere Auto Deploy.
2. Unable to access a file since it is locked
3. Storage how to size your LUNs
4. Setting timezone in ESXi or not
5. My new whitebox ESX homelab

See full post at: Vote for your favorite VMware & virtualization blogs

Normaly when installing a vSphere environment for new customers, I wait with entering the correct licenses until the environment is ready and can be moved to production. Until today I never ran into any issues with that since most of our customers buy Enterprise or Enterprise Plus edition. Today I discovered that after entering a vSphere Standard license, you might run into an issue with DRS where the affinity rules stay in effect.

As best practice we usually put the vCenter VM on the first host in the cluster using a VM to Host affinity rule in DRS. A few days after entering the vSphere Standard license which doesn’t allow DRS, I tried to move the vCenter VM to a different host, but this wasn’t allowed because a VM to Host affinity rule was still active. When checking the cluster settings, DRS was still disabled. When I enabled DRS, without clicking OK, I could see there still was a host-affinity rule defined in the settings.

I decided to remove the rule and the host-group and VM-group.

As expected, when clicking OK I received an error telling me that DRS was not a valid option for this license.

I did hope however that the deletion of the rules would still have been applied. Unfortunately not. When opening the cluster settings, enable DRS again, I could still see the rule and the groups were present. Only way to get rid of this was to enter a NFR license key for the Enterprise (or Plus) edition, enable DRS, remove the VM- and host-groups, remove the rule, click OK to see the changes applied. Go back to Cluster settings, make sure they’re all gone. Disable DRS and remove the NFR license.

Sounds like a little bug to me and I therefore create a support call with VMware for this.

PS: Frank Denneman hinted me this is probably only for “MUST RUN” DRS rules.

See full post at: vCenter DRS rules bug when downgrading license

Today, when performing a VMware Health Check, I came across a strange issue with a customer of mine. Well, issue is maybe a big word, but I discovered the VMware Tools version some of the VMs had running, were newer than the VMware Tools version from a newly installed VM. To make sure I double checked by removing the VMware Tools and reinstalling them, again the VMware Tools version was less than the tools version of the suspicious VMs.

The VMs with the very high VMware Tools version had version 8448 running. When checking the VMware Tools about page, it showed:  8.8.0 build 471268. The other ‘normal’ VMs had VMware Tools version 8300. The Windows VMware Tools about page showed 8.3.12 build 493255. The vSphere environment I was running this on had vCenter 4.1 and ESXi 4.1 update 2 build 502767.

After some help on twitter, it turned out these VMs had been created from a VM that was originally created in VMware Workstation !!! I removed the VMware Tools from the Windows VM and reinstalled them, since I’m not sure if there is a difference between the VMware Tools installed when the VM is on an ESXi host and the VMware Tools in VMware Workstation or Fusion. Upgrading them to the ESXi version didn’t work because, of course, the existing build number is higher than the version I would like to install.

I don’t have any real answers for you yet, but I’m trying to find out more whether there are potential issues when running the VMware Workstation VMware Tools in your ESXi VM. My first guess would be that it wouldn’t matter, otherwise VMware had probably done more checking or given other alarms when trying to upgrade the tools.

If you have all the answers, please tell me in the comment section.

On twitter I was pointed to this list: VMware Tools versions and Packages.

A big thank you to  Ewan Leith and Alexander for their twitter help.

See full post at: VMware Tools version number higher than expected

At the Dutch VMUG on December 9th, 2011 I was asked to do a little interview with Alex Rosemblat from VKernel. We spoke about the presentation I did at the VMUG in which I talked about my VMware vSphere Health Check. See the pages about the Health Check in the top menu bar.

Also check out VKernel’s latest release of VKernel vOperations Suite which offers a great way to do performance and capacity management of your vSphere and Hyper-V environment.

Sorry Alex about the part after 5min10

See full post at: VKernel interview at Dutch VMUG

When visiting customers I noticed that the VMware admin often doesn’t really know how much free space is left on the datastores and wether action is needed to free up space or get extra capacity. When I show them the datastore overview in the VI Client that shows the warnings and alerts for the datastores, it turns out that they don’t often look at this page because it gives too many false alarms. These false alarms happen because the default values right out of the box are set at 75% for a warning to trigger and 85% for an alarm to trigger. In most cases this is much too soon as the next image shows you.

In general I use as a rule of thumb a required free space per datastore of 40GB. Usually these 40GB can accomodate enough snapshot space during nightly backups and storage migrations to prevent the datastore from filling up. Those 40GB free space I would like to monitor through my vCenter alarms which is very easy if all datastores would be equal in size, you could than edit the default alarm to reflect the new % settings. Unfortunately in most environments, not all datastores are equal in size and you would have to change the alarm on each datastore.

There is an easier way, you can create folders and assign alarms to folders and move datastores of the same size into these folders. This will give you a much better view of your datastores and alarms. The alarms you see are now “real” alarms that really require your attention. See how the next image gives you much less alarms and only shows warnings and alarms on datastores that really are below 40GB.

I should warn you though… my friend Duco Jaspars tipped me about this KB article: “Defining alarms on datastore folders can cause vCenter Server 4.x to becomes unresponsive“, although I have not yet ran into this issue with the customers were I implemented this.

In the next version of vCenter I do hope VMware makes a change and enables the use of GB on this alarm instead of just a percentage. You could than just set a GB value and it would be equal to all datastores. In the current situation you have to work with % of the total size of the datastore and especially with large datastores this can be quite a challenge, especially since you can only enter integers and no decimals. See the table below:

As you can see you’ll have to be a little creative with the numbers to get the warnings the way you want them.

See full post at: How to make vCenter datastore alarms useful

The VMware vSphere Health Check performs quite a number of checks but doesn’t really explain why values are good or bad. Today I released three new sections that explain the theory behind the CPU, Memory and Storage checks. Click the “Health Check” button in the menu bar of my blog to access these new sections or just follow the links below:

• CPU health check
• Memory health check
• Storage health check

See full post at: VMware vSphere Health Check – CPU Memory and Storage checks explained

At the Dutch VMUG event 2011 I gave a presentation on how to check your VMware environment to make sure it is healthy. When creating the presentation I had a lot of doubts because I was afraid everyone would think these points were very obvious. But on the other hand, when visiting customers and doing these health checks for them, I found a lot of those “obvious” issues in their environment. I decided to stick to my plan and test the audience and it turned out they were very happy with my presentation and I saw a lot of people in the audience taking notes. The replies afterwards also showed that for many people there were a lot of eye-openers in this presentation. I therefore decided to convert the power point presentation into this blogpost and hope my readers find it a valuable health check.

In the top menu bar of this blog you’ll find the “Health Check” section. There you can find the various pages that together give you a complete health check.

See full post at: VMware vSphere Health Check

Ever had it happen in your environment? Committing a snapshot on a VM fails and you can’t get your VM to boot again because there are disks missing. This could happen because when initiating Delete or DeleteAll snapshots, the snapshot details are deleted from Snapshot Manager, then the snapshot files are consolidated and merged to another snapshot file or to the virtual machine parent disk. If the consolidation fails, there were no snapshots shown in the Snapshot Manager, but the snapshot files were still being used on the datastore. This can cause the datastore to run out of space.

Unfortunately today this happened for me too, but it has been the first time this happened in a vSphere 5 environment. And therefore it was also the first time I noticed a new feature in VMware vSphere 5 / vCenter 5: “consolidate snapshots”. When a VM has snaphots present on the datastore but they don’t seem to be linked to the VM anymore, vSphere 5 will detect this and report an error on the summary tab: “Virtual machine disks consolidation is needed”.

I quickly found there is a new option now under the snapshot menu. Right click the VM, select Snapshot and select the new option “Consolidate”. Now vSphere will start a new consolidation.

A great new option that probably can save quite some work for vSphere admins. See these KB’s for more info:

• Consolidating snapshots in vSphere 5
• Consolidating snapshots

Unfortunately in my case, this didn’t work and I immediately got a general I/O error, even though the datastore had enough space left. I eventually had to revert to my last Veeam backup because that was more recent that going back in time to the day the snapshot was made.

See full post at: New vSphere5 feature: Virtual Machine disks consolidation is needed

Today VMware released their Technical Preview of the VMware View PCoIP client for OSX. We’ve all been waiting for this since the release of VMware View 5 and today I finally got to test it on OSX. Of course I had to install it right away and run a test drive from work to my VMware View 5 lab at home. Even though I have only a small uplink to my ISP, I was able to run a Youtube movie at 480p without issues. Running it at 720p works fine to when windowed, but 720p full screen is a bit too much for the small upload I have and you can see some small hick-ups. But still a reasonable viewing experience.

From the VMware website :

Features In the VMware View Client for Mac OS X

• Support for Intel-based Macs
• PCoIP protocol optimized for VMware View 5
• Full screen support for Mac OS X Lion users
• Copy and Paste plain text between View 4.x virtual machines and Mac
• Copy and Paste text, formatted text, and graphics between View 5.x virtual machines and Mac
• Support optional RSA authentication
• Enhanced certificate checking
• Add up to 4 VMware View server shortcuts in VMware View Client

Installing the client

Installing the View Client with PCoIP is very easy. After downloading the DMG image, open it, and drag the application to the applications folder.

After opening the View Client, you’re presented with the connections screen in which you can add up to 4 View Servers.

Press the big cloud button and add your remote host. When the connection is made, you’ll see a security warning depending on the certificate you implemented on your VMware View Security or Connection Server. In the settings menu you can change the required action for the security level of your connections.

Next you’re presented a logon screen and after your logon completes you’ll see the desktops that are available for you. Do pay attention to the little pull down menu below the desktop, which will let you choose between RDP and PCoIP. Note: In this release ONLY the PCoIP protocol is supported. Connecting over RDP can only be done with the View 4.6 client for OSX.

Once you selected the desktop, you’ll be logged on to your desktop and you’re finished. Happy working!

From the release notes:

Known Issue: Unable to connect to Windows 7 based virtual machines using the RDP protocol. Workaround: Access your Windows 7 desktop with the higher performance PCoIP protocol or use the older VMware View 4.6 client with Microsoft Remote Desktop Connection to access Windows 7 based desktops with RDP.

Items Under Consideration for Future Major Client Releases Include:

• Use of Multiple displays/monitors
• Printing to locally attached printers
• Full screen support for Mac OS X Snow Leopard
• SmartCard authentication
• USB device connectivity

See full post at: VMware View Client with PCoIP for Mac OS X

When deploying XenDesktop in a VMware environment, you could run into the following error when trying to connect your XenDesktop host to your VMware vCenter environment: “The hosting infrastructure could not be reached at the specified address”. This is due to the fact that VMware vCenter only allows https connections by default. To make your XenDesktop server use VMware vCenter 5 (or 4.1 and 4.0) as the virtualization platform to deploy the desktop VMs, a change is needed in the proxy.xml file.

In Windows 2008 R2 Server go to C:\ProgramData\VMware\VMware VirtualCenter and make a backup copy of the proxy.xml file and then edit the original proxy.xml.

The location differs per Windows version. Should you use plain Windows 2008 server you can find it here: C:\Users\All Users\VMware\VMware VirtualCenter\proxy.xml. In Windows 2003 server you can find it here: C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\proxy.xml.

Search for the <serverNamespace>/</serverNamespace> section. In my current config they look like this:

<e id="0">
  <_type>vim.ProxyService.NamedPipeServiceSpec</_type>
  <accessMode>httpsWithRedirect</accessMode>
  <pipeName>\\.\pipe\vmware-vpxd-webserver-pipe</pipeName>
  <serverNamespace>/</serverNamespace>
</e>

Now change the accessMode section httpsWithRedirect to httpAndHttps:

<e id="0">
  <_type>vim.ProxyService.NamedPipeServiceSpec</_type>
  <accessMode>httpAndHttps</accessMode>
  <pipeName>\\.\pipe\vmware-vpxd-webserver-pipe</pipeName>
  <serverNamespace>/</serverNamespace>
</e>

Next search for <serverNamespace>/sdk</serverNamespace> and again change it:

<e id="9">
  <_type>vim.ProxyService.LocalServiceSpec</_type>
  <accessMode>httpsWithRedirect</accessMode>
  <port>8085</port>
  <serverNamespace>/sdk</serverNamespace>
</e>

Change httpsWithRedirect to httpAndHttps:

<e id="9">
  <_type>vim.ProxyService.LocalServiceSpec</_type>
  <accessMode>httpAndHttps</accessMode>
  <port>8085</port>
  <serverNamespace>/sdk</serverNamespace>
</e>

Now restart the vCenter service and try to connect your XenDesktop server to vCenter. Make sure you use the complete and correct URL including sdk at the end and of course the correct credentials:     http://vCenterServer.domain.local/sdk.

After completing the following screen, you should now see the next screen in the wizard. This proofs that your change was successful.

See full post at: XenDesktop Error: The hosting infrastructure could not be reached at the specified address