Windows guest CPU socket/core recognition
Hello everyone,
I guess I'm not the first one who hit the problem with Microsoft's licensing model..
Nowadays the common single or dual quad-core workstation can't be fully used because it's limited by example: license up to 2 physical processors. Such VM acts like 4-way or 8-way machine.
Is there any way howto expose CPUs differently for this kind of problem?
TIA, Z.
Quoted 8 lines · On Monday 17 August 2009 22:28:35 Zdenek Kaspar wrote:
Hello everyone,
I guess I'm not the first one who hit the problem with Microsoft's licensing model..
Nowadays the common single or dual quad-core workstation can't be fully used because it's limited by example: license up to 2 physical processors. Such VM acts like 4-way or 8-way machine.
Nine times out of ten, a single cpu guest is going to be a better option than a smp/multie core guest. I've seen idle windows guests go from using nearly 200% cpu for -smp 2 to ~5-10% for -smp 1. Unless your guest is actually using all that cpu all the time, you're going to be wasting a decent amount of cycles.
Quoted 2 lines
Is there any way howto expose CPUs differently for this kind of problem?
There have been patches (from Andre Pryzwara and maybe others) to support multi-core vs mult-socket smp.
Quoted 7 lines
TIA, Z.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Brian Jackson napsal(a):
Quoted 11 lines · On Monday 17 August 2009 22:28:35 Zdenek Kaspar wrote:
Quoted 8 lines
Hello everyone,
I guess I'm not the first one who hit the problem with Microsoft's licensing model..
Nowadays the common single or dual quad-core workstation can't be fully used because it's limited by example: license up to 2 physical processors. Such VM acts like 4-way or 8-way machine.
Quoted 5 lines
Nine times out of ten, a single cpu guest is going to be a better option than a smp/multie core guest. I've seen idle windows guests go from using nearly 200% cpu for -smp 2 to ~5-10% for -smp 1. Unless your guest is actually using all that cpu all the time, you're going to be wasting a decent amount of cycles.
Yes, without proper use it's waste. My guest is 64bit and represents node in computing cluster working on assigned jobs (not MPI etc..)
Quoted 5 lines
Quoted 1 line
Is there any way howto expose CPUs differently for this kind of problem?
There have been patches (from Andre Pryzwara and maybe others) to support multi-core vs mult-socket smp.
I will check these patches, thank you (and Dor Laor) for the hint!
Quoted 10 lines · Zdenek Kaspar
Hello everyone,
I guess I'm not the first one who hit the problem with Microsoft's licensing model..
Nowadays the common single or dual quad-core workstation can't be fully used because it's limited by example: license up to 2 physical processors. Such VM acts like 4-way or 8-way machine.
Is there any way howto expose CPUs differently for this kind of problem?
It was discussed on http://www.mail-archive.com/[email protected]/msg18490.html but not yet merged.
Quoted 6 lines
TIA, Z.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 6 lines · Dor Laor
Quoted 5 lines · Zdenek Kaspar
Hello everyone,
I guess I'm not the first one who hit the problem with Microsoft's licensing model..
Quoted 7 lines
Quoted 5 lines
Nowadays the common single or dual quad-core workstation can't be fully used because it's limited by example: license up to 2 physical processors. Such VM acts like 4-way or 8-way machine.
Is there any way howto expose CPUs differently for this kind of problem?
It was discussed on http://www.mail-archive.com/[email protected]/msg18490.html but not yet merged.
I have a reworked version almost ready. The AMD part is working fine, but I still have troubles with the Intel part and threads vs. cores (in the guest). I hope I can fix this still this week.
Regards,
Andre.
Signature · 3 lines
Andre Przywara AMD-OSRC (Dresden) Tel: x29712