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

[Kai Meyer]

On 03/01/2012 01:10 PM, Stefan Weil wrote:
> 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.
It is a shared library.
> 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.
My primary concern right now is if it is a reasonable course of action. 
I will eventually rely on our internal processes to determine how to 
remain in compliance with exiting licenses.
http://wiki.qemu.org/License
Portions of qemu (ie the qed block driver) are licensed under the LGPL. 
Can you help me understand the impact of licensing our contributions 
under the LGPL instead of GPL?
> I personally don't like the idea of QEMU supporting closed source
> shared libraries.
I'm sorry to hear that, however you are being very helpful, so I 
appreciate that.
> > 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
In addition to the conditional build, would it be appropriate (more 
easily accepted) if there was a run-time check for the existence of the 
library instead of at compile time? This would allow us to enable image 
access on existing systems (that are up to date) instead of requiring 
separate maintenance of qemu versions (ie: hosting our own distribution 
of qemu packages for different platforms, or requiring a rebuild on 
every system.)
> for your image type.
>
> Regards,
>
> Stefan Weil
Thanks!

-Kai Meyer