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

[Nate Bushman]

The encryption is speed-optimized AES256. The compression is proprietary, as is 
common for backup image files, however in hindsight I agree with you. I too 
would prefer for it to all be open. It's possible we maybe able to make such a 
shift. Thanks for your thoughts and suggestions. 

Sent from a phone

On Mar 9, 2012, at 2:19 AM, "Kevin Wolf" <address@hidden> wrote:

> Am 08.03.2012 18:16, schrieb Nate Bushman:
>> You make really good points on opening up the image file format.  I see real 
>> value there in that it would foster development of other solutions around 
>> that format.  The problem in this case is that StorageCraft's backup image 
>> format uses proprietary compression and encryption, and so, regrettably, we 
>> can't (currently) open up that code. 
> 
> This is an interesting statement. Not so much for compression, for which
> I can't know how much better your solution is than common algorithms.
> But I always thought that closed encryption algorithms have to be
> considered bad, because using them would mean relying on security by
> obscurity. Which probably everyone agrees is a bad idea.
> 
>> This is an interesting lesson in retrospect.  We could possibly publish a 
>> spec of the format when encryption and compression aren't used, but in 
>> practice this doesn't happen (compression speeds up the backups because the 
>> CPU time it takes to compress is far less than the time saved by writing the 
>> smaller amount of compressed data to the disk), so because compression saves 
>> both time and space nearly all of our customers use the compression options 
>> at a minimum, and many also use the encryption.
> 
> I see. Though it probably depends on your use case for qemu with these
> images. If you create an image specifically for use with qemu, it could
> make sense to use uncompressed images (or possibly even introduce
> another zlib-compressed mode or something). On the other hand, if qemu
> was to be used to work with already existing images, it wouldn't help.
> 
> Kevin
> 
>> -----Original Message-----
>> From: Kevin Wolf [mailto:address@hidden 
>> Sent: Thursday, March 08, 2012 8:18 AM
>> To: Kai Meyer
>> Cc: address@hidden; Nate Bushman
>> Subject: Re: [Qemu-devel] Add support for new image type
>> 
>> (Sorry, missed the rest of this thread as I was expecting to be kept in the 
>> CC list)
>> 
>> 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?
>> 
>> As other people already said, there's no way that we would accept this.
>> 
>> However, what do you really gain from keeping your file format secret? I 
>> can't imagine that the information required for a (possibly read-only) 
>> properly licensed block driver contains anything of what makes the core of 
>> your products. I can understand that you want to keep sophisticated source 
>> code closed, but I really can't for file formats.
>> 
>> So if you tried to get permission to publish a specification of your image 
>> format and wrote a minimal qemu block driver from scratch, I believe this 
>> would be best for everyone.
>> 
>>> 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?
>> 
>> A conditional build would be required and I'd consider a run-time check 
>> optional.
>> 
>> Kevin
>