No hidden reasons. The statement you quote is just common sense. HA is about increasing reliability and removing single points of failure. Hosting a collective on a single VM hardware pretty much negates these benefits.
Nothing much to add to the KB article 3062OSI8. In our experience, disk I/Os and bandwidth are the most critical resources within a virtualized environment, but it's similar to shared storage solutions (e.g., SAN or iSCSI). For very large workloads, especially with high number of concurrent users, the number of CPU cores might be a limiting factor. I seem to remember that no virtualization product supports more than 4 cores per VM.
So this is a good example of where context is important. HA running across VMs on the same physical host is generally considered not to be a best practice. Denis is 100% right about the technical details of this.
From a use case perspective though it isn't quite as cut and dried. HA provides huge benefits in the manageability department, and so even if the nodes were both on the same VM host you still get a huge chunk of the value of HA.
You also have to look at the robustness of the hardware. If your VM host is a world class Stratus fault tolerant server, and your seperate hardware nodes are 486 Gateway PCs - which setup is more likely to suffer two failuers?
Bottom line is that common sense prevails here. Collective nodes on seperate, solid hardware is the best solution. VMs don't impact this much if they're on seperate hosts. Even on the same host, a collective of virtualized PI servers beats having just a single node.
As for other considerations: the only thing that springs to mind is the VMWare VMotion functionality. With the latest patches (from VMWare) this seems to work acceptibly with the PI system components. However, it's a generalized approach to system availability, where as our HA design is custom taylored for the way PI works. I wouldn't be afraid of VMotion - but I wouldn't use it unless I had HA PI (or ACE, or interfaces, etc.) setup first.
This is a very interesting discussion. I was thinking along the lines of being able to set up a development envirionment where you could test the effect of things like manual entry to a Collection. Or any application that writes to PI.
Could you set up a Collective on a single pc you are using for development, perhaps as 1 VMs on that pc? One of the technical problems here would be connecting to the VMs and they connecting to each other. But assuming you could work out those details, is this the best solution for a collection dev platform short of having 2 spare networked pc's to use? Would it be allowed under the current vCampus licensing?
the vCampus License covers a three node collective - it does not matter if you run three virtual machines or three physical machines from the license point of view.
Some of my collegues are running collectives (multiple VM's) on one physical host. But note that a collective needs at least 2 VMs to be a collective. Managing the networks should not be an issue - the "virtual" world is not much different than the physical in this respect.