Re: [Qemu-devel] Guest kernel device compatability auto-detection

From: Avi Kivity <avi@redhat.com>
To: Sasha Levin <levinsasha928@gmail.com>
Cc: qemu-devel <qemu-devel@nongnu.org>, kvm <kvm@vger.kernel.org>,
	"Richard W.M. Jones" <rjones@redhat.com>
Subject: Re: [Qemu-devel] Guest kernel device compatability auto-detection
Date: Thu, 25 Aug 2011 08:33:04 +0300	[thread overview]
Message-ID: <4E55DE90.2020503@redhat.com> (raw)
In-Reply-To: <1314249688.3459.23.camel@lappy>

On 08/25/2011 08:21 AM, Sasha Levin wrote:
> Hi,
>
> Currently when we run the guest we treat it as a black box, we're not
> quite sure what it's going to start and whether it supports the same
> features we expect it to support when running it from the host.
>
> This forces us to start the guest with the safest defaults possible, for
> example: '-drive file=my_image.qcow2' will be started with slow IDE
> emulation even though the guest is capable of virtio.
>
> I'm currently working on a method to try and detect whether the guest
> kernel has specific configurations enabled and either warn the user if
> we know the kernel is not going to properly work or use better defaults
> if we know some advanced features are going to work.
>
> How am I planning to do it? First, we'll try finding which kernel the
> guest is going to boot (easy when user does '-kernel', less easy when
> the user boots an image). For simplicity sake I'll stick with the
> '-kernel' option for now.
>
> Once we have the kernel we can do two things:
>   1. See if the kernel was built with CONFIG_IKCONFIG.
>
>   2. Try finding the System.map which belongs to the kernel, it's
> provided with all distro kernels so we can expect it to be around. If we
> did find it we repeat the same process as in #1.
>
> If we found one of the above, we start matching config sets ("we need
> a,b,c,d for virtio, let's see if it's all there"). Once we find a good
> config set, we use it for defaults. If we didn't find a good config set
> we warn the user and don't even bother starting the guest.
>
> If we couldn't find either, we can just default to whatever we have as
> defaults now.
>
>
> To sum it up, I was wondering if this approach has been considered
> before and whether it sounds interesting enough to try.
>

This is a similar problem to p2v or v2v - taking a guest that used to 
run on physical or virtual hardware, and modifying it to run on 
(different) virtual hardware.  The first step is what you're looking for 
- detecting what the guest currently supports.

You can look at http://libguestfs.org/virt-v2v/ for an example.  I'm 
also copying Richard Jones, who maintains libguestfs, which does the 
actual poking around in the guest.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.