VMware ESX 4.0 U1 – Storage Pathing Policy Issue

January 7th, 2010

While fixing up storage pathing through redundant FC adapters, noticed that one ESX 4.0 U1 host using Fixed (VMware) path selection policy had an Active (I/O) path for each presented LUN but did not have a Preferred adapter highlighted. Also, received the following error when trying to set the preferred adapter (under Datastore Properties -> Manage Paths -> right-click in Paths, select Preferred):

Unable to cast object of type ‘LogicalUnitPolicy’ to type ‘FixedLogicalUnitPolicy’

This was only happening on one host and was happening for every datastore and every type of storage presented to the host (local and remote).

To fix, selected the only local storage presented to this host (where ESX was installed) and briefly changed the Path Selection Policy to Most Recently Used (VMware), which causes a Set logical unit policy action on the host. After doing so and then switching back to Fixed (VMware), the preffered path is then highlighted and the other LUN’s were able to be successfully set as well.

I expect that a rescan of the storage adapters may also resolve it but didn’t get the chance to try it.

VMware ESX 3.5 to vSphere (ESX 4.0 U1) Upgrade In A Nutshell

January 7th, 2010

The intention for this upgrade was to use the VMware Host Update Utility included with the vSphere Client. However, an upgrade was in the end not possible. The reason being because the existing ESX 3.5 installation had customized partitions (specifically to fill out the local storage with /, /var, swap, etc). This was fine for ESX 3.5 but for ESX 4.0, these partitions are inside the service console VMDK stored on the local VMFS. There was only 2.5GB of space left over for VMFS on the ESX 3.5 installation.

So, the upgrade was effectively a per host rebuild to ESX 4.0. The process, however, is still simple:

  • vMotion all guests off of the host to be rebuilt
  • Put the host into maintenance mode
  • Remove the host from the cluster
  • Reboot the host and install from the ESX 4.0 media (selecting local storage to create the VMFS for the service console VMDK)
  • Add the host back to the cluster

After upgrading the first host, adding it to the cluster and ensuring that it’s configuration was good, I then created a Host Profile of it and used that profile to attach to the remaining hosts and apply it’s settings to ensure full compliance. This process saved plenty of time configuring the hosts post-install. A scripted installation may have been a better option but for <5 hosts, the Host Profile utility is a very fast way to configure hosts and ensure compliance. Further, for management purposes going forward, the Host Profile utility is an excellent tool to ensure compliance of hosts.

Install VMware ESX 4.0 vSphere in VMware Workstation 7

January 5th, 2010

Using a laptop with 4GB of RAM, trying to install ESX 4.0 Update 1. Allocated 2GB RAM to the virtual machine but receiving the following error when trying to power it on:

Not enough physical memory is available to power on this virtual machine with its configured settings.
To fix this problem, decrease the memory size of this virtual machine to XXXXMB, or adjust the additional memory settings to allow more virtual machine memory to be swapped.
Alternatively, do you want to temporarily reduce the memory size of the virtual machine from 2048MB to XXXXMB? Reduce Memort | Do Nothing

The only option of any use is of course “Do Nothing”. ESX 4.0 won’t install without a minimum of 2GB of memory.

To fix the issue and allow the virtual machine to power on with its allocation of 2GB memory: In Workstation, go to Edit -> Preferences -> Memory tab then increase the Reserved Memory slider up to the desired amount of memory. I increased it to exactly 2048MB and the ESX 4.0 virtual machine could be powered on.

Also tested with lower values and it will also work – it depends on the Additional Memory setting. The default option is to ‘Allow some virtual machine memory to be swapped’ (switching to the ‘Fit all virtual machine memory into reserved host RAM’ option, will result in the VM failing to power on if the Reserved Memory allocation is lower than the amount of memory allocated to the virtual machine).

Cisco Unity 7 Unified Messaging with Exchange 2007: Import User Error 0×80070005

December 30th, 2009

Receiving error: “0×80070005 has occurred: E_ACCESSDENIED” when trying to import users on a new setup of Cisco Unity 7 integrated with Exchange 2007. Further, the following is logged to the Application event log:

Event Type: Error
Event Source: CiscoUnity_DSAD
Event Category: Error
Event ID: 1046
Date: 12/23/2009
Time: 4:21:51 PM
User: N/A
Computer: HOSTNAME
Description:
The Cisco Unity service that monitors Active Directory (AvDSAD) failed to modify object.

Type: AVOBJECTTYPE_MAILUSER
Name:
Reason: ERROR_ACCESS_DENIED: Access is denied.
Domain Controller:

Possible causes include: 1) Network connectivity to the Domain Controller. 2) Insufficient rights for The Cisco Unity service that monitors Active Directory (AvDSAD) account.

Ensure that The Cisco Unity service that monitors Active Directory (AvDSAD) can contact the Domain Controller and has sufficient rights to modify objects. If the problem persists, enable all the micro traces for The Cisco Unity service that monitors Active Directory (AvDSAD) in the Unity Diagnostic Tool. Report the problem to Cisco TAC and include the diagnostic log.

Had followed the setup guide, including running the Permissions Wizard and the manual Exchange PowerShell script to create Unity’s system mailboxes.

Checked the Active Directory account of the users being imported and noticed that the UnityDirSvc and UnityMsgSvc account permissions had not been inherited to child objects. That is, they were only applied at the OU level that the user objects existed in.

Under Advanced (Security tab), selected to “Allow inheritable permissions from the parent to propogate to this object…” Tried the import again, worked perfectly.

A VMware Holiday

December 20th, 2009

Between Christmas and the New Year, I plan to do a VMware ESX 3.5 cluster upgrade to vSphere. This will be 4 hosts in an HA/DRS cluster all upgraded to vSphere / ESX 4.0 U1.

The process should be similar to a regular host upgrade: Virtual Center (oops, vCenter), followed by the hosts, followed by the VM’s (tools and virtual hardware). There are a few different options when it comes to the upgrade including Update Manager, ESX host update utility, using install media at the console, … Will post again with the upgrade details.