From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58987) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3BwE-0001bn-F9 for qemu-devel@nongnu.org; Thu, 01 Mar 2012 14:45:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S3BwC-0006cU-Qj for qemu-devel@nongnu.org; Thu, 01 Mar 2012 14:45:18 -0500 Received: from [199.101.231.129] (port=32186 helo=STC-EXCH.stc.local) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3BwC-0006cC-IU for qemu-devel@nongnu.org; Thu, 01 Mar 2012 14:45:16 -0500 Message-ID: <4F4FD1C9.8050006@storagecraft.com> Date: Thu, 1 Mar 2012 12:45:13 -0700 From: Kai Meyer MIME-Version: 1.0 References: <4F4E9E31.50903@storagecraft.com> <4F4F8FCD.7010106@redhat.com> In-Reply-To: <4F4F8FCD.7010106@redhat.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Add support for new image type List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Nate Bushman On 03/01/2012 08:03 AM, Kevin Wolf wrote: > Am 29.02.2012 22:52, schrieb Kai Meyer: >> Is it possible to extend qemu to support a new image type? I have an >> image type that is ready for consumption and I'm looking for the >> integration point between qemu and the new image format. > Which image format do you want to get integrated? > > Have a look at block/qcow2.c to get an idea of what a qemu block driver > looks like. At the bottom of the file there is a struct that contains > function pointers to all exported functions, so this is usually a good > place to start exploring a driver. > > Kevin Great, this is exactly what we're after. I work for StorageCraft, and we would like to figure out some way to allow qemu to directly consume our image-based backups. It would provide us with user-space mounting (via libguestfs) as well as booting VMs directly from Backup images. We already have a proprietary image access library that provides block-wise access to our image files. I have been able to scratch together a proof of concept already, which I am really pleased with. I see only two roadblocks for which I don't have immediate answers for. 1) Licensing Is it possible to license our contributions in such a way that we do not need to open the source code of our image access library? 2) External dependency on our image access library. We do not want to force qemu to require our image access library to be present to build. Would it be better to do a conditional build (./configure --with-spf) or a run-time check for our image access library?