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

[Richard W.M. Jones]

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.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org