This is a re-hash of a question I asked a while back - after a consultant has come in firing ideas in to other teams in the department the whole issue has been raised again hence I'm looking for more detailed answers.

We're intending to set-up a multi-instance SQL Cluster across a number of physical blades which will run a variety of different systems across each SQL instance. In general use there will be one virtual SQL instance running on each VM host. Again, in general operation each VM host will run on a dedicated underlying blade. The set-up should give us lots of flexibility for maintenance of any individual VM or underlying blade with all the SQL instances able to fail over as required.

My original plan had been to do the following:

1. Install 2008 R2 on each blade
2. Add Hyper V to each blade
3. Install a 2008 R2 VM to each blade
4. Within the VMs - create a failover cluster and then install SQL Server clustering.

The consultant has suggested that we instead do the following:

1. Install 2008 R2 on each blade
2. Add Hyper V to each blade
3. Install a 2008 R2 VM to each blade
4. Create a cluster on the HOST machines which will host all the VMs.
5. Within the VMs - create a failover cluster and then install SQL Server clustering.

The big difference is the addition of step 4 whereby we cluster all of the guest VMs as well. The argument is that it improves maintenance further since we have no ties at all between the SQL cluster and physical hardware. We can in theory live migrate the guest VMs around the hosts without affecting the SQL cluster at all so we for routine maintenance physical blades we move the SQL cluster around without interruption and without needing to failover.

It sounds like a nice idea but I've not come across anything on the internet where people say they've done this and it works OK. Can I actually do the live migrations of the guests without the SQL Cluster hosted within them getting upset?

Does anyone have any experience of this set up, good or bad? Are there some pros and cons that I've not considered?

I appreciate that mirroring is also a valuable option to consider - in this case we're favouring clustering since it will do the whole of each instance and we have a good number of databases. Some DBs are for lumbering 3rd party systems that may not even work kindly with mirroring (and my understanding of clustering is that fail overs are completely transparent to the clients).

Thanks.