From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:34681) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3DKt-0005ed-8A for qemu-devel@nongnu.org; Thu, 01 Mar 2012 16:14:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S3DKr-0003SH-3Y for qemu-devel@nongnu.org; Thu, 01 Mar 2012 16:14:50 -0500 Received: from [199.101.231.129] (port=12542 helo=STC-EXCH.stc.local) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3DKq-0003Ri-Sd for qemu-devel@nongnu.org; Thu, 01 Mar 2012 16:14:49 -0500 Message-ID: <4F4FE6C6.1070302@storagecraft.com> Date: Thu, 1 Mar 2012 14:14:46 -0700 From: Kai Meyer MIME-Version: 1.0 References: <4F4E9E31.50903@storagecraft.com> <4F4F8FCD.7010106@redhat.com> <4F4FD1C9.8050006@storagecraft.com> <4F4FD7C7.7030001@mail.berlios.de> <4F4FD9A6.9060308@mail.berlios.de> <4F4FE4AA.20902@codemonkey.ws> In-Reply-To: <4F4FE4AA.20902@codemonkey.ws> 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: Anthony Liguori Cc: Stefan Weil , qemu-devel@nongnu.org, Nate Bushman On 03/01/2012 02:05 PM, Anthony Liguori wrote: > On 03/01/2012 02:18 PM, Stefan Weil wrote: >> Am 01.03.2012 21:10, schrieb Stefan Weil: >>> Am 01.03.2012 20:45, schrieb Kai Meyer: >>>> 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? >>> >>> This is not possible if you want to link your image access library >>> statically. >>> >>> QEMU uses GPL v2. You can use a patched QEMU internally, >>> but as soon as you want to give it to customers (or get it integrated >>> in the official source tree), you must publish all code which is needed >>> under an open license. >>> >>> If your image access library is a shared library (linked at runtime), >>> the situation is more difficult. The intention of the GPL is still >>> that you have to publish your code (this is also what the FSF says), >>> but there are different opinions for GPL v2. See >>> http://en.wikipedia.org/wiki/GNU_General_Public_License for >>> more information. >>> >>> I personally don't like the idea of QEMU supporting closed source >>> shared libraries. >>> >>>> 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? >>> >>> You'll need the conditional build for those people who don't want >>> support >>> for your image type. >>> >>> Regards, >>> >>> Stefan Weil >> >> >> I forgot to mention a possible solution: instead of using your image >> access library >> (which is closed source), you could write new access code (maybe with >> reduced >> functionality) and publish that code under an open source license. > > If the "image access library" is solely for use in a proprietary > system, I would be opposed to merging it. > > The only real work around here is to make use of open standard like > iSCSI (which is already supported natively by QEMU). > > Regards, > > Anthony Liguori Ok, pushing support upstream for our image format is looking unlikely, which is understandable. I'll hold off on doing more work then until I can hear from our legal department on whether or not we could distribute a modified version of qemu with out requiring publication of our proprietary source code. If we can't use qemu in general use-cases (since we can't push support for our images up stream), we could still really benefit from a targeted use-cases (like a Rescue Environment.) However, I should say I'm very pleased with how simple (code wise) it was to add support for the image format to qemu. -Kai Meyer