Archive

Archive for September, 2010

VMware Update Manager fails to patch a host

September 26, 2010 Leave a comment

On a few occasions I have found sites where VMware Update Manager fails to patch or update a host. The task can fail with the error “VMware vCenter Update Manager had an unknown failure. Check Task and Events tab and logs for more details” or “Failed to scan host for patches”

I have found the most common issue is the /tmp directory is full, this can be confirmed using the df -hmk command from the console.

If the updates are occurring over a WAN link it’s also possible the failure is occuring due to timeouts.

Categories: VMware

VMFS datastores and resignaturing

September 15, 2010 Leave a comment

 Several times primarily when using HDS storage I have been required to change the host mode settings between Sun cluster and Linux. Normally this is due to SRM and the SRA requirements. When this is done the Canonical Name of the devices changes and the VMFS Datastore will disappear, generally you add the VMFS back re-signaturing it in the process. 

Several things I have noticed: 

1. The VMFS datastores cannot be added back whilst connected to the vCenter Server, you must connect directly to the ESX host. 

2. Add the VMFS back on one host, will not propagate to other hosts. 

3. It takes a long time to add the storage back as each VMFS takes approximately 3 minutes to find the devices. 

I don’t understand why any of the above issues occur but notice that each time I have done this I have had the same problem.

Categories: VMware

Sydney’s Bledisloe, game of the 2010 season

September 7, 2010 Leave a comment

Looks like we could have the game of the season shaping up for this weekend’s clash between the Wallabies and All Blacks in Sydney. The Wallabies on a high from a narrow in against South Africa and All Blacks missing Dan Carter and giving Aaron Cruden, Israel Dagg and Victor Vito starts in a mini rotation.
Although the All Blacks will be the bookies favourite I doubt any fans will be feeling overly confident. I believe although the AB’s started the season well ahead of both South Africa and the Wallabies, the margin between the teams has narrowed considerably throughout the Tri Nations tournament. Now at the end of the Tri Nations the best two teams face off before heading off on their end of season tours.
I expect Australia to want it more as they will be desperate not to notch up a historic 10 losses in a row. Whereas the All Blacks, with several key changes are looking to build depth ahead of next year’s World Cup.

Go the All Blacks!!

Categories: All Blacks

Exchange 2010 DAG and VMware HA

September 2, 2010 4 comments

Update: Microsoft has changed it’s support stance, see the below article.

http://blogs.technet.com/b/exchange/archive/2011/05/16/announcing-enhanced-hardware-virtualization-support-for-exchange-2010.aspx

Updated post on this issue here

As Paul Cunningham from Exchange Server Pro correctly points out in this post Microsoft does not support Live Migration or vMotion of Mailbox Servers if they are part of a DAG (Database Avalaibility Group). Paul also mentions something which Scott Schnoll talked about at Teched last week, that Microsoft does not support high availability solutions in the hypervisor, i.e. VMware HA. Refer to the following line in the system requirements:

“Microsoft doesn’t support combining Exchange high availability solutions (database availability groups (DAGs)) with hypervisor-based clustering, high availability, or migration solutions that will move or automatically failover mailbox servers that are members of a DAG between clustered root servers. DAGs are supported in hardware virtualization environments provided that the virtualization environment doesn’t employ clustered root servers, or the clustered root servers have been configured to never failover or automatically move mailbox servers that are members of a DAG to another root server.”

Exchange 2010 System Requirements

I had a discussion regarding this same topic with Sandy Miller at Teched. Now I believe there is either misunderstanding from Microsoft on how VMware HA works or that Microsoft is placing the same limitation on VMware that it has with its own hypervisor so as not to disadvantage its own product. To understand this we first need to clearly understand the differences between how the two hypervisors implement HA.

VMware HA continuously monitors all ESX Server hosts within a cluster and acts when it detects a failure. An agent placed on each host maintains a “heartbeat” with the other hosts in the cluster and loss of the heartbeat with the other hosts in the cluster initiates the process of restarting all affected virtual machines that were registered on the affected host, thereby restarting the VM’s. Contrary to popular belief it is nothing more than automatically powering back on the VM, it does not vMotion or move a resource as the VM is now powered off.

Hyper-V uses Windows Clustering and Clustered Shared Volumes or CSV’s, these CSV’s are NTFS volumes shared by the Hyper-V hosts. The VM becomes a clustered resource, similar to other Microsoft Clustered resource, that VM resource can then be moved between hosts (Live Migration), or in the event of a failure the cluster service will automatically move that resource and restart the VM on the remaining hosts.

Therefore only the “hypervisor-based solutions that will move or automatically failover mailbox servers that are members of a DAG between clustered root servers” are not supported. I do not believe that VMware HA meets any of these criteria, “moving” or “failover” of mailbox servers. VMware HA simply powers on a failed VM. I suspect this limitation does effect Hyper-V due to its use of Windows Clustering.

When Microsoft states that Mailbox Server protected by high availability solutions in the hypervisor is not supported, what exactly does that mean? If you contacted Microsoft with an issue regarding a general application error and they identified you having HA enabled would this mean you would receive no support at all, irrespective if the issue was unrelated to HA? I understand if your issue was corrupted Information Stores and you were Live migrating the effected Mailbox Server you would clearly be stuck with a unsupported configuration. The blanket statement “unsupported” to me is a cope out! VMware HA is a tick box that automates the pressing of the power button a VM?

Unfortunately I can only really vent my displeasure here in this blog, but ultimately as a IT professional with Microsoft certifications and working for a Microsoft Partner I will ensure that any Mailbox Servers I deploy are neither Live migrated, nor have HA protecting them, to ensure my customers do have supported configurations.

Categories: Exchange, Microsoft, VMware