/usr/bin/kvm-ok should be disassociated from kvm

Confirming this bug.

I suggested last week to put in pciutils. cjwatson nacked that, and I agree it's not the perfect place for this.

Find a good package to put this util in, and I'll gladly sponsor a patch.

:-Dustin

Daviey suggested util-linux, which looks reasonable to me. Adding a task for both packages.

Assuming cjwatson is at least +0 on util-linux, let's remove it from qemu-kvm and add it to util-linux.

:-Dustin

On Mon, 2009-09-14 at 18:33 +0000, Dustin Kirkland wrote:

> Daviey suggested util-linux, which looks reasonable to me. Adding a
> task for both packages.
>
> Assuming cjwatson is at least +0 on util-linux, let's remove it from
> qemu-kvm and add it to util-linux.
>
Only if you do it upstream, please.

Scott
--
Scott James Remnant
<email address hidden>

Actually, I'm moving this from util-linux to update-notifier.

Take a look at Lucid's current update-notifier-common package, which provides /etc/update-motd.d/20-cpu-checker.

I think update-notifier-common should provide /usr/bin/kvm-ok, and the update-motd.d script should run it too.

Kees, what do you think?

I'm going to target this for Lucid beta1 for now, as I think this is totally doable with the approval from update-notifier peeps.

This is sensible. If too much detection stuff like this ends up in update-notifier, I suspect we can just create a new package called "cpu-checker", which is the bzr tree I've current got the check-bios-nx code and test suite in.

On another note, I would like to see kvm-ok improved somehow so that it is accurate after a system has been running for a while. Right now, if a system has been running a while and dmesg has scrolled off the top, or if the "kvm" module hasn't yet loaded, there's no feedback on if VT is disabled in the BIOS.

I really don't see the point in being told on every single login whether or not my CPU has VT extensions?

On Tue, Mar 2, 2010 at 1:11 AM, Soren Hansen <email address hidden> wrote:
> I really don't see the point in being told on every single login whether
> or not my CPU has VT extensions?

That's not how it would work.

See /etc/update-motd.d/20-cpu-checker. The kvm bit would simply check
if it appears you have kvm extensions but they're disabled in BIOS.

On Tue, Mar 02, 2010 at 08:03:12AM -0000, Dustin Kirkland wrote:
> On Tue, Mar 2, 2010 at 1:11 AM, Soren Hansen <email address hidden> wrote:
> > I really don't see the point in being told on every single login whether
> > or not my CPU has VT extensions?
> That's not how it would work.
>
> See /etc/update-motd.d/20-cpu-checker. The kvm bit would simply check
> if it appears you have kvm extensions but they're disabled in BIOS.

Didn't kvm-ok used to be a general check for whether your system had VT
or not as well? Is that part of it gone or is that moving elsewhere?

kvm-ok used to be just a grep for vmx|svm of /proc/cpuinfo.

Now, it performs a couple of additional checks. It will also check
dmesg for a message about kvm being disabled in your bios, and look
for /dev/kvm.

The check for the bios message has been exceedingly useful to users,
and we the maintainers trying to support users who's computer
manufacturers arbitrarily disable kvm in their bios by default. Much
of the documentation spread around the web simply says "grep your
cpuinfo for vmx|svm", but most of it neglects to say, "oh, by the way,
check your dmesg for a kvm disabled in bios message".

This particular bug is really about moving /usr/bin/kvm-ok out of the
qemu-kvm package and into some package the user will already have on
their system when they're trying to decide if they can use kvm or not.

The current mode is clearly suboptimal, which looks like:
 $ sudo apt-get install qemu-kvm
 $ kvm-ok || sudo apt-get purge qemu-kvm

That's clearly silly.

Whether a message ends up in MOTD, I care not. But I thought Kees'
change set a precedent for giving friendly hints about cpu features
which are disabled in BIOS.

On Tue, Mar 02, 2010 at 02:48:40PM -0000, Dustin Kirkland wrote:
> kvm-ok used to be just a grep for vmx|svm of /proc/cpuinfo.

I understand. That's why I didn't want to put it in the kvm package to
begin with.

> The check for the bios message has been exceedingly useful to users,
> and we the maintainers trying to support users who's computer
> manufacturers arbitrarily disable kvm in their bios by default.

I understand the usefulness of the information.

> This particular bug is really about moving /usr/bin/kvm-ok out of the
> qemu-kvm package and into some package the user will already have on
> their system when they're trying to decide if they can use kvm or not.

Right.

> The current mode is clearly suboptimal, which looks like:
> $ sudo apt-get install qemu-kvm
> $ kvm-ok || sudo apt-get purge qemu-kvm
>
> That's clearly silly.

No doubt. Again, that's why I didn't want it in the kvm package to begin
with.

> Whether a message ends up in MOTD, I care not. But I thought Kees'
> change set a precedent for giving friendly hints about cpu features
> which are disabled in BIOS.

Kees' script (IIUIC) is meant to tell users if they have important
security features in their CPU, but for some reason have them turned
off. It's something they're expected to act upon. Just like "Hey,
you've got security updates" is something they're supposed to act upon,
and when acted upon, the notice disappears.

"Yup, you still have VT support" is only vaguely actionable and does not
go away in response to any action you take. I think it makes much more
sense in util-linux.

--
Soren Hansen
Ubuntu Developer
http://www.ubuntu.com/

Changing the affected package to procps, as Kees has agreed to accept kvm-ok there.

Attaching a debdiff that puts the utility in debian/kvm-ok for now, and installs it to /usr/bin/kvm-ok.

This bug was fixed in the package qemu-kvm - 0.12.3-0ubuntu13

---------------
qemu-kvm (0.12.3-0ubuntu13) lucid; urgency=low

  * Rename the default debhelper files to qemu-kvm.*, makes the namespace
    a little more managable as we split this source package up into better
    logical binary packages
    - debian/postinst -> debian/qemu-kvm.postinst
    - debian/doc -> debian/qemu-common.doc
    - debian/links -> debian/qemu-kvm.links
    - debian/install -> debian/qemu-kvm.install
    - debian/upstart -> debian/qemu-kvm.upstart
  * debian/qemu-common.install, debian/qemu-common.links, debian/control:
    - new binary package that contains the architecture independent and
      common files (bios roms, keymaps, documentation, and scripts)
  * debian/rules:
    - populate the binary-indep action to handle the qemu-common package
    - manually prune the keymaps from qemu-kvm, since qemu-common contains
      these now
  * debian/kvm-ok, debian/control: move the kvm-ok script over to the
    cpu-checker package, and recommend this package, LP: #429443
 -- Dustin Kirkland <email address hidden> Mon, 08 Mar 2010 17:18:13 -0600