Release: vSphere 4.1 Update 1

Like many others already mentioned today: vSphere 4.1 Update 1 has been RELEASED!

I selected a couple of fixes from the release notes that made our life as a vSphere admin a lot better :

  • vCenter Storage Monitoring plug-in might not get enabled if vSphere Client 4.1 is connected to vCenter Server 4.0
    If you use vSphere Client 4.1 to connect to vCenter Server 4.0, and you then enable the vCenter Storage Monitoring plug-in, the Plug-in Manager Window might display an error similar to the following:
    The plug-in failed to load on server(s) vmvc38 due to the following error:
    Could not load file or assembly 'VpxClientCommon, Version=4.1.0.0, Culture=neutral, PublicKeyToken=7c8-0a434483c7c50' or one of its dependencies. The system cannot find the file specified.

    This issue is resolved in this release.


  • Performance Overview data might not display after upgrading to vCenter Server 4.1
    Performance Overview data for the past day, week, and month might not be displayed after upgrading to vCenter Server 4.1.

    This issue is resolved in this release.

  • Performance data might be missing for certain intervals after upgrading to vCenter Server 4.1
    After upgrading to vCenter Server 4.1 or every time that vCenter Server restarts, multiple threads might invoke the same stored procedure to process statistics in temporary tables (VPX_TEMPTABLE[1,2,3]) at the same time causing certain operations to not complete. This might lead to failure in collection of statistics. The performance data in the performance overview charts might be missing for certain intervals.

    This issue is resolved in this release.

  • Replacing SSL certificates in vCenter Server with custom certificates generated using OpenSSL 1.0.0 or later causes Storage Monitoring Service to fail
    For this issue, the following error is recorded in the sms.log files:
    Error constructing private key

    This issue is resolved in this release.
  • Search functionality might not display results if you use vSphere Client 4.1 to access vCenter Server 4.0
    If you use vSphere Client 4.1 to connect to a vCenter Server 4.0 system that is using vCenter Linked Mode, and you then perform a search function, the search results might not appear and might seem that the search function does not complete.

    This issue is resolved in this release.

  • vCenter Server alarm actions are triggered repeatedly even after the state of the alarm reverts to normal
    Some vCenter Server event and state-based alarm actions are triggered repeatedly even after the alert status reverts to green (normal).

    This issue is resolved in this release.

Grab your copy of vCenter Server 4.1 Update 1 here: VMware

 

I made also a short list of fixes in ESX:

  • Some virtual machines stop responding during storage rescan operation when any LUN on the host is in an all-paths-down (APD) state
    During storage rescan operation, some virtual machines stop responding when any LUN on the host is in an all-paths-down (APD) state. For more information, see KB 1016626 at http://kb.vmware.com/kb/1016626. To work around the problem in the KB, manually set the advanced configuration option /VMFS3/FailVolumeOpenIfAPD to 1 before issuing the rescan and then reset it to 0 after the completion of the rescan operation. The issue is resolved in this release. You need not apply the workaround of setting and not setting the advanced configuration option while starting the rescan operation. Virtual machines on non-APD volumes will no longer fail during a rescan operation, even if some LUNs are in an all-paths-down state.

  • Creation of large .vmdk files on NFS might fail
    When you create a virtual disk (.vmdk file) with a large size, for example, more than 1TB, on NFS storage, the creation process might fail with an error: A general system error occurred: Failed to create disk: Error creating disk. This issue occurs when the NFS client does not wait for sufficient time for the NFS storage array to initialize the virtual disk after the RPC parameter of the NFS client times out. By default the timeout value is 10 seconds. This fix provides the configuration option to tune the RPC timeout parameter using the esxcfg-advcfg -s <Timeout> /NFS/SetAttrRPCTimeout command.
  • Updates for the WDDM driver
    In this release, the Windows Display Driver Model (WDDM) driver is updated to fix some infrequent issues where a Windows virtual machine fails and displays a blue screen.
  • Cannot take quiesced snapshots of Microsoft Windows Server 2008 R2 virtual machine running vCenter Server 4.1
    When creating a snapshot of a Microsoft Windows Server 2008 R2 virtual machine that has vCenter Server 4.1 installed, the snapshot operation might fail to complete. This issue occurs on Microsoft Windows Server 2008 R2 virtual machines when the ADAM database is installed.

    The issue is resolved in this release.

Grab your copy of ESX(i) 4.1 Update 1 here: VMware

esxcfg-scsidevs–a output changed in vSphere 4.1

Last week I was busy converting one of my ks.cfg scripts which I use to install vSphere 4.0 update 2 to vSphere 4.1 and I found something, which I didn’t expect from VMware..

To find the iSCSI vmhba I use the following one-liner to save it into a variable VMHBA:

VMHBA=$(/usr/sbin/esxcfg-scsidevs -a |grep “Software iSCSI” |awk ‘{print $1}’)

But the this on-liner didn’t work anymore in vSphere 4.1. So I tried to run the script part by part and started with on a vSphere 4.1 host:

/usr/sbin/esxcfg-scsidevs -a

The following output was generated:

image

if you run the same command on a vSphere 4.0 update 2 host, you’ll see the difference:

image

So to fix this part of my ks.cfg I had to change the VMHBA one-liner and change the grep phrase to “iSCSI Software Adapater” instead of “Software iSCSI”:

VMHBA=$(/usr/sbin/esxcfg-scsidevs -a |grep “iSCSI Software Adapter” |awk ‘{print $1}’)

After changing this line, my ks.cfg script runs fine again. But the question remains unanswered; why did VMware change the output of esxcfg-scsidevs –a Winking smile.

How To: Configure vSphere 4.1 Active Directory Authentication

In this post I will show you how to setup Active Directory Authentication in vSphere 4.1.

What do we need tot do:

- Before you start. Please make sure that DNS and NTP are fully functional.
- Create an AD group called "ESX Admins" on a Windows Domain Controller
- Add users to that group
- Configure ESX/ESXi server’s "Directory Services"

If your ESX hosts and Active Directory Domain controllers are able to find each other via DNS, you’re ready to go to the next step of this setup. We need to create a group called “ESX Admins” and add the users with administrator permissions in vCenter to this group. When you choose a different name for the group, you will not be able to use Active Directory Authentication. I found this in the vsp_41_esx_server_config.pdf:

vCenter Server registers any selected Windows domain user or group through the process of assigning permissions. By default, all users who are members of the local Windows Administrators group on vCenter Server are granted the same access rights as any user assigned to the Administrator role. Users who are members of the Administrators group can log in as individuals and have full access.
Users who are in the Active Directory group ESX Admins are automatically assigned the Administrator role.

After creating the ESX Admins group it’s now time to join the ESX host to the Windows Domain. When you’re managing a small environment, you can do this with five a six mouse clicks per ESX host.

Read more of this post

vSphere 4.1 Download Links Are Ready

image_thumb1_thumb1_thumb[1]

Breaking news: The download links for vSphere 4.1 are ready:

thanks to @vConsult!

 

To be continued. Need some sleep zzzZZZZ (3:27)

Follow

Get every new post delivered to your Inbox.

Join 975 other followers