Different CPU types in XenServer pool
-
Dear community!
I have two old AMD servers, one with 8 Quad-Core AMD Opteron 8347 @ 1908 MHz and 64 GB RAM and the other one with 4 Quad-Core Opteron 8393 SE @ 3100 MHz and 32 GB RAM. I managed to add them to the same pool in XenServer 6.5, so I guess the CPUs are compatible (enough). I am curious as to what has been done in order to mask the differences between the CPUs. I live migrated a VM from one to the other (8347 to 8393), and I noticed that the VM was reporting the old clock speed for the CPU... Does this mean that the faster CPU of the second server will look to the VMs as having the same specs as the older 8347, or will this cahnge when I reboot the VM? Is it better from a performance point of view to keep the two servers separated, not in a pool? -
Its all because of the VM drivers, they allow the VM to rotate between your pool without being forced to have identical hardware.
The XenServer-Tools.iso installs the PV drivers required for this.
-
Unrelated to OP:
Those are good old servers, but be careful with power usage if you're the one footing the bill. They are very thirsty at full tilt (Opt 8393 especially).
-
Yes, I know they are power hungry, but my department doesn't have to worry about the bill -- it's handled by the higher levels in the organization.
Perhaps I phrased the question in a clumsy way since I get no answer... What happens to the virtual CPU of a VM that is migrated from one server to the other? Will the virtual CPU change speed after the VM is rebooted on the new server?
-
The speed will vary per the host, but the VM will still run on any host it gets moved to.
How much of a variance is there between these servers?
-
Well, the one is at 1,9 GHz and the other is 3,1 GHz.
What I mean is, what happens when a VM is live migrated from the 1,9 to the 3,1 host -- what happens to the virtual CPU speed? And what about the other direction? Will a reboot of the VM restore the vCPU speed to local host speed, or what...?
Will the faster of the two hosts in effect have its CPU speed lowered for all VMs in order to look like a heterogenous pool?
-
@flomer said:
Yes, I know they are power hungry, but my department doesn't have to worry about the bill -- it's handled by the higher levels in the organization.
Perhaps I phrased the question in a clumsy way since I get no answer... What happens to the virtual CPU of a VM that is migrated from one server to the other? Will the virtual CPU change speed after the VM is rebooted on the new server?
Yes, the speed will change.
-
@flomer said:
Well, the one is at 1,9 GHz and the other is 3,1 GHz.
What I mean is, what happens when a VM is live migrated from the 1,9 to the 3,1 host -- what happens to the virtual CPU speed? And what about the other direction? Will a reboot of the VM restore the vCPU speed to local host speed, or what...?
Will the faster of the two hosts in effect have its CPU speed lowered for all VMs in order to look like a heterogenous pool?
You are thinking about this very oddly. The VMs have zero say in the speed of the CPU. There is no connection. The VMs run at the speed of the CPU, period.
-
OK. I just started the VM on the host with 1,9 GHz CPUs. When I run 'cat /proc/cpuinfo' it tells me that the "cpu MHz : 1908.811". Then I migrate the VM to the other host (with physical CPU of 3,1 GHz). The two hosts are not now in the same pool. When I run the same command after the migration it tells me that the CPU is still 1,9 GHz. The VM now has a vCPU of speed 1,9 GHz but is really running on a server with CPUs at 3,1 GHz. Hence my question...
I try to reboot the VM and after the reboot the above command gives me the more expected result of "cpu MHz : 3100.172". This seems logical and I can live with this CPU "masking" when migrating a VM from one host to another on an irregular basis.
Now, I am wondering if this means that if the two hosts are put in a pool if the faster host never really will live up to its full potential, due to this "masking" of CPU speeds? Will the faster CPU always be masked as slower, in order to be more like the slower in features? If so, it seems I will lose a lot of computing power when I gain the benefits of a pool... Am I still unclear? -
The reason the servers have to mask the performance in different servers, is so that you can maintain your uptime of your VM's.
Think of it like any real computer, you can just expect it to jump with regards to its system resources without a system reboot. The OS has to investigate the hardware that it has to run with before those changes can be made.
If your pool was built of identical systems you'd never notice the difference. Is there a a major need to have the 3.1 GHz? If so tell management to buy a server that matches.
-
Well, I am just trying to make use of some old hardware here, and buying identical new(old) machines is out of the question.
But, if this means that the faster machine will have to be masked to a lower CPU speed in order to allow for VMs to be live migrated from one to the other in the pool, this means I will better utilize the machines if they are separate, and not pooled. Right?
I will instead have to use some other machines for the VMs that I would like to experiment with HA for. I have three other Intel-based older machines that have identical CPUs, so for this pool this will not be an issue.
-
For all intents & purposes, you can assume that the VM will run at the speed of whatever CPU it is currently on, rebooted or not. It's just like in Windows... Your hardware might support hotplug of extra RAM, but unless your software is configured to accept that, it's not going to see any new RAM until a reboot... Think of the CPU speed value as the same thing...
Essentially, you have hot-swapped a 1.9gHz CPU for a 3.1 gHz CPU... and when you migrate to that faster CPU, you should see a little bit of performance increase (or a lot, depending on what your VM is used for)... However, the OS above the Hypervisor doesn't see that it has changed CPUs because of the way XenServer handles that. If you have to reboot the VM for updates or whatever, it does a complete recheck of the hardware and goes, "Oh, new CPU!" and updates the OS stats.
-
@flomer said:
I will instead have to use some other machines for the VMs that I would like to experiment with HA for. I have three other Intel-based older machines that have identical CPUs, so for this pool this will not be an issue.
I would suggest keeping them in the same pool unless the VMs begin to act strangely after migrations, etc.
-
Hm. So you are saying that a VM that is mirgated form the 1,9 GHz host to the 3,1 GHz host will actually run faster, even though it will not report the correct speed until a reboot? In that case it will be perfectly fine to pool the hosts together, for added flexibility and possible HA-fun
-
@flomer I'm not 100% certain that is the case in XenServer, but I know that was the case when I used coughvmwarecough.
-
OK, I guess I could try and test it if I have the time soon
-
@flomer I would recommend against testing anything in production, unless you want to have a fun day, lol.
/ -
Well, it's on our lab network, and I am playing with and learning XenServer at the moment. I might move some of our production servers from vSphere to XenServer if things work out nicely.
-
Depending on your VMswear licensing, you might make out nicely and save a bit of money and not have to give it to VMware.
-
Yes. At the moment we are having two different Essentials Plus environments, and I must say I am at times very frustrated about the limitations. I mean, why not 5 hosts instead of just three (6 CPUs)?? We are a rather small SMB-type department in a large organization, and I see that XenServer will give us things like live storage vmotion for free, whereas for vSphere I have to shut down the VMs... I am also playing with View, and thinking about virtualizing a few workstations that have powerful GPUs -- for that to work we need full licenses in order for vGPU to work, and this will be prohibitively expensive when we are just talking about 5 users... I feel sometimes that we are cought in the middle. We are a business, but have a small budget. Sigh...
