All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Stancek <jstancek@redhat.com>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] tst_virt: Make use of systemd-detect-virt if available
Date: Thu, 18 Aug 2016 09:15:49 -0400 (EDT)	[thread overview]
Message-ID: <1783998347.724638.1471526149366.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <20160818123809.GA26650@rei.suse.cz>




----- Original Message -----
> From: "Cyril Hrubis" <chrubis@suse.cz>
> To: ltp@lists.linux.it
> Cc: "Jan Stancek" <jstancek@redhat.com>
> Sent: Thursday, 18 August, 2016 2:38:09 PM
> Subject: [PATCH] tst_virt: Make use of systemd-detect-virt if available
> 
> The problem is that there is no defined way to detect if we are inside
> of a virtual machine, only bunch of heuristics. If you look at the
> src/basic/virt.c in systemd source code it's ~500 lines of code that
> tries many different things to try to guess if we are running
> virtualized and under what hypervisor.
> 
> Currenlty LTP fails to detect KVM in OpenStack Cloud (and possibly many
> more) since the /proc/cpuinfo does not contain the QEMU string there.

I noticed the same in some RHEL KVM guests.

> You can also boot QEMU with non-default -cpu option and you will get the
> same result.
> 
> The easiest solution is to try the systemd-detect-virt first if it
> exists, then we fall back to the previously implemented detections for
> older distributions. This is not complete solution though, as the
> detection still fails with older and non-systemd distributions.
> 
> Signed-off-by: Cyril Hrubis <chrubis@suse.cz>
> ---

We could also add a function that tries "virt-what", to increase our chances.
Anyway, I think it's good idea to not rely just on /proc/cpuinfo.

Regards,
Jan

  reply	other threads:[~2016-08-18 13:15 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-18 12:38 [LTP] [PATCH] tst_virt: Make use of systemd-detect-virt if available Cyril Hrubis
2016-08-18 13:15 ` Jan Stancek [this message]
2016-08-25 14:09   ` Cyril Hrubis
2016-08-31 13:51   ` Cyril Hrubis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1783998347.724638.1471526149366.JavaMail.zimbra@redhat.com \
    --to=jstancek@redhat.com \
    --cc=ltp@lists.linux.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.