{"id":10613,"date":"2010-05-25T08:35:27","date_gmt":"2010-05-25T08:35:27","guid":{"rendered":"https:\/\/aidanfinn.com\/?p=10613"},"modified":"2010-05-25T08:35:27","modified_gmt":"2010-05-25T08:35:27","slug":"exchange-support-policy-for-virtualization","status":"publish","type":"post","link":"https:\/\/aidanfinn.com\/?p=10613","title":{"rendered":"Exchange Support Policy for Virtualization"},"content":{"rendered":"

I’ve previously blogged about this but I’ve been asked about it recently so I’m posting again.\u00a0 I’ve also been watching lots of webcasts and reading web pages on the subject.<\/p>\n

You an read the original text on the Microsoft TechNet site<\/a>.<\/p>\n

The first and most important thing to know is that Microsoft does not support the usage of DAG (database availability group) members on clustered virtualization solutions (Hyper-V, Xen, VMware, etc).\u00a0 Their phrasing is that Exchange clustering solutions cannot be used on virtualization solutions.\u00a0 No quick migration, no live migration, no vMotion, nothing.\u00a0 This means that CCR and SCC are also not supported.<\/p>\n

That\u2019s it.\u00a0 Simple as.\u00a0 No negotiations.<\/p>\n

I find this a little odd.\u00a0 SQL supports guest failover clustering, host clustering, database mirroring in clustered virtual machines.\u00a0 Other MS applications that use the ESE database have no issues with highly available virtualization.<\/p>\n

What this means is that if you want to run Exchange DAG members as a virtual machine(s) then you need to run them on standalone hosts.\u00a0 There\u2019s no point in having one host; you\u2019ll need two.\u00a0 If you\u2019re doing that then you\u2019ll have at least two CAS, hub transport, CAS\/Hubs, Edge, etc.\u00a0 You can probably place one of each on your standalone hosts.<\/p>\n

Why doesn\u2019t Exchange support DAG on highly available virtualization?\u00a0 I cannot think of a technical reason.\u00a0 The Exchange product team has not shared one with us.\u00a0 I\u2019ve heard whispers of data corruption but I suspect that is pure speculation.\u00a0 If you use Live Migration then you know that there is zero network traffic loss.\u00a0 The \u201cdowntime\u201d is 2 milliseconds; less than a TCP\/IP timeout for single packet.\u00a0 So it cannot be the fact that a VM is moved using Live Migration that is causing an \u201cissue\u201d.<\/p>\n

[speculation] If I had to guess<\/em><\/span><\/strong> then here it is: The Exchange product group didn\u2019t test it.\u00a0 Usually, if an MS team doesn\u2019t test something then they won\u2019t support it.\u00a0 Sometimes there are technical failings that cause the lack of support.\u00a0 But when no reasons are given then that means they just didn\u2019t have time, didn\u2019t have the equipment or just didn\u2019t see the point. I\u2019m going out on a limb here: Exchange has been known to emphasise deadlines before product in the past (Exchange 2007 SP1 finished the product) and I would wonder if they just didn\u2019t figure if the testing time was worth it.\u00a0 They just couldn\u2019t test Hyper-V; they\u2019d have to cover all of the hardware virtualization solutions in SVVP.<\/p>\n

Some people don\u2019t _get_<\/em><\/span><\/strong> virtualization so they don\u2019t get the need for people to virtualize a Exchange VM\u2019s with fault tolerance.\u00a0 I\u2019ve heard the argument: \u201cwhy would you want to put highly available Exchange on a Hyper-V cluster?\u201d.\u00a0 Duh!\u00a0 For all the usual virtualization reasons.\u00a0 Any why on a cluster?\u00a0 Because you don\u2019t want to purchase host hardware just<\/em> for Exchange.\u00a0 Not everyone is one of the Fortune 1000\u2019s and some of the reasons we virtualize is to get fewer physical hosts and lower ownership\/operating costs.\u00a0 A well designed, modern host can run a lot of high utilization VM\u2019s. [\/speculation]<\/p>\n

Other stuff you should know about when it comes to Exchange (2007 SP1 and later) on hardware virtualization:<\/p>\n