Thank you for the question! The process you are referring to is known as VMware High Availability (HA), one of the new features of VMware Infrastructure 3 (VI3). As you were told, VMware HA enables Virtual Machines (VM) running on ESX 3 hosts that belong to VMware HA enabled clusters to fail automatically over to other ESX 3 hosts that belong to the same VMware HA enabled cluster in the case of the failure or isolation of the original ESX 3 host.
So the question then becomes, "Can a VMware HA enabled cluster contain ESX 3 hosts in separate buildings and/or separate VLANs?"
The VMware cluster prerequisites state that "In general, DRS and HA work best if the virtual machines meet VMotion requirements..." (http://pubs.vmware.com/vi3/resmgmt/vc_create_cluster.7.2.html). Of the VMotion requirements, there are two that present a problem for separate buildings and separate VLANs. VMotion requires that participating hosts use shared storage -- typically this is a storage area network (SAN) attached to the hosts by means of a fibre connection. VMotion also requires a private gigabit ethernet migration network between all participating hosts (http://pubs.vmware.com/vi3/resmgmt/vc_create_cluster.7.4.html).
First I will examine the shared storage requirement. If two ESX 3 host servers are in separate buildings then it is cumbersome at best to connect them to the same SAN. It is true that this could be accomplished using a long-distance fibre connection, but this negates the purpose of separating the two ESX 3 host servers to begin with. If the building that contains the first ESX 3 host server and the SAN loses connectivity or power, the remote ESX 3 host server is effectively useless since it cannot access the data on the SAN. Therefore the solution is for each ESX 3 host server to be connected to a separate, local SAN. However, the VMotion requirement clearly states that all participating hosts must use shared storage -- that is have access to the same data -- a requirement that seems to cancel out the solution of separate, local SANs. However, this requirement can be fulfilled using a product by EMC called Mirrorview. MirrorView allows two SANs in separate locations to stay synchronized in real time (MirrorView/Synchronous). This means that even though the two ESX 3 host servers are connected to separate SANs, both servers have access to the same data. This leaves the networking requirement.
VMware reports that VMotion requires that all participating hosts be connected to a private gigabit migration network. While this is a very strong suggestion, it is not a requirement. There are, however, two very good technical reasons for VMware stating that VMotion, and subsequently HA, requires a private gigabit network.
The first reason relates to how VMotion works. VMotion is the process by which the entire state of a running VM is moved to a new host over the wire. The VMotion process could potentially fail or worse, result in a corrupted VM on the target host, if any of the packets containing the state of the running VM were corrupted or did not arrive properly at their destination. Packet loss and corruption typically occur due to heavy network loads, limited bandwidth, header corruption, and hardware problems. This is why VMware requires a private gigabit network for VMotion. VMotion requires the bandwidth and the network segregation to function properly. This is not to say VMotion cannot succeed across VLANs on a public network, it can, but the chance of doing so are diminished greatly because of all the unknown factors.
The second reason relates to HA itself. VMware HA actually consists of two scenarios. The first case is a failed host -- in this case, the other participating hosts should be ready to assume control of the failed host's VMs. The second case is a host that has not failed, but has been isolated from the cluster due to loss of network connectivity -- in this case, the isolated host must know that it is isolated and that it should shut down its running VMs so that the other cluster members can assume control of them. Each of these HA scenarios depend on reliable network connectivity in order to determine when other hosts are down, or when a host is isolated, and a private, or rather dedicated, gigabit network is conducive to this reliability. Like VMotion, HA can succeed on a public network, but the chances of such a success are lessened due to the variables involved.
While a private and dedicated gigabit network is one way to provide fat, exclusive bandwidth, it is not the only way. You could easily set up a fast network devoid of congesting traffic across building and VLAN boundaries with a dedicated ethernet-to-fibre-to-ethernet link between the buildings and a static route between the VLANs. Although this is not exactly what VMware requires, it should work.
So, the answer to the quesiton is technically yes, what you want to do is possible with a little eclectic maneuvering. However, VMware does not currently support the configuration required to make it happen, and I am not aware of any plans on their part to do so in the near future.
Dig Deeper on VMware virtualization
Related Q&A from Andrew Kutz
A user wonders how well Ubuntu will serve him/her in terms of stability, and gets release recommendations from an expert. Continue Reading
This expert's insights will help you make a decision whether to use Ubuntu remote backup. Continue Reading
Learn about an emerging product that aims to decrease time spent fixing dependencies. Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.