qemu-devel
[Top][All Lists]
Advanced

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

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


From: Kevin Wolf
Subject: Re: [Qemu-devel] Add support for new image type
Date: Fri, 09 Mar 2012 10:23:08 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1

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




reply via email to

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