A new book: VMware ThinApp 4.7 Essentials

VMware ThinApp 4.7 is an application virtualization and portable application creator which allows users to package conventional applications so that they are portable. “VMware ThinApp 4.7 Essentials” shows you how to deploy ThinApp packages in order to improve the portability, manageability and compatibility of applications by encapsulating them from the underlying operating system on which they are executed.
VMware ThinApp 4.7 is an application virtualization and portable application creator which allows users to package conventional applications so that they are portable. ThinApp eliminates application conflicts, reducing the need and cost of recoding and regression testing.

Want more information? Check here.

vCenter Server Appliance Tips and Tricks

I have done multiple installations of the vCenter Virtual Appliance. Every time I run into the same issue and get the same question from customers. So I though to make a post with all my tips and tricks. This post will be updated when I have a new trick. So check back often.

Change default IP setting before running SSO config

When your vCenter starts for the first time. SSH to the temporary IP address and configure the correct IP settings through Yast. How? Read on.

Change the vCenter name localhost to server name

By default your vCenter name is localhost. In order to change this, login in the vSphere Web Client and goto the vCenter Servers view.

1. Select your vCenter named localhost.
2. Select the manage tab.
3. Select General.
4. Click Edit.
5. Select Runtime settings.
6. At the vCenter Server name change localhost to whatever you want.

Disable IPv6

Don’t disable IPv6. Your vCenter server won’t work anymore after a reboot.

Setting the correct IP settings for the appliance

In the vCenter Virtual Appliance web interface you can alter the IP setting for the vCenter appliance. This is not enough.

1. Login with SSH on your vCenter Appliance server.
2. Start yast.
3. Goto Network Devices | Network Settings
4. Goto Hostname/DNS
5. Set the correct Hostname and Domain Name
6. Reboot host

Replace default SSL certificates

This one is easy. Look at this KB article.

Active Directory authentication

With vCenter 5.1 VMware introduced Single Sign On (SSO). This is a service on vCenter where you can configure multiple authentication sources. 2 of them are default.

• Localos (where the user root comes from)
• System-domain (here you can create vCenter users)

Most of you would like to configure Active Directory authentication. This can be done in 2 ways.

1. Active Directory intergration
   Login in on the vCenter Appliance with HTTPS at port 5480 and goto to the tab vCenter Server | Authentication. Place a mark at Active Directory Enabled and provide the Domain name with the corresponding credentials.
2.  LDAP connection
   Login with the vSphere web client on your vCenter server. On the home page goto Administration | Sing-On and Discovery | Configuration. At the tab Identity Sources click the + sing. Select Active Directory and provide the Identity source settings.

No domain.localusername in vSphere client

If you have a Active Directory Identity Source configured you have to login as follow: domain.localusername. This is no problem if you have multiple domains who contain the same usernames. But if you have only one domain configured this can be annoying. If you configure this Identity Source as Default Domain you don’t have the provide the domain name any more.

Login with the vSphere client on you vCenter server. On the home page goto Administration | Sing-On and Discovery | Configuration. At the tab Identity Sources select your Identity Source and click Add to Default Domain button at the top. Your domain will appear in the lower section of the screen. There you can select the domain and use the arrow key’s to change the search order. The on that is on top is searched first.

NTP time synchronization

Of course you want time synchronization for your vCenter server and what better way to do this with NTP.

1. Login with SSH on your vCenter Appliance
2. Start yast and goto Network Services | NTP Configuration
3. Make sure that the Start NTP Daemon is set to Now and on Boot
4. Select Add and provide the IP or DNS name of you NTP server.

After you save the configuration NTP is started. You can check the time synchronization with the command: watch “ntpq -p”.

The watch command will execute the ntpq command every 2 second. You can stop this whit Ctrl-C.

Using Firefox on Mac won’t show all the available tabs in the vCenter Virtual Appliance web interface.

This is a bug (still with build 5.1.0.5200 Build 880472). Use a older Firefox.

Change SSH host keys after changing the hostname and IP settings

After you changed the hostname and the IP settings of you vCenter server, you have to regenerate the SSH host keys. “Why?” I hear you asking yourself, “everything works?”. Yes everything is working, and it’s secure. But the host keys are generate with the wrong (temporary) values.

1. Delete the ssh_host_* files in /etc/sshd/
2. Restart SSHD by entering the command rcsshd restart.

You will see that the host key’s a regenerated.

High %LAT_C values in ESXTOP

ESXTOP is a great tool for troubleshooting performance issue in VMware vSphere. In the past I written a post about CPU troubleshooting. One of the main values I mention in this blog post was %RDY.Want to know what it means? Read the post 🙂

While checking a vSphere 5.1 environment of a customer I got the following ESXTOP results

As you can see the %USED and %RUN differer a lot. Meaning the virtual machine want more CPU resources (%RUN) than it is actually getting (%USED). A small difference is normal but not up till 50%. %RDY was normal but as you can see %LAT_C is very high. But what does the value %LAT_C means? In the man pages %lat_c is explained as:

%LAT_C Percentage of time the resource pool or world was ready to run but was not scheduled to run because of CPU resource contention.

As you can read, there is a high CPU resource contention. But where does it come from? This is a DELL PowerEdge R620 with 2 Intel E2650 8 cores processors who is running 4 virtual machines. All these virtual machine have 8 vCPUs configured. So you may think that the amount of vCPUs is to high for the amount of pCPUs. But I wouldn’t expect these values. Then I looked a the P state off the CPU, seeing P states of 4, 5 even 11 or 12 explained to me that power saving was enabled in the BIOS for the CPUs. After I disabled power saving (in this case set the performance to maximum) I got the following results in ESXTOP.

As you can see %RUN and %USED are quit the same and %LAT_C is low. This is what we want to see.

vSphere webclient doesn’t show correct WWNN and WWPN

When I was installing a new vSphere 5.1 cluster for a customer I had to document the WWNN and the WWPN. After copying and pasting the WWNNs and the WWPN I noticed that on a hosts, the same WWNN and WWPN occur. Of course these have to be unique.

As you can see, this is not what you want.

When I list the WWNN and WWPN through the CLI I get the following result.

As you can see, the last 2 numbers/letters are different.

Conclusion, you cannot trust the vSphere Web Client for listing the correct WWNN and WWPN. Use the CLI instead.

vSphere Web Client logbrowser: Unauthorized access

vSphere 5.1 is just released and I’m already implementing it in a test environment for a customer of mine. As of vSphere 5.1 the vSphere Web Client is must improved.

While playing around I wanted to test the logbrowser. The logbrowser you can view, search, and export one or more vCenter Server and ESXi log files at a time using the log browser. You can also export, manage, and view different log types.

Right after I clicked the logbrowser option I got the error:

The release note off vSphere 5.1 say’s the following:
When you click Log Browser in the vSphere Web Client, an Unauthorized Access error appears
When you click the Log Browser link in the vSphere Web Client, an error message appears: Exception: https://<system-address>:12443/vmwb/logbrowser: Unauthorized access. This error occurs after you replace the default vCenter Single Sign On server’s SSL certificate, either directly or by regenerating the certificate in the vCenter Server Appliance.

I didn’t replace or recreate the certificate files but the error is the same. VMware has the following work around.

1. Log in to the vSphere Web Client as a Single Sign On administrator.
2. Navigate to Administration > Sign-on and Discovery > Configuration, and click the STS Certificate tab.
3. Click Edit.
4. Select the Single Sign On SSL keystore.
   • If Single Sign On is running on a Windows system, select the following file:
     C:Program FilesVMwareInfrastructureSSOServersecurityserver-identity.jks (default path)
   • If Single Sign On is running on Linux (vCenter Server Appliance), select the following file:
     /usr/lib/vmware-sso/security/server.jks (default path)
5. Open the Single Sign On server.xml file with a text editor or browser.
   • On Windows:
     C:Program FilesVMwareInfrastructureSSOServerconfserver.xml (default path)
   • On Linux:
     /usr/lib/vmware-sso/conf/server.xml (default path)
6. Search for keystorePass="..." on the Connector element. The string in quotes is your password.
7. Enter the password in the vSphere Web Client when prompted.
8. Select only the displayed chain.
9. Click OK and enter the password again.
10. Restart the following services: the vSphere Web Client, vCenter Server, vCenter Inventory Service, and the VMware Log Browser. You do not need to restart Single Sign On.

After reading the procedure multiple times I didn’t understand step 4 and 5. When I click Edit as in step 3 I didn’t see any keystore. And when I clicked on the Browse button. I browsed my own desktop. And of course the file server-identity.jks from step 4 isn’t on my desktop.

I copied the file from the vCenter appliance to my desktop with secure copy and used it like described in step 4. The rest of the procedure is correct and you can browse the logfiles.