[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Kai Meyer
Subject: Re: [Qemu-devel] Add support for new image type
Date: Thu, 1 Mar 2012 14:14:46 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20120215 Red Hat/3.1.18-2.el6_2 Lightning/1.0b2 Thunderbird/3.1.18

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.


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.


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).


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]