Search results matching tags 'Database Administration' and 'Virtualization'

Some Thoughts on Clustering SQL Server Virtual Machines

jmkehayias — Wed, 24 Nov 2010 04:58:24 GMT

On my blog post Virtualizing SQL on VMware Reference List, Oscar Zamora (Blog | Twitter) asked the following question in a comment:

As a virtualized instance has the benefit of "failing over" to another physical box, would you consider clustering a virtualized instance?

The answer to this question more than I want to write up in a comment, so I decided instead to blog my response. Since at least ESX 3, VMware has provided a number of high availability features in their enterprise server virtualization product. A detailed listing of the HA features available in VSphere 4 can be found in the vSphere Availability Guide.
In this post I’ll talk about the most popular ones and the ones that VMware marketing uses to try to convince people that VMware HA solves all of their High Availability needs.

High Availability and DRS Clusters

ESX hosts can be clustered together providing high availability from the hardware failure of a host for the guests running inside of the cluster. If a host fails, the VM’s that were running on that host fail as well, but the cluster detects this and powers the VM’s up on other hosts inside of the cluster automatically, bringing the VM’s back online and restoring application serviceability. Other features such as Server vMotion and Storage vMotion allow movement of the VM’s and storage dynamically to allow for hardware maintenance and upgrades with little to no downtime to the applications running on the VM’s. In addition to this the VMware Tools installed inside of the guests can provide monitoring of the guest to detect Operating System failures and lock ups inside of the VM and automatically restart the VM.

VMware High Availability: Easily Deliver High Availability for All of Your Virtual Machines
VMware High Availability: Concepts, Implementation, and Best Practices

Fault Tolerance

VSphere 4 introduced a new high availability feature for VM guests called Fault Tolerance. Fault Tolerance creates a synchronized Secondary virtual machine on another host in the high availability cluster that is lock stepped with the Primary VM. In the event of a host failure, guests that have Fault Tolerance enabled immediately failover to their Secondary in a manner that is similar to vMotion preventing application downtime from occurring. When this occurs a new Secondary is created on another host inside of the cluster and synchronized with the new primary maintaining the fault tolerance of the guest inside of the environment.

VMware vSphere™ 4 Fault Tolerance: Architecture and Performance
VMware® Fault Tolerance Recommendations and Considerations on VMware vSphere™ 4
Protecting Mission-Critical Workloads with VMware Fault Tolerance

What does this all mean to SQL Server?

These features are really great features provided by virtualization, but that doesn’t make them the solution to all of your High Availability needs. SQL Server is often considered and treated by server administrators as just another application server, especially when it comes to virtualization. However, SQL Server is not just another application and SQL Server provides its own High Availability options, like clustering, that may be more appropriate based on your environmental requirements. There are specific reasons that the above features may not be acceptable HA features for SQL Server.

Fault Tolerance is currently limited to single vCPU guest VM’s only, so unless your SQL Server VM’s are all single vCPU, that’s not going to help you out. This leaves you with VMware HA and the potential for failure with automatic restart on another host. However, what none of the VMware features provides is minimization of downtimes associated with planned Windows Updates of the guest VM’s or the application of SQL Server Service Packs. If you have the ability to take periodically planned downtimes of one to two hours for patching the basic HA features of VMware will probably meet your needs. This may be an acceptable configuration in your environment, and if it is, I won’t fault you for deciding that it meets your high availability needs. I have VM’s in production that are protected first, by good database backups, and then by VMware HA.

However, I also have systems that have minimal downtime requirements, and because of this, relying on VMware HA as my primary HA solution doesn’t provide the level of availability required for those systems. This leads to SQL Server clustering, which is supported in virtualization if it meets specific requirements as documented on the Support policy for Microsoft SQL Server products that are running in a hardware virtualization environment and in Bob Wards blog post SQL Server Support Policy for Failover Clustering and Virtualization gets an update. This brings us to the question that started this discussion: “Would I consider clustering a virtualized instance?” Maybe, if the host environment had the resources to support it, but using VM’s for my cluster nodes wouldn’t be my first choice for clustering for a couple of reasons.

First if a database has a minimal downtime requirement it probably also has a minimum performance requirement that is coupled with it. While you can, and should, setup reservations for the resources allocated to a SQL Server VM, in NUMA enabled hosts like newer Nahalem systems, the maximum recommended size of a single VM is the resources available in a single NUMA node. That means if you have a quad socket quad core server with 128GB RAM with 4 NUMA nodes, on per socket, each node would have 4 cores and 32GB RAM, making the largest VM 4 vCPU and 32GB RAM, unless you trade off the NUMA optimizations in ESX and memory locality. In addition to this, you have to be careful where your SQL Server VM cluster nodes exist inside of the VMware host cluster to actually maintain the high availability of the SQL Server cluster. If both of the SQL Server VM cluster nodes exist on the same physical host, and that host fails, both of the SQL Server VM cluster nodes are going to fail as well. On top of these reasons, configuration of the VM guests for MSCS is not a trivial process as shown by the 36 page whitepaper Setup for Failover Clustering and Microsoft Cluster Service.

In my current environment we have multiple clustered SQL Server instances, and none of them are virtualized and at the current time we are planning to build additional clustered SQL Server instances to migrate databases that have high availability and minimal downtime requirements to. Despite having a dedicated VMware host cluster for our SQL VM environment comprised of very powerful hardware, there isn’t any added benefit to building the clusters inside of virtual machines. Your environment may be different and clustering inside of virtual machines may make sense for your specific requirements, but in the end it is the database downtime requirements that should determine whether or not the database should be clustered, not that VMware provides built in High Availability, because that only covers one aspect of minimizing downtime.

Some thoughts on the Virtualization Feedback in the SSWUG Newsletters

jmkehayias — Thu, 01 Apr 2010 11:49:49 GMT

Last Thursday, March 25, 2010, the topic of Virtualization of SQL Server came up in the SSWUG Newsletter, with Steven Wynkoop asking if peoples perceptions and experiences have changed since the last time he covered virtualizing SQL Server. I unfortunately missed the last coverage of this topic, but it appears from the newsletter that there was a general consensus that “low-traffic solution could be fine, but if you had a heavy hitting application, the net advise was to avoid a virtual environment because the load just couldn't be answered in the same way that a dedicated server could provide.” I’ve personally heard this information numerous times over the last four years, so its not surprising to see it being repeated in the SSWUG newsletter.

There are certainly SQL Server implementations where the current limitations of a virtual world would preclude virtualizing the environment, since there are limits on the number of vCPU’s (Hyper V allows 4, and VSphere 4 allows 8) and amount of memory (Hyper V allows up to 64GB, and VSphere 4 allows up to 255GB) each virtual machine can use. If you have a SQL Server with dual duo core processors and 32GB of RAM that is consistently running forty percent CPU load, its not a good candidate for virtualization, and attempting to do so will result in less performance than a physical implementation. This doesn’t describe the majority of servers that I have seen in my own work, or in doing consulting work, and I’d say that a majority of the SQL Servers in use by most businesses could be virtualized and still achieve acceptable, if not better performance than their current physical implementations.

I the last two weeks I’ve answered quite a few forums posts that dealt with SQL Server performance problems that turned out to be virtualized servers, I’ve been having discussions on Twitter with Denny Cherry (blog/twitter) and Buck Woody (blog/twitter) about how to best configure a new virtual cluster we are building at my job for SQL Server, and I’ve answered some questions about monitoring virtualized servers in VMware ESX for a couple of MVP’s that do consulting work and have had to look at virtualized SQL Servers. I am by no means an expert at virtualization, but I have almost four years of experience working with virtualized production SQL Servers that hosted all sizes and types of SQL databases, and I’ve had great results.

I am not alone in this experience based on the feedback provided by Mike in the March 30th newsletter, but if you read through Mike’s response and compare it to every other piece of feedback provided, you should easily see that there is a fundamental difference in his implementation and the level of technical knowledge of the staff. Many of the other comments provided in the other newsletters show a fundamental lack of technical knowledge by the respondents as well as their support staff, which is a big contributor to their real and/or perceived problems with virtualizing SQL Server.

Busting Some Myths in the Feedback

While reading through the feedback I noticed that there was a good bit of misinformation being presented by people who were against virtualizing SQL Server. Some of the items might have been true three or four years ago, but hypervisor and feature improvements in the virtual space have done a lot to allow virtual machines to perform at comparable levels to similarly sized VM’s.

You won’t get acceptable IO performance from a VM

A large number of the responses focused around problems with IO performance in a virtualized SQL Server, for example:

“if you focusing on the disk IO as the key factor in performance you’ll find that in all but the most heavily used systems that the virtual server option is viable.” – Steve 03/31/2010

“The problem is that we test the setup on a new iSCSI device, then end up with a variety of systems sharing the same “shelves” (sets of drives) and the result is slower than expected performance.” – Rick 03/26/2010

“The main problem will always be one of storage subsystem and I/O. The biggest challenge with SQL virtualization, I believe, is how to optimize the storage back-end, especially with so many IT shops deciding to go with iSCSI NAS solution for their guest OS farm.” – George 03/26/2010

In each of these scenarios, the virtual environment hasn’t been given a fair opportunity to perform. There seems to be a major disconnect in how people think about storage for a VM versus a physical implementation of SQL Server, and this drives a vast majority of the performance problems I find when people run SQL Server in a virtual server. This problem is almost entirely rooted in over selling the cost savings associated with virtualization to the point that you cut your legs out from under you. Would you try running a physical production SQL Server using a heavily shared NAS iSCSI device for database storage?

If you did, you’d have the same IO performance problems in the physical server that you would in the virtual server. The problem here is that you are using shared disks, and you have competing IO demands, something that is well documented as a performance bottleneck for SQL Server. In addition to this, a lot of NAS iSCSI devices I see these days have large drives 300GB up to 1TB in size in a RAID 5 configuration, so a NAS with 6 drives yields roughly 5TB of storage which is great capacity wise, but really slow performance wise. The problem here has absolutely nothing to do with whether or not the SQL Server is virtual, it has to do entirely with the configuration of IO subsystem backing the server.

If the IO subsystem is properly configured good IO performance can be achieved from a virtual machine running SQL Server. The following charts show the results from SQLIO on a 2 vCPU 4GB RAM, virtual machine running in VSphere 4, using VMDK’s on heavily shared LUN’s from a fiber attached SAN. The tests used a 48GB test file and ran 64K Random and Sequential Read and Write tests using 4, 16, and 64 threads with 4, 8, and 8 pending respectively, based on a short test set provided to me by Brent Ozar (blog/twitter) for benchmarking a server before and after a reconfiguration of the disk arrays in a minimal downtime to show improvements.

This is hardly the best configuration for SQL Server, but the limit for IO load is just at the limits of our 4Gb/s SAN fabric. A better configuration would use raw device mapping for the data and log LUN’s and have MPIO properly configured for the HBA’s, a configuration I’ll be testing in the near future, but you can certainly get good IO performance out of a virtualized SQL Server when the hardware has been sized properly for IO in general.

You can’t adequately troubleshoot performance problems in a VM

This comment is very common from people that don’t have much experience working with VM’s.

“Again, since it’s hard to tell what’s using the I/O, it’s hard to give them metrics as to why/how this isn’t performing well.” – Rick 03/26/2010

“And then has to prove the performance problem is with the server/storage area, instead of the application, yet doesn't have access to see anything about the vmWare/storage side that can really help to troubleshoot the problem? And it sounds like he has no way, nor do the VM admins, to monitor the I/O in an application-oriented way?” -

Both Hyper V and VMware provide the ability to perform detailed analysis of performance at the host level. In VMware has esxtop for performing analysis from the host level and monitoring the resources being used by the guests, and Hyper-V can be monitored through perfmon. However, you don’t really need to look at the host to know that a problem or bottleneck exists, especially with SQL Server. The guest OS still has performance counters and SQL Server has wait stats and file stats that can tell you where your bottlenecks are. If it takes 25ms to read from disk it takes 25ms to read from disk. If you have high accumulated wait times for PAGEIOLATCH_*, WRITELOG, ASYNC_IO_COMPLETION, or IO_COMPLETION waits, associated with high latency numbers for the Windows Performance Counters for Physical Disk in the VM, you can bet that you have an disk related bottleneck and at that point you need to jump out to the host to identify the what/why with the host level tools.

My own thoughts

It is very clear that there is a significant lack of understanding by the community and apparently some of its leaders how virtualization can or should be done with SQL or any other server for that matter. The biggest problem I see, and it has occurred in my own jobs, is oversubscription of hardware, resulting in bottlenecks. The other prevailing problem is the fact that SQL Server DBA’s aren’t benchmarking accurately or troubleshooting problems correctly leading them to incorrect decisions that make absolutely no sense. Take for example the comments by Leanne in today’s newsletter:

"I just got done supporting a client that we started off with SQL Server 2008 on a Virtual Server 2008. We were three months before going into production with it when it started getting heavy hitting from testing. Over about 1 to 2 days of use, the memory use would climb slowly up to 100% and SQL would choke. We would be forced to reboot the server to clean things up and then it would start all over again. We tried everything we could think of with how SQL Server was using memory but nothing helped. The sys admins tried everything they could think. They finally told us that from what they could see, for some reason, the virtual was not recognizing the memory getting freed up by processes so slowly it chocked on itself.
Two weeks before we went live we were given a real Server and we had no problems with memory use from that point on. Given my experience, I would be hesitant to recommend to anyone to use SQL Server 2008 on a virtual server without extensive testing in this vein."

To be honest, some more information is needed to be certain, but the problem described has nothing to do with being a VM, and is rooted in SQL Server being misconfigured for memory usage. This is one of the most common problems people ask about on the forums, and it has nothing to do with a memory leak it is how SQL Server uses memory, and will be the same on the physical server if they had an identical setup. (Troubleshooting the SQL Server Memory Leak)

Another reader, Dan, comment in today’s newsletter:

“I can check waitstats in the DMV if it’s a recent version of SQL Server (but we still have a lot of SQL 2000 here). But then what?”

You can check waitstats in SQL 2000 as well, DBCC SQLPERF(waitstats) will return the accumulated waits for the SQL Server. Why didn’t Steven point this out and provide a service to the community instead of posting comments that are riddled with incorrect information and prone to lead others down the same incorrect thought process about virtualizing SQL Server? I don’t know, I’ll leave that to Steven to address because I am sure he reads through the SQLBlog content based on other posts on here.

The complete list on newsletters covering this topic can be found at

Friday, March 26, 2010
Monday, March 29, 2010
Tuesday, March 30, 2010
Wednesday, March 31, 2010
Thursday, April 2, 2010

This is another good example of where you should be careful what you trust from the internet, even when it is purportedly coming from a trusted source in the community such as SSWUG, because the information contained in the feedback hasn’t been vetted for any kind of technical accuracy and is full of incorrect information. I’d point out that Microsoft has migrated a majority of their own SQL Server environment to VM’s and even provides a whitepaper that documents how they did this:

http://technet.microsoft.com/en-us/library/dd557540.aspx

Building a SQL Server Cluster for Testing - Part2

jmkehayias — Mon, 08 Jun 2009 03:26:00 GMT

Its been a few days since the first post in this series, and I have learned a lot about clustering in Windows Server 2008 with SQL Server 2008. The first thing I learned over the last few days is that there are some significant changes in Windows 2008 Clustering that affect how you will roll out a cluster for testing purposes. A lot of the changes have to do with Windows 2008 clustering configuration and not necessarily with clustering SQL Server 2008 directly, but since clustering SQL Server is dependent first on successfully clustering Windows Server 2008, they are important to note.

The first problem that bit me in working on this project is that there are changes in Windows Server 2008 clustering that made my original attempts to use an OpenFiler iSCSI target for clustering inadequate. Primarily the problem has to do with the requirement for SCSI-3 Persistent Reservations.

http://blogs.technet.com/askcore/archive/2009/04/15/windows-2008-failover-cluster-validation-fails-on-validate-scsi-3-persistent-reservation.aspx

This is not currently supported under any of the Linux open source iSCSI targets that are readily available online. (If you happen to know of one, send me a contact through here, I'm interested.) This meant that I had to first change my iSCSI target implementation out for SCSI-3 Persistent Reservation support. Luckily StarWind supports SCSI-3 as a part of their Express Edition, though it requires Windows to be running which requires more system resources than the comparable Linux implementation.

This being the first and only cluster I have setup from scratch, I have to say, that while somewhat aggravating at times, it wasn't overly complicated to actually get online and running. A majority of the problems that I encountered had to do with my lack of understanding the requirements for building a Windows 2008 Cluster, like SCSI-3 Persistent Reservations. Fortunately, I have experience installing and running SQL Server 2008 on Windows Server 2008. For a quick run down, here are more or less the steps that I followed along the way to building my first successful cluster:

Install ESXi.
Install Virutal Infrastructure Client on laptop
Create Virtual Machine for Active Directory Domain Controller (DC01)

1 vCPU 2GB RAM 20GB HardDisk
Install Windows Server Enterprise onto DC01
Configure Static IP for Networking
Add the Active Directory Server Role
Run Active Directory Configuration and create a new Domain and Forest.
Add ports to firewall for DNS and AD.
Create SQL Service User Account

Create Virtual Machine for W2K3 iSCSI SAN (SAN)

1 vCPU 2GB RAM 20GB HardDisk 60GB HardDisk
Install Windows Server 2003
Configure Static IP for Networking
Add to Active Directory
Install StarWind Express Edition
Configure 3 iSCSI Targets

5GB Quorum Disk
5GB MSDTC Disk
20GB Data Disk

Add ports to firewall for iSCSI

Create Virtual Machines for Node 1 and 2 (W2K8-01/W2K8-02)

2 vCPU 4GB RAM 20GB HardDisk 2 Network Adapters
Install Windows Server 2008 Enterprise onto W2K8-01/W2K8-02
Configure Static IP for Networking Controller 1 on Public Network
Configure Static IP for Networking Controller 2 on Private Network for Heartbeat.
Join both servers to the Active Directory Domain.
Configure iSCSI Initiator

Target Portal = SAN IP Addresss
Configure Quorum TargetID as Disk1, MSDTC as Disk2, and Data as Disk3
Set all targets to "Automatically restore this connection when the computer starts."

Add the Application Server Role
Add Failover Clustering Feature
Open Failover Cluster Manager and validate the configuration of both servers for Clustering.
Create a new Failover Cluster named W2K8-CLUSTER on IP 192.168.100.210
Add MSDTC to the Cluster from W2K8-01 named WIN2K8-MSDTC on IP 192.168.100.211
Install .NET 3.5 onto both Cluster Nodes from SQL 2008 Installation Media.
Run Setup for SQL Server 2008 on W2K8-01 and select "New SQL Server failover cluster installation"
Name SQL Cluster SQL2K8CLUSTER
Run Setup for SQL Server 2008 on W2K8-02 and select "Add Node to a SQL Server failover cluster"

If you can follow all of these steps, you should have a complete SQL Cluster. I had considered posting a step by step guide as a part of this process. However, one of the lessons that I learned during this process is that I could have saved a lot of time, and a lot of headache by doing a bit of research before diving in head first. There is already a really good write up in a four part series written by Edwin Sarmiento that uses StarWind and builds a very similar cluster to the one that I built.

http://www.mssqltips.com/tip.asp?tip=1687

I should know by now to follow the Latin statement nanos gigantum humeris insidentes, or standing on the shoulders of giants, meaning "One who develops future intellectual pursuits by understanding the research and works created by notable thinkers of the past". I should know at this point in my career to do my research up front, but I still tend to attempt to roll my own first and then find the ~~corrections~~ directions later on. As a part of this process I ordered a new book:

Microsoft SQL Server 2008 Management and Administration by Ross Mistry

based on a posting I found while trying to figure out a problem I was having with MSDTC while on my second of three attempts at installing my cluster. While I haven't received the book yet, I did get a message from Ross pointing me to his book after purchasing it in response to a question that I posted on Twitter. If you haven't happened to jump on the social networking site yet, I'd highly recommend that you do and get involved in the SQL Community online. The amount of information you can get in a few seconds while working on a project such as this is simply phenomenal. Another member of the SQL Community who provided responses to my clustering questions and postings on Twitter was none other than clustering guru, Geoff Hiten, who I've met a few times personally, and I frequently send links to questions on clustering on the forums when I can't help with them.

So now that I have installed a functioning Windows Server 2008/SQL Server 2008, I am off to install a second cluster, but this time on Windows Server 2003 with SQL Server 2005 so I can play with performing upgrades. So much to learn, but so little time....

Building a SQL Server Cluster for Testing - Intro

jmkehayias — Wed, 03 Jun 2009 04:31:41 GMT

At some point as a SQL Server DBA, you have to learn how to install and configure a SQL Server Cluster. I personally haven't dealt with a SQL cluster since SQL Server 2000, and I've never had to install one from scratch, so I've decided to jump in feet first and put the time in to learn how to do this. There are already a few great primers on how to build a Windows Cluster using Microsoft Virtual Server and a Shared SCSI Bus for clustering.

Using Microsoft Virtual Server 2005 to Create and Configure a Two ...

How to Configure Virtual Server 2005 in Order to Setup a Test SQL ...

Setting up a SQL cluster under MS VS2005 R2 Part1

A few weeks back I bought a used server from Ebay, a DL580 with 4x3.0Ghz Xeon MP processors, 16GB RAM, and 4x73GB U320 15K drives as a play server. It set me back just short of $700 shipped which is decent for the power it packs. The only problem I have with it is that the Xeon MP processors are x86 only, and don't support Hardware Virtualization, but for the price I still consider it a deal. I've faced a few problems in getting this server configured to be a Virtual Machine Host in the last few weeks, all leading me to one great conclusion. I DON'T HAVE A CLUE WHAT I AM DOING OUTSIDE OF SQL SERVER.

I can regurgitate Best Practices and dictate how I want servers configured to run SQL Server on all day long, and luckily (unluckily for my own experience) I work with a server team that just takes my specs and provides me a server running as requested which I then install, configure, and administer SQL Server on. I fully understand the ins and outs of what makes SQL Server run, but I've never actually configured a RAID Array, iLO card, or built a server from the ground up (when my laptop/desktop have problems I hand them over to be fixed, its the way things work where I am currently).

So now that I have demonstrated my incompetence publicly, stay tuned while I work through configuring a ESXi host with a OpenFiler iSCSI appliance as a iSCSI target for a Windows 2008 and SQL 2008 clustered install. If you are interested in building your own test clustering environment for next to nothing I'll be blogging my progress while I progress in this little project.

For this intro post, let me first begin by explaining why I chose to work with ESXi as my virtualization platform over VMware Server or Microsoft Virtual Server (HyperV is out because it requires x64 and hardware virtualization from what I have read). I started out installing Windows Server 2008 Enterprise and Virtual Server 2005 Enterprise to begin building my cluster when I hit a snag. Windows 2008 Server doesn't support shared SCSI Bus for clustering, I would have to use Windows Server 2003, and I want to play on the latest and greatest, which left iSCSI for my quorum disk. One problem I had running Windows Server for my host OS is that it was using a fair amount of my system resources for the host OS to be running.

I took a look at the virtualization platforms available, and found the VMware offers ESXi for free which has a very small foot print, < 300MB installed for its software hypervisor. My older brother had mentioned a free iSCSI target called OpenFiler a while back, so I did a search and there is a free appliance that can be run in ESX that is almost plug and play out of the box to create an iSCSI target. This more or less is what lead me to ESXi. I tried both VMware and Microsoft Virtual Server and found that management was clunky through the web, and since we use ESX at my current job, and I am pretty familiar with the Virtual Infrastructure Client, ESXi just made the most sense.

My other big snag I hit was more of a logistics problem with my house. I have FIOS Internet Access which is high speed over Fiber and my router, wireless router, and switch are in my living room since FIOS comes in on the cable wires for digital TV. My home office happens to be on the other end of my house. So I needed to run a cable across my house to add a new server to my network since it doesn't have built in wireless; or did I? The power of Twitter came my rescue and a quick question led to information that I could use an older wireless router to create a bridge wirelessly to my existing wireless network. This required hacking my old WRT54G Linksys router with a Linux Bin file which I found on the following site:

WRT54G v4 Installation Tutorial - DD-WRT Wiki

After spending an entire night expecting that I had "bricked" my old wireless router (ie, destroyed it and turned it into a paper weight) I finally got it configured as a bridge that forwarded DHCP/DNS/Networking to my primary router in my living room. What's better, it actually gets a better signal than my laptop/desktop wireless cards do in the office, and I get better connectivity by hooking them into the switch built into the router than working wirelessly.

Tonight I downloaded ESXi, burned it to a CD and had it installed and running on the server in under 20 minutes. Once this is done and the server restarts, getting started is really simple, just connect to the ESX host IP Address in a web browser and you can download the Virtual Infrastructure Client from the server and begin managing and creating virtual machines:

In the next post, I'll cover creating and configuring the iSCSI target with an OpenFiler Appliance. After that Installing the first node of the cluster and configuring the iSCSI initiator in Windows Server 2008, followed by installing the second node. (At least that is my plan)

Stay tuned for how it progresses.

SQL Server 2005 and 2008 receive Guest Failover Clustering Support from Microsoft

jmkehayias — Tue, 19 May 2009 05:52:39 GMT

Bob Ward blogged about this on the Customer Support Services blog this morning:

SQL Server Support Policy for Failover Clustering and Virtualization gets an update…

Essentially you can now run SQL Server 2005 and 2008 in a Virtualized Failover Cluster as long as the Guest OS is Windows Server 2008 or higher, the selected virtualization vendor meets the requirements for SVVP as outlined in the following article:

Support policy for Microsoft SQL Server products that are running in a hardware virtualization environment

and the Virtualization vendor meets the requirements of the following document:

The Microsoft Support Policy for Windows Server 2008 Failover Clusters.

For further information see the blog post by Bob Ward above.