Can vSphere/ESXi run on different CPU architecture?

[alexltk0506]

We want to implement VMware infrastructure and looking into purchasing vSphere Ess. Plus. We are not implementing shared storage. We will have 3 ESXi host total.

I want to save money as much as possible. I have an HP Proliant DL380p Gen8 and a DL385 G7 servers. Per HP, both are compatible with ESXi 6.0. I would like to use these two servers and only have to purchase one server.

The DL380p is Intel and the DL385 is AMD. Can this setup work or do all server need to be Intel?

Thank you,

Alex

[a_p_]

As long as you don't want/need to live migrate (vMotion) virtual machines from one host to another,you can have hosts with different CPU vendors in the same datacenter.

André

[MKguy]

The DL380p is Intel and the DL385 is AMD. Can this setup work or do all server need to be Intel?

Whether this setup "works" depends on what you're trying to do with it.

Yes, you can install and run VMs independently on both, AMD and Intel x86/x64 hosts, you can even put them in a cluster and enable HA (if you have shared storage), but you won't be able to use live migration between these two hosts (which you can still use without shared storage since the introduction enhanced vMotion in ESXi 5.1).

Essentials Plus licenses on a setup that can neither utilize HA due to lack of shared storage, nor use vMotion for live migrations because of incompatible CPUs seems a bit of a waste to me though.

[alexltk0506]

We definitely want to use vMotion. Can be used without shared storage, correct?

Well, looks like we'll need to purchase two servers instead of one.

Does the CPU need to be the same model? For example, would all need to have  Intel Xeon E5 2609 v2 CPU?

Thank you,

Alex

[MKguy · Accepted solution]

We definitely want to use vMotion. Can be used without shared storage, correct?

Yes, it's possible since 5.1, but there are a few things to keep in mind. It's basically a combination of storage vMotion, transferring the VM disks from one storage device to another and a regular vMotion, transferring a live running VM from one host's memory to another.

As such it's nowhere as dynamic as a normal vMotion alone, since copying VM disk data can take a long time. There is also no DRS support.

You can read on some more here: http://wahlnetwork.com/2012/11/21/leveraging-vmwares-enhanced-shared-nothing-vmotion/

Does the CPU need to be the same model? For example, would all need to have  Intel Xeon E5 2609 v2 CPU?

No, the basic requirement to transfer a live running OS is that both, source and destination host support the same CPU instruction sets. Exact model, Mhz clock rate, cache size etc. are irrelevant as long as the CPU instruction sets are identical. So no, they don't have to be the exact same model.

Additionally, you can enable Enhanced vMotion Compatibility (EVC) on a cluster of hosts with the same CPU vendor, which allows you to set the lowest common denominator of a CPU generation between different hosts. For example, the Xeon E5 2609 v2 you mentioned is an Ivy Bridge generation CPU. If you add a Sandy Bridge generation Xeon you would set the EVC mode to Sandy Bridge, as it's the oldest generation in your cluster and containing all common instruction sets that are also present in the newer generation Ivy Bridge host. If you add a

host with Haswell generation CPUs, you would set the EVC mode to Ivy Bridge respectively.

EVC will mask the newer instructions to VMs to ensure they can be live-migrated to all hosts.

You would need to keep the AMD host out of your cluster but that doesn't really make any difference in your case since vMotion will never work between AMD and Intel and you can't use VMware HA because you're lacking shared storage. Just be aware that VMs on the AMD host will never be able to migrate to the other hosts without downtime via Enhanced vMotion.

Check these articles for details about EVC:

VMware KB: Enhanced vMotion Compatibility (EVC) processor support 

VMware KB: EVC and CPU Compatibility FAQ 

[alexltk0506]

So if I don't implement shared storage then I wouldn't need vMotion, correct? My understanding with vMotion (not Storage vMotion) is that in a setup with shared storage I can more VMs from one host to another and take the host offline for maintenance. But, if I don't have shared storage I can still use vMotion, but the storage is still on the host and would have to move it before I can take the host offline for maintenance, for example, correct?

The organization does want some sort of HA, but not at the 24/7 level. The most critical application/server can be done for 1 hour everything else is in the range of 1 to 4 hours. Their backup solution can integrate with vSphere for backup and recovery. If a VM or ESXi host goes down I can spin up the VM in matter of minutes directly from the backup device or the cloud and users can still access the application/server. During this time I can repair the server or recover the VM to another host.

On the other hand, shared storage is not out of the question, yet. This is still being considered. Well, at least until the Org. gets the quote for a Storage Array. (:

Not sure what route to take.

Thank you for the information you provided.

--Alex

[MKguy]

So if I don't implement shared storage then I wouldn't need vMotion, correct? My understanding with vMotion (not Storage vMotion) is that in a setup with shared storage I can more VMs from one host to another and take the host offline for maintenance. But, if I don't have shared storage I can still use vMotion, but the storage is still on the host and would have to move it before I can take the host offline for maintenance, for example, correct?

Let me phrase it like this:

1. vMotion helps you with planned maintenance on a physical host (including updates, patches maintenance on its physical interconnects and whatnot) by migrating a live running VM from one physical host to another and it does not incur downtime. It will be a manual process in your case and take quite some time if you don't have shared storage, because the whole VM disk data needs to be transferred over the network. Most cluster environments use shared storage that makes vMotion a no-brainer and also enables DRS.

2. VMware HA is a cluster feature that protects you against unplanned physical hardware failure or hypervisor failure (PSOD) by restarting the VMs on different hosts of the cluster. It's automatic but the process WILL incur a short (usually application-wise 1-3m, depending on how long it takes to boot and initialize) downtime as the memory state of the VMs is lost and they undergo a complete boot cycle (basically it's as if you push the physical reset button on your server).

HA requires shared storage because the new host somehow needs to access the source VM data files if the other host has failed. Without shared storage you will first have to somehow get the data to the surviving host through backups, recovering the failed host or its disks or whatever.

It's a very manual process and can take some time for multiple VMs and you should cross fingers that you planned the disk space accordingly to put all VMs on a single host.

[alexltk0506]

I still have more research and planning to do, but I think I will start implanting the idea of shared storage to management. Like you said, vMotion and DRS is a no-brainer.

Thanks. You've given me enough info to start with.

Best regards,

Alex