From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Richard W.M. Jones" Subject: Re: [Qemu-devel] Guest kernel device compatability auto-detection Date: Thu, 25 Aug 2011 08:32:12 +0100 Message-ID: <20110825073212.GD3905@amd.home.annexia.org> References: <1314249688.3459.23.camel@lappy> <4E55DE90.2020503@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sasha Levin , qemu-devel , kvm To: Avi Kivity Return-path: Received: from mx1.redhat.com ([209.132.183.28]:22419 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750972Ab1HYHcR (ORCPT ); Thu, 25 Aug 2011 03:32:17 -0400 Content-Disposition: inline In-Reply-To: <4E55DE90.2020503@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53598) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QwUQE-0005Lt-B5 for qemu-devel@nongnu.org; Thu, 25 Aug 2011 03:32:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QwUQD-0005zv-3f for qemu-devel@nongnu.org; Thu, 25 Aug 2011 03:32:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:26915) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QwUQC-0005zi-Sr for qemu-devel@nongnu.org; Thu, 25 Aug 2011 03:32:17 -0400 Date: Thu, 25 Aug 2011 08:32:12 +0100 From: "Richard W.M. Jones" Message-ID: <20110825073212.GD3905@amd.home.annexia.org> References: <1314249688.3459.23.camel@lappy> <4E55DE90.2020503@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E55DE90.2020503@redhat.com> Subject: Re: [Qemu-devel] Guest kernel device compatability auto-detection List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Sasha Levin , kvm , qemu-devel 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