01.11.2013 10:47, Harald Dunkel wrote:
Hi Michael,
On 10/26/13 13:19, Michael Tokarev wrote:
`kvm' command, in the form it exists now, is a bad practice. If you want kvm
extensions, you have to enable them explicitly and the command should fail if
these aren't available. Or else it behaves in an unpredictable way - sometimes
it will enable kvm, and sometimes will work in tcg mode.
I don't see that this is unpredictable or bad practice. It has
been the expected behavior of the "kvm" tool for years. Surely
everybody is free to use "qemu-system-x86_64" with the appropriate
options instead to get an error message, if hardware virtualization
is not available.
Harald, I think you're just unaware about the amount of issues we
had with this very `kvm' tool behavour in years. In #kvm channel
on irc every second question was something like "why my VM is so
slow", and the next question asked by a support person was "is
kvm enabled?" -- "How to verify?.. oh no, it is not, why it didn't
complain?"
It was just awful. Really. The reasons was different and numerous,
but all boiling down to either lack of support in hardware (or
disabled support, and this feature is still disabled by default
in bios on a lot of new machines), or missing module, or wrong
permissions to /dev/kvm.
(I would guess that more than 99% of all x86/amd64 CPUs running
Linux today _do_ have hardware virtualization, though.)
Yes, except of a few low-end systems such as atom-based, or older
systems. Most comes with svm/vmx turned off by default.
However, things indeed changed today. Not because hardware is
different, but because most users of kvm are using libvirt which
_ensures_ that the kvm is explicitly requested from qemu, and it
fails with a clear error message if it isn't available. Libvirt
also ensures the qemu process is started with appropriate perms,
and that the module is loaded etc.
But even today, people who run qemu/kvm manually, face the same
issues _still_, coming to #kvm asking the same question. And
the issues are still the same -- silent fallback to tcg mode in
case kvm isn't available, which makes it run slow.
BTW, `-machine accel=kvm' is the same as -enable-kvm, which is shorter.
Since "qemu-system-x86_64" has other defaults than the "kvm" wrapper,
you might consider to fix the warning message accordingly, e.g.
"W: kvm binary is deprecated, please use 'qemu-system-x86_64 -machine accel=kvm:tcg'
instead"
It is exactly what I want to _avoid_. People really wanting to use
kvm should use `qemu-system-x86_64 -enable-kvm' (or -machine accel=kvm,
which is the same thing).
But the more I think about this, the more I tend to revert this
whole change. How about this:
- undeprecate `qemu-kvm' package and move the wrapper script to it
- change current -machine accel=kvm:tcg in it to -enable-kvm
First will let to install old (pre-jessie) real qemu-kvm in parallel
with current qemu-system-x86 (in case, for example, when the user
does not want to upgrade qemu/kvm for some machines because of
a regression or whatnot). (And this has nothing to do with the
current discussion).
And second will ensure that guests running using `kvm' command are
really running with kvm extensions enabled, and fail if it isn't
available.
This may break some number of setups where people used kvm command
without kvm exts being available. But I guess these are minority
and it's a good idea for them to fix their setups anyway... Oh
well.
Serge, what do you think?
Thanks,
/mjt
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
