Re: [Qemu-devel] Add support for new image type

[Kai Meyer <kai.meyer@storagecraft.com>]

On 03/01/2012 01: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.
>
> QEMU uses this approach for some image types where we don't have the
> original source code (for example block/vpc.c or block/vmdk.c).
>
> Regards,
> Stefan Weil
>
I haven't planned on pitching that as a solution, but I will keep it in 
mind.