Am 29.06.2013 23:38, schrieb Bill Davidsen:
Reindl Harald wrote:
> "model name: QEMU Virtual CPU version 1.0.1"
> what the hell - on VMware you have the same CPU as the host and only "VMware
EVC"
> is filtering CPU capabilities to provide relieable hot-migration between hosts
> by make only the flags of the oldest CPU in the cluster visible to guests
That's why we use KVM, migrations may not be within a cluster. Or be real time
"migrations" as you are thinking of
it, but rather may involve being backed up until the next time there is a support need
for the machine. Different
environment, different goals
the goal of virtualization in production is live-migartion and failover
this way you hve zero downtime at host-upgrades / reboots
> that's why a VMwar eguest has around 95-98 % of the native
performance because
> there is only few binary translation and most instrcutions are passed 1:1
>
And as I remember if there was one old machine in the cluster you wouldn't have the
aes instruction either.
That's from docs, haven't tried VMware in a very long time
that is why i mentioned "VMware EVC"
you hardly need this because any running process inside a virtual machine will crash if
it is using CPU instructions which are not available on the CPU of the target host after
a migartion and with "VMware DRS" the cluster automatically starts
live-migartions
if one host is overloaded while others are idle to spread the load of the guests
in a useful manner to the available hosts
virtualization is the base of my daily job and afer working some time
with this features you never ever setup a server on bare metal for
gain a few percent more peformance with no safety net or way too complex
HA setups inside the machines itself inseatd have them a layer deeper
than your production OS
well, i love opensource and on the guests Fedora/CentOS is running but
until now there is no opensource solution which can beat VMware on
certified hardware with proper support