[Top][All Lists]

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

Re: [Qemu-devel] [PATCH] Add tar container format

From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH] Add tar container format
Date: Fri, 14 Aug 2009 01:08:03 +0200

On 14.08.2009, at 00:57, Anthony Liguori wrote:

Alexander Graf wrote:
For that we still need to enable the qemu blockery to support stacking though.

Signed-off-by: Alexander Graf <address@hidden>

This feels like a bit too much of a one-off to me. I'm concerned that it's something we'd have to support long term that wouldn't have very many users beyond your particular use-case.

Well, the same goes for "bochs", "parallels", "dmg" and all the other fun image format backends nobody uses, right? How do one or two more hurt you there?

Though I'm not saying that I wouldn't like to see users of this. It's great to have this option for archiving virtual machines (incl. config file) without the need to worry about readability of it. Just tar xzf it and you're done.

Also, we will start using this in SUSE Studio. So all appliances you'll download from there will be in tar.dzip format. That means that if this was in upstream, even fedora or ubuntu users could start those appliances without extracting or even downloading them first.

So far, we only support image formats that are dedicated to virtual machines. We support http and nbd but those are generic protocols, not necessarily special formats. tar and dzip seem arbitrary. Why not zip, rar, bzip2, or any other format?

Simply because this was the only real standard I've found. The dict project uses dictzip for a couple of years now and it seems to be pretty stable (only a single version exists).

Bzip2 is supposed to be chunkable, but I haven't found anyone who did this yet and my knowledge in compression is pretty small. I don't know what rar does, but pkzip has a 2 GB file size limit (which is pretty bad for VM images) and I'm not aware of any seek extensions to it.

If you have good suggestions, please go ahead. We need a VM format container that

  a) everyone can extract with existing tools
  b) can be used as input for qemu

As a sidenote, the OVF specification states that OVF Packages are supposed to be TAR files.

You could do all of this by making use of a fuse filesystem.

Right, but I really don't want to have a server serving a virtual machine rely on anything even close to fuse. What if the fuse client starts hanging? The whole box goes down? No thanks.

I'd almost rather see something like gio integration so that this sort of generic filesystem stuff could live somewhere else. I'm curious what others think though. Does it seem reasonable to include this type of functionality?

A plugin infrastructure sounds nice at first, but doesn't do all the fedoras and ubuntus out there too much good ;-).


reply via email to

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