I'm trying to understand how the various virtualization vendors (specifically Amazon EC2, but also VMware and Xen) enable software vendors to provide a real HA solution in the environment where the servers are virtualized.

Specifically, if I'm running any HA application (exchange, databases, etc) I need to ensure that my redundant virtual "servers" aren't located on the same physical server.

Using in-house virtualization solutions (VMware, Xen, etc) I can provision accordingly as well as check the virtual -> physical arrangement. I could, however, accidentally "vmotion" to the same physical hardware.

With EC2, I don't even have the ability at provision time to select different physical servers. Since their Cluster Compute Instances are 1 virtual server per physical server it seems to be the only way to guarantee I don't have a false sense of redundancy.

Any ideas or thoughts would be helpful. What are others doing about this problem? If the vendors provided an API where I could get something as simple as a unique physical system identifier I could at least know if I'm going to have an issue.



I can only really speak to VMWare. If you are using DRS, you can create rules that will either keep machines on the same physical box, or keep them on separate physical boxes. Even if you accidentally vmotioned to a box with the other machine on it it would vmotion right back off.

| improve this answer | |
  • So I'd be doing that on the provisioning end? Does VMware provide an API from within the VM to understand the physical hardware? Perhaps a call back to their management tools on another server? – tmcallaghan Sep 8 '10 at 17:13
  • I'm not sure about from within the VM, but the management tools have an inherent understanding of the hypervisor topology and you may be able to query that via SNMP (never tried though). – voretaq7 Sep 8 '10 at 17:19
  • 1
    DRS is setup in the management console. If your VM has access over 443 to the managment server, then you should be able to write against the VMWare API to do this. vmware.com/support/pubs/sdk_pubs.html – Zypher Sep 8 '10 at 17:23

If you're using a managed hosted solution, then you simply have to find out what your contract says. You're not managing the machines in that situation, you're buying a service. Find out what you're buying. If the package you buy says that there are no single-point-of-failures, then all you can do is assume they're keeping your VMs on different hardware. If they don't, and it fails, hopefully your contract says you get some money back, free month, something like that.

If you can't manage the systems, why would they give you any access to tell what physical machine your VMs live on anyway? You can't do anything about it. And even if you could ensure that they're not on the same physical host, how do you determine that the SAN has dual fabrics, for example?

For a hosted solution, from a reputable vendor, simply pay attention to what you bought.

edit - From the EC2 page : if you buy machines in one Region, you get 99.95% uptime. You can buy machines in different Availability Zones to get better reliability.

| improve this answer | |
  • I'm not sure how your response applies to a service like Amazon EC2. They are providing virtualized servers and I can run whatever I want inside each VM. They do not, however, make any guarantees as to where the VM physically resides. – tmcallaghan Sep 8 '10 at 17:38
  • Well, that's what I'm getting at. If they sell this service and, per contract, don't guarantee that your VMs are running on different hardware, then you don't have it. And since you can't do anything about it from within the machine, what does it matter if you can find out if they're running on the same box or not. – mfinni Sep 8 '10 at 17:47
  • Also edited my response - right there on the EC2 webpage is how you get what you're asking for. Availability Zones. Without that, all you get is 99.95% uptime, with credit if that isn't maintained. – mfinni Sep 8 '10 at 17:52

Quite often these are running on a shared storage device (a SAN or similar), and the physical hosts all connect to that. So 2 servers that are capable of running a VM both have connections to the shared storage using a clustered file system. When one of the servers fails, the other is told to start running - and it picks up the files on the storage so there's no interruption.

Its difficult to migrate the data for a 30Gb guest from one server to another if one of the servers has died.

The shared storage itself is often set up so its fully redundant, RAID disks and redundant fibre channel/iScsi switches.

| improve this answer | |
  • While this is a decent explanation of the benefit of shared storage for VM (and clustering in general, really), it doesn't address the question in any way that I can see. – mfinni Sep 8 '10 at 18:21
  • sorry - I was explaining how to get a HA environment (1st para of your Q). How to determine whether you actually have one... ask them? – gbjbaanb Sep 8 '10 at 20:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.