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" <kw...@redhat.com> 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:kw...@redhat.com] >> Sent: Thursday, March 08, 2012 8:18 AM >> To: Kai Meyer >> Cc: qemu-devel@nongnu.org; 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 >
