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

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

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