Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I'm looking for a way to generate, or derive, a unique CPU identifier. For example:

If SERVER_A uses vmotion from HOST_A to HOST_B, I want to be able to tell the differences between the cpus.

Any idea?

share|improve this question
    
This needs to be inside from SERVER_A. So inside the vm guest, and not the ESX/VMWARE host. –  awojo Aug 25 '12 at 1:32
1  
Lemme guess - you're trying to figure out how to restrict the license of your product to a single host. –  EEAA Aug 25 '12 at 1:33
    
I think you mean 'host' or 'hypervisor', not 'CPU'. After all, the hypervisor could shift your guest VM to another CPU on the same host... –  Patrick Aug 25 '12 at 1:42
    
No sir. I am just trying to find the difference between each vmotion'd location. I have a need to sort of map between two different CPU's. –  awojo Aug 25 '12 at 1:42
    
What about multiple CPUs on the same host? If you do find an identifier, will it change if the hypervisor switches you to one of the other CPUs? I'd imagine that there is no way around this without pinning a VM to specific CPUs. I'm hoping someone has a good answer, because I've spent a lot of time researching this myself. The best answer I've been able to find is to add something to the config on the host that the VM can query via vmware-tools (but you have to have total control over the environment). –  Jed Daniels Aug 25 '12 at 2:00

1 Answer 1

What specific information are you seeking?

There has to be a baseline of CPU compatibility in an existing vMotion arrangement. vMotion doesn't function without it. See the descriptions of the Enhanced vMotion Compatibility (EVC) function within VMWare.

With EVC, you can be sure that the CPU capabilities of each host are consistent (or at least a common subset of the available features).

CPU information is also available within the guest operating system.

  • If Linux, dmidecode and cat /proc/cpuinfo will display some of the host CPU specification.
  • In Windows, this is available in the System Control Panel. Outside of that, host CPU information is visible in the vSphere client.

enter image description here

At the ESXi host level, esxcfg-info -w provides hardware information, including CPU specs.


Edit:

If the goal is to tell the difference between host servers, this would be very easy if the CPU's are different. At that point, something like the suggestions above would work.

If the hosts are identical, you either need to tap into the VMWare API, or use the suggestion from Stack Overflow, which involves disabling a VMWare security setting and establishing a unique identifier for the host.

You can set machine.id = "<string>".

share|improve this answer
    
I need it to be within the guest operating system, can't be at the ESXi host level. Basically what I'm trying to do is get the DIFFERENCE between HOST_A and HOST_B. All I need is some sort of hash or uid, or some sort of unique identifier so that I can tell the difference between the two hosts. It has to be within the guest operating system though. –  awojo Aug 25 '12 at 1:41
    
See my edit above. –  ewwhite Aug 25 '12 at 1:58
    
What is your actual obective? –  Simon Catlin Aug 25 '12 at 14:00
    
@awojo. Maybe I'm missing something... or am just super brilliant... but isn't the point of virtualization that differences between hosts shouldn't matter to or even be accessible by the guest OS? –  HopelessN00b Aug 25 '12 at 18:33
    
Yes, but when you're trying to determine performance data, you want to be able to track when you switch physical hosts (for calculating purposes). Having some sort of identifier would enable that. It can be done by tapping into the ESXi host, but I want to do it without deprecating any security controls. –  awojo Aug 25 '12 at 21:19

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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