Whilst at VMworld Europe 2010 I attended a session on virtualising Exchange 2010. This was one of the most useful sessions I went to and whilst it confirmed a number of issues I had read about in the Best Practices Guide there was one tip I picked up from the session that was not in the guide and I thought would be useful to share.
When deploying Exchange 2010 in a Database Availability Group (DAG) on vSphere the Database and Log file disks are only currently supported on RDM disks not VMFS.
I previously blogged about Extending the System Disk in Windows Server 2008 where as a new feature over Windows Server 2003 it is possible to extend the system volume online and without needing to resort to third party tools which often required at least a reboot.
I’ve now used this feature many times, but yesterday I had an issue when extending the volume of a Windows Server 2008 system drive where it returned the horrible looking error below ‘The parameter is incorrect’.
I made my first trip to a VMworld conference this week and had a fantastic time learning in sessions and labs and mixing with some great virtualisation minds from around Europe and the rest of the World. I would highly recommend anyone with an interest in virtualisation to take the opportunity to go to one in the future if possible. I thought I would put together a post of some of the highlights, so in no particular order other than notes I made on the way, home here goes!
Recently I noticed an issue with some Citrix VMs which were displaying the Safely Remove Hardware option to users logged in to that server.
These VMs were on Hardware Version 7 with the latest VMware Tools installed. Both of the above hardware components were using two of the HW7 only drivers, PVSCSI and VMXNET3. The below KB article explains how to disable the HotPlug capability so that the ‘Safely Remove Hardware’ message no longer appears in the system tray.
One of the major new features within Exchange 2010 is the Database Availabilty Group (DAG). This replaces High Availability options from previous versions of Exchange such as SCR and CCR - it essentially works by having multiple copies of the same Exchange databases replicated across multiple Exchange servers.
Exchange 2010 is supported on hardware virtualisation platforms provided the conditions in this Technet article are met. Whilst looking at various options for a possible Exchange 2010 deployment for a user base in the hundreds (it obviously made sense to look at what possibilities are available if deciding to virtualise the mailbox server role) I stumbled across this blog post which suggested that whilst Exchange 2010 was supported as virtual, when running a DAG it was not supported if part of a virtualised cluster.
During the initial stages of an upgrade of a number of VMware hosts from ESX 3.5 U5 to ESXi 4.0 U2 the boot times rose from the normal few mins (most of which is Dell Hardware checks) to around 12 mins.
In particular it was appearing to hang for 5 mins, whilst on the screen the below was displayed:
Loading module multiextent
This would only happen after the install was completed and the host connected back to the fibre channel SAN, otherwise boot times were normal.
I was asked recently via Twitter how to find the CpuFeatureMask property of a VM using PowerCLI. When running a basic
Get-VM Test01 the below properties are outputted to the console:
It is possible to view more properties and values by runnning:
Get-VM Test01 | Format-List \* Unfortunately this still does not reveal the CpuFeatureMask property. However, if we pipe the Get-VM command through to Get-View we will get back a .
I’ve mentioned on this blog before that I’ve been using VMware Update Manager a lot recently - and wrote about some of my experiences here. Today I was really pleased to see that Carter Shanklin’s team released some cmdlets for PowerCLI to cover Update Manager which had only previously been available back as a beta in the VI Toolkit days.
They arrived just in time because I am currently preparing for a round of ESX patching and I needed to provide a report of hotfixes I was intending to deploy for a particular version of ESX.
A while back I posted a script on a basic capacity report I run each month to get an overview of CPU and Memory usage in our various clusters. Since upgrading to vSphere 4.0 U1 I noticed some strange behavior in the results for memory, i.e. they came back at pretty close to 0% (typically between 0.05 and 0.06%) for the average memory usage in a cluster which typically were quite heavily used.
I’m pretty obsessive about patching systems whatever the OS; keeping servers up-to-date and consistent across your environment is very important. VMware ship a great tool vCenter Update Manager to help you with this task for ESX / ESXi systems - you can find out more about it in a new article I have written for Simple-Talk.