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

[Sasha Levin <levinsasha928@gmail.com>]

On Thu, 2011-08-25 at 08:32 +0100, Richard W.M. Jones wrote:
> On Thu, Aug 25, 2011 at 08:33:04AM +0300, Avi Kivity wrote:
> > 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.
> 
> Yes, as Avi says, we do all of the above already.  Including
> for Windows guests.

>From what I gathered libguestfs only provides access to the guests'
image.

Which part is doing the IKCONFIG or System.map probing? Or is it done in
a different way?

-- 

Sasha.