As Wally says you can run VCS inside the virtual host, so here for exampe you would have Vitrual Host A and B and host A would be running App and host B just has O/S running. If Host A or App fails, the App is started on host B. This I am sure you are all familar with if you have run VCS in Solaris
You can run VCS in the hypervisor - VMWare ESX (which is essentially Linux). Here, for the example above, you only have Host A running App and if Host A or App fails, the whole virtual machine fails over to another PHYSICAL host. There is a slight advantage here with less overhead as you have CPU and MEM for one O/S + App, but for VCS running in hosts you have CPU and MEM for 2 Operating systems. Also you only have licence for VCS on physical ESX host and you can run as many virtual machine as you want as oppose to having to licence each virtual host for VCS. But it takes longer to failover as you have to start O/S + App as oppose to just App. Note VCS for ESX does monitor the applications and this is how it differs from VMWare clusters as VCS will fail virtual machine over if app fails whereas VMWare will be unaware app has failed. Also VCS for VMware supports VMotion, but Vmotion is not supported for VCS running inside virtual machines.
For both of these solutions there is no "master" node - each node can take decisions by communicating with other nodes over the private cluster network. For VCS One there is a dedicated decision maker and this is a 2-node cluster called the Policy Master that JUST takes failover decisions for up to 256 nodes in a "farm". The nodes in the farm can be windows, linux or UNIX and you can set-up dependencies (like start DB on UNIX first and then start App on Linux and then web tier on Windows). The Policy Master communicate to the nodes in the farm via public network. You can also do better load balancing with VCS One than VCS if you run multiple apps on each server.
Mike
