On 12/02/2013 12:17, Reindl Harald wrote:
Am 12.02.2013 12:58, schrieb Gordan Bobic:
On 12/02/2013 10:46, Reindl Harald wrote:
means:
you buy much better hardware with more and faster CPU's
for a single device as you would buy for 20 machines
and most of the day one or two guests can allocate
most of the ressources on their own
Sure, but that's consolidation, assuming you have loads that tessellate nicely. If your load is capable of
saturating the bare metal, your performance will take a substantial hit if you virtualize. If you want to argue
otherwise, describe your test methodology and results. Things may have improved somewhat from Core 2 to Core i, I
haven't re-tested on my most recent hardware - plan to do so in a week or so.
my test methodology is practical workload and not constructed crap
i profile my own web-applications which are highly optimized
And you generated your saturation level load how, exactly? Simple
redneck tests are the ones that hypervisor's smoke-and-mirrors cannot
cheat, and thus the only ones that will show you the true state of
affairs. Otherwise you might as well swallow the marketing brochure
wholesale and stick your head in the sand.
believe it or not, they are faster in a VMware guest as on the host
itself in many cases, both the same Fedora version with binary
identical packages optimized for corei7 and SSE4.2
-O3 -march=corei7 -mtune=corei7 -mmmx -msse2 -msse3 -msse4.1 -msse4.2 -maes -fopenmp -mfpmath=sse
That just tells me you didn't push the machine to full saturation.
Virtualization takes resources, and you cannot go faster by adding
overheads. The only exception to this is where you have hardware
specifically designed for this, with a hypervisor in firmware running on
proprietary resources that a generic bare metal OS wouldn't be able to
access anyway (or at least it wouldn't know what to do with it). In such
cases you have an added bonus that you can reboot the host without
switching off the guests (and without migrating them elsewhere, either).
But hardware like that is very proprietary and uncommon.
Gordan
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
