ML
    • Recent
    • Categories
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    Different CPU types in XenServer pool

    IT Discussion
    xen xenserver virtualization xenserver 6.5 amd amd64 opteron
    5
    29
    8.6k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • F
      flomer
      last edited by scottalanmiller

      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?

      1 Reply Last reply Reply Quote 1
      • D
        DustinB3403
        last edited by

        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.

        1 Reply Last reply Reply Quote 0
        • M
          MattSpeller
          last edited by

          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).

          1 Reply Last reply Reply Quote 0
          • F
            flomer
            last edited by

            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?

            S 1 Reply Last reply Reply Quote 0
            • D
              DustinB3403
              last edited by

              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?

              1 Reply Last reply Reply Quote 0
              • F
                flomer
                last edited by flomer

                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?

                S 1 Reply Last reply Reply Quote 0
                • S
                  scottalanmiller @flomer
                  last edited by

                  @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.

                  1 Reply Last reply Reply Quote 0
                  • S
                    scottalanmiller @flomer
                    last edited by

                    @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.

                    1 Reply Last reply Reply Quote 0
                    • F
                      flomer
                      last edited by flomer

                      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?

                      S 1 Reply Last reply Reply Quote 0
                      • D
                        DustinB3403
                        last edited by DustinB3403

                        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.

                        1 Reply Last reply Reply Quote 1
                        • F
                          flomer
                          last edited by

                          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.

                          D S 2 Replies Last reply Reply Quote 0
                          • D
                            dafyre
                            last edited by

                            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.

                            1 Reply Last reply Reply Quote 0
                            • D
                              dafyre @flomer
                              last edited by

                              @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.

                              1 Reply Last reply Reply Quote 0
                              • F
                                flomer
                                last edited by flomer

                                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 😉

                                D 1 Reply Last reply Reply Quote 1
                                • D
                                  dafyre @flomer
                                  last edited by

                                  @flomer I'm not 100% certain that is the case in XenServer, but I know that was the case when I used coughvmwarecough.

                                  S 1 Reply Last reply Reply Quote 0
                                  • F
                                    flomer
                                    last edited by

                                    OK, I guess I could try and test it if I have the time soon 😉

                                    D S 2 Replies Last reply Reply Quote 0
                                    • D
                                      dafyre @flomer
                                      last edited by

                                      @flomer I would recommend against testing anything in production, unless you want to have a fun day, lol.
                                      /

                                      1 Reply Last reply Reply Quote 0
                                      • F
                                        flomer
                                        last edited by

                                        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.

                                        S 1 Reply Last reply Reply Quote 1
                                        • D
                                          dafyre
                                          last edited by

                                          Depending on your VMswear licensing, you might make out nicely and save a bit of money and not have to give it to VMware.

                                          1 Reply Last reply Reply Quote 0
                                          • F
                                            flomer
                                            last edited by

                                            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...

                                            D S 3 Replies Last reply Reply Quote 1
                                            • 1
                                            • 2
                                            • 1 / 2
                                            • First post
                                              Last post