If you watched the demonstration blogcast of Virtual Server 2005 R2 I posted up at the weekend, yesterday, I ripped the environment apart to build it again from scratch so you can see how I built it.
The last part of this mini series is where we setup the networking on the Virtual Machine guest we are making highly available through host clustering. In my scenario, I deviate from the whitepaper on host clustering as the network cards between my two hosts are different. In the whitepaper, you place the .vnc file for the network on the shared drive. I also show you once more what happens during unplanned downtime by power-cycling one of the nodes in the cluster.
So that's all you need to know about host based clustering using Virtual Server 2005 R2 in conjunction with Windows Server 2003 Clustering Services. Have fun, and please let me know if you found this useful!Click here to view part 5.
Part 1Part 2Part 3Part 4
Part 1Part 2Part 3Part 4
Question sir...I watched your entire videos relating to the Virtual Server R2 HostClustering and noticed that the cluster nodes are laptop and desktop. I'm no cluster expert, but I though cluster nodes are "suppose" to be identical. I'd like to this to my small client's setup due to hardware differences / costs. Basically, with what you did is okay to do...although I know not recommended or best practices cluster still will work for non-similar hardware (host hardware). Thanks - great technical BLOG.
Putting support to one side, to fail over a VM from one node to another in a planned downtime requires the VM to be put in "saved state" and restarted on another node. For this to work, there are several requirements from a processor perspective. It so happened that both the desktop and laptop machines were Intel Pentium 4 3.2 MHz processor with the same stepping (although one was mobile, this did not matter). I put more information on this on my blog a few days ago: http://blogs.technet.com/jhoward/archive/2005/12/19/416244.aspx. For _unplanned_ failover, idential hardware is not so much of a requirement as the VM is restarted on another node. So from that perspective, it would have worked if one machine were running an AMD processor and the other an Intel processor.
As you saw, you _can_ cluster together very successfully two quite different machines with different network cards and still get high availability with virtual machines, it's just very unlikely to be supported.
The best place to look for requirements for _supported_ cluster environments is following links from http://www.microsoft.com/windowsserver2003/technologies/clustering/default.mspx.
Hope that helps.
John, how do you put multiple servers in the havm.vbs
Brian - it should be exactly the same as building a cluster of more machines - havm.vbs is simply the failover script. If you have look at technet for info on building clusters, that's the process to follow. havm.vbs won't care regardless of number of nodes.
I guess I was a little vague. I actually meant how can I, if I can, attach multiple vmc's to one script.
Unfortunately, as far as I'm aware that isn't possible using the script as it stands - I would test it, but have no demo kit available. When you configure the script resource, you specify the name of the VM it is failing over. With a little tweaking, you could _in theory_ have multiple parameters with names of multiple VMs, but this would deviate from the supported script - and I re-iterate, I haven't tested this. The supported solution would be to have multiple groups, one per virtual machine.
Jon, before we went to host clustering for virtual server, we had our virtual's set up to boot at intervals. Is there any way to tell the havm.vbs script to delay the resume of a machine after the resource comes online?
You should be able to do this in a couple of ways. One is to introduce a new resource to the cluster group which is a generic script with a single line "wscript.sleep 5000" for example which will cause a 5 second delay. Then make sure that the havm script is dependent on the delay script. You can get more inventive by using another cluster private "variable" such that havm already uses to define how long to delay for.
The other solution is to hard code the delay into the havm script. However, probably best to leave that well alone and use the generic script as-is.
Hope that helps
I've sent this out to several folks that wanted to learn more about VS.&nbsp; Here are a few resources...
Virtual Server 05 R2 es gratis, tambien es importante el entranemiento para completar la oferta....aqui...
Here's a good question emailed to me yesterday. If you seen&nbsp;the Virtual Server 2005 R2 Host Clustering...
In response to the Havm.vbs posted by Brian, would it matter if you copied havm.vbs to same directory and renamed it to havm2.vbs and associated the second VS to havm2.vbs (VS1 to havm.vbs and VS2 to havm2.vbs), which would allow for both VS's to run using the same scripted commands in files with different names?
Microsoft have released today 4 new whitepapers for Microsoft Virtual Server. They all are about ~20