Hi All,
What are guest cores in KVM? Are they fake, like everything else in the guest? Just another process running on the host emulating a core?
Or are the guest cores actually connected directly to the physical cores on my motherboard?
Many thanks, -T
2010/11/18 MargoAndTodd margoandtodd@gmail.com:
Hi All,
What are guest cores in KVM? Are they fake, like everything else in the guest?
KVM requires VT-x support in your CPU, to get optimal CPU-performance in the guest. Eg. no, it is not emulated like for example the sound card - the virtual CPU uses the hardware virtualization support in your CPU. How is is shown in the guest (eg. the name of it and its capabilities/flags), depends on the options you give to KVM. If you start KVM with the -cpu host argument, your Core i7 cores will get presented exactly as Core i7 cores within the guest, with all the same capabilities as on your host. This is not done by default, as it would make it impossible to migrate from a server with CPU A to another server with CPU B, since the CPUs need to be identical (eg. have the same flags). Therefore the default virtual CPU in most setups is "QEMU CPU vx.xx", which uses the most common CPU capabilities.
Just another process running on the host emulating a core?
Or are the guest cores actually connected directly to the physical cores on my motherboard?
No, they are not directly connected, they are threads on your host.
Just FYI, you *can* start a guest with more virtual cores than you have physically, but you'll see a huge performance hit if you do so (due to some internals of KVM). However, you can still exceed your physical number of cores, and get fair performance, as long as it's spread among several machines. Eg. if you have 2 cores, you can run 2 (or more) guests with 2 CPUs each, but performance will suffer if you run 1 guest with 4 cores.
Best regards Kenni
On 11/18/2010 01:52 PM, Kenni Lund wrote:
2010/11/18 MargoAndToddmargoandtodd@gmail.com:
Hi All,
What are guest cores in KVM? Are they fake, like everything else in the guest?
KVM requires VT-x support in your CPU, to get optimal CPU-performance in the guest. Eg. no, it is not emulated like for example the sound card - the virtual CPU uses the hardware virtualization support in your CPU. How is is shown in the guest (eg. the name of it and its capabilities/flags), depends on the options you give to KVM. If you start KVM with the -cpu host argument, your Core i7 cores will get presented exactly as Core i7 cores within the guest, with all the same capabilities as on your host. This is not done by default, as it would make it impossible to migrate from a server with CPU A to another server with CPU B, since the CPUs need to be identical (eg. have the same flags). Therefore the default virtual CPU in most setups is "QEMU CPU vx.xx", which uses the most common CPU capabilities.
Just another process running on the host emulating a core?
Or are the guest cores actually connected directly to the physical cores on my motherboard?
No, they are not directly connected, they are threads on your host.
Just FYI, you *can* start a guest with more virtual cores than you have physically, but you'll see a huge performance hit if you do so (due to some internals of KVM). However, you can still exceed your physical number of cores, and get fair performance, as long as it's spread among several machines. Eg. if you have 2 cores, you can run 2 (or more) guests with 2 CPUs each, but performance will suffer if you run 1 guest with 4 cores.
Best regards Kenni
Thank you. I am slowly starting to get it.
Do you have a rule of thumb as to how many core to assign to a guest? For instance, with an Intel x5650 with 6 real and 12 hyperthreaded cores, how many cores would you assign to the guest?
Many thanks, -T
Do you have a rule of thumb as to how many core to assign to a guest? For instance, with an Intel x5650 with 6 real and 12 hyperthreaded cores, how many cores would you assign to the guest?
It fully depends on the load of your guests and how many guests you want/need to run on a single server.
You need to perform some testing to know what will work the best in your case. One thing to remember though: In your case, if you create two guests with 12 virtual CPUs each, and one of them crashes and take all its 12 virtual CPUs up to 100%, it will essentially take most of the processing power away from the second guest, leaving the second guest in a close-to-useless state (depending on your scheduler, but you get the point). If you on the other hand had assigned 6 cores to each of them, the second guest would have remained unaffected, since it just uses the 6 cores with no load. So if your guest will not utilize the extra CPUs anyway, then don't assign them.
Best regards Kenni
On 11/18/2010 04:01 PM, Kenni Lund wrote:
Do you have a rule of thumb as to how many core to assign to a guest? For instance, with an Intel x5650 with 6 real and 12 hyperthreaded cores, how many cores would you assign to the guest?
It fully depends on the load of your guests and how many guests you want/need to run on a single server.
You need to perform some testing to know what will work the best in your case. One thing to remember though: In your case, if you create two guests with 12 virtual CPUs each, and one of them crashes and take all its 12 virtual CPUs up to 100%, it will essentially take most of the processing power away from the second guest, leaving the second guest in a close-to-useless state (depending on your scheduler, but you get the point). If you on the other hand had assigned 6 cores to each of them, the second guest would have remained unaffected, since it just uses the 6 cores with no load. So if your guest will not utilize the extra CPUs anyway, then don't assign them.
Best regards Kenni
Thank you! -T
On 19/11/10 11:01 AM, Kenni Lund wrote:
Do you have a rule of thumb as to how many core to assign to a guest? For instance, with an Intel x5650 with 6 real and 12 hyperthreaded cores, how many cores would you assign to the guest?
It fully depends on the load of your guests and how many guests you want/need to run on a single server.
It also depends on what each guest is doing. Some software, like the Postfix MTA, has issues with the timer in a VM and in circumstances like that you want to minimise the number of cores if you can't skip the use of the VM entirely.
Kenni is right, though, test it and see whatever works best for your project.
Regards, Ben
On 11/19/2010 01:43 AM, Ben McGinnes wrote:
On 19/11/10 11:01 AM, Kenni Lund wrote:
Do you have a rule of thumb as to how many core to assign to a guest? For instance, with an Intel x5650 with 6 real and 12 hyperthreaded cores, how many cores would you assign to the guest?
It fully depends on the load of your guests and how many guests you want/need to run on a single server.
It also depends on what each guest is doing. Some software, like the Postfix MTA, has issues with the timer in a VM and in circumstances like that you want to minimise the number of cores if you can't skip the use of the VM entirely.
Kenni is right, though, test it and see whatever works best for your project.
Regards, Ben
Thank you!
On 18/11/10 23:32, MargoAndTodd wrote:
Do you have a rule of thumb as to how many core to assign to a guest? For instance, with an Intel x5650 with 6 real and 12 hyperthreaded cores, how many cores would you assign to the guest?
You may already know this, but don't rely on hyperthreading giving you very much extra. At best it's squeezing some useful work out of what would be a few idle cycles waiting for the instruction pipeline to re-fill. At worst it degrades performance and has been known to be a security hazard.
Therefore, in your given case, think six not twelve. Common advice is to leave one core for the host OS/scheduler. Which leaves you with 5 physical CPUs to allocate.
N
On 11/19/2010 02:25 AM, Nick wrote:
Therefore, in your given case, think six not twelve. Common advice is to leave one core for the host OS/scheduler. Which leaves you with 5 physical CPUs to allocate.
Perfect explanation and rule of thumb. I will stick to the actual cores. Thank you!
-T
-
Ben McGinnes -
Kenni Lund -
MargoAndTodd -
Nick