Does vmotion require the same chipset or the same CPU or both?

[agrikk]

Like the title says. I'm going to expand my home VMWare lab to three hosts and I'm currently running it on ASUS M2N-SLI Deluxe motherboards (with socket AM2 Athlon 64 X2 4800+ CPUs) and they're pretty scarce on eBay.

I've seen the M2N-E motherboard that's much cheaper since it uses a dumbed down version of the nForce 570 chipset, but the dumbing down is in places where I won't be needing it (no SLI, no SATA RAID, etc).

So my question remains: to ensure that I don't run into any vm masking issues and having vms fail to migrate in vmotion, is it purely a CPU spec issue or does the chipset also have something to do with it?

Can I just plop another socket AM2 Athlon 64 X2 4800+ CPU into a slightly different motherboard and have it all work smoothly?

 

[sabregen]

As long as the CPU's are of the same stepping, VMotion should work. It's looking at the CPU architectures one each of the boxes to determine if a live migration from one host to another is viable.

However, based on your question, I can only assume that you disk configuration will be shared disk, of a supported type that will enable vmotion. Again, this is an assumption. If all of the other VMotion requirements are met, then the answer to your question is yes.

 

[lopoetve]

Sabregen is 99% right. Chipset ~can~ matter, depending on the settings (generally it returns an EDX error for that) and differences. It's mostly CPU, but chipset can have an effect. I don't know any that are incompatible off the top of my head, but I have seen it once.

for yours, it should work just fine, as long as the SATA controller works for isntalling esx.

 

[agrikk]

That works for me. Thanks for your responses.

 

[sabregen]

Sabregen is 99% right. Chipset ~can~ matter, depending on the settings (generally it returns an EDX error for that) and differences. It's mostly CPU, but chipset can have an effect. I don't know any that are incompatible off the top of my head, but I have seen it once.

for yours, it should work just fine, as long as the SATA controller works for isntalling esx.

the man is never happy.

 

[lopoetve]

Sorry

Mostly because every time I find myself saying 100%, someone proves me wrong

And it always bites me in the ass

So I write it down. My little black book of gotchas ain't that little anymore

Someday I should write a storage guide...

 

[zpackrat]

if you hide the nx flag you should be able to vmotion between different cpu models / mfg at a loss of performance.

 

[lopoetve]

if you hide the nx flag you should be able to vmotion between different cpu models / mfg at a loss of performance.

That's only part of the difference - there's also SSE differences, and even x86-64 implementation differences, and there's no way to safely migrate between manufacturers. Some apps will do it fine, others do very poorly. This is why it's blocked by default.

 

[RiDDLeRThC]

Hell I have an issue migrating between a dual core system and a quad core system.

I need to enable EVC for Intel Hosts but can't till all the VM's in my cluster are powered off and my VC is in the cluster.

 

[lopoetve]

Hell I have an issue migrating between a dual core system and a quad core system.

I need to enable EVC for Intel Hosts but can't till all the VM's in my cluster are powered off and my VC is in the cluster.

hint- this is one of the reasons VC as a VM sometimes sucks balls.

I always suggest two physical machines:
1. DNS/DC server.
2. VC server.

Virtualize anything you want, but keep a DNS/DC server out, and keep VC out. IMHO.

That way, even if your entire ESX environment goes KA-BOOM, you still have all the needed infrastructure to troubleshoot and get it back up, without being totally stuck.

You have no idea how nasty it is when your hosts are connecting to NFS via DNS, and the DNS servers are down and on NFS... and your hosts won't come up since HA is hung since it has no DNS, and VC that would let them resolve is on NFS... and RAGEON

 

[RiDDLeRThC]

Hey you dont have to tell me but I work with what I got!

lol two ESX servers clustered, mission critical systems can run on one of the two esx servers without issue.

iSCSI SAN with redundant paths.

all servers/SAN has redundant power supplies.

all servers have a raid 1 for esx itself.

DRS ensures that at least one DNS/DC server is on each ESX host.

 

[RiDDLeRThC]

Any recommendations for getting EVC enabled easily?

From what I understand VMware supports running VC as a VM.

What sucks is I had the cluster created before I ghosted the VC from my VMWare Workstation VM to a VM on the server and just forgot to enable it before hand.

 

[lopoetve]

Any recommendations for getting EVC enabled easily?

From what I understand VMware supports running VC as a VM.

What sucks is I had the cluster created before I ghosted the VC from my VMWare Workstation VM to a VM on the server and just forgot to enable it before hand.

VMware does, that's just something we haven't considered

Migrate VC to a physical box

OR fire it up in workstation again, do thhe conf, and then move the db back. Sucks, don't it?

 

[RiDDLeRThC]

Yeah think i'm going to go that route, it seems the quickest.

I just need to fix my ghostcast server.

No biggy.

I agree it sucks but to get a racked 1u for just VC of two ESX servers would be like asking for a new company car for no reason.

Not going to happen right now, not with how we are watching our spending.

 

[RiDDLeRThC]

lopoetve-

Can I just shutdown the VM of Virtual Center, copy it off the datastore via the VI Client, load it into VMWare Workstation, do my deed and then move it back?

 

[lopoetve]

not exactly, IIRC - they're different vm types.

go to virtual appliance -> export, and export it as a OVF. Workstation can read that