This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-API] XCP: RFC: compressing VM exports by default

To: Dave Scott <Dave.Scott@xxxxxxxxxxxxx>
Subject: Re: [Xen-API] XCP: RFC: compressing VM exports by default
From: Anil Madhavapeddy <anil@xxxxxxxxxx>
Date: Tue, 22 Jun 2010 08:12:29 -0700
Cc: "xen-api@xxxxxxxxxxxxxxxxxxx" <xen-api@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 22 Jun 2010 08:12:36 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <81A73678E76EA642801C8F2E4823AD218080C98A1E@xxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-api-request@lists.xensource.com?subject=help>
List-id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com>
List-post: <mailto:xen-api@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=unsubscribe>
References: <81A73678E76EA642801C8F2E4823AD218080C98A1E@xxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-api-bounces@xxxxxxxxxxxxxxxxxxx
This is possibly out of scope, but I think a really common use-case is to 
shuffle VHD files around.  Have you considered an output format that just moves 
the VHD from the backend directly into the VM export?

In the case of a non-VHD backend then the compressed stream form is good, but 
it seems a pity to duplicate the sparseness checking for the common (VHD on LVM 
or NFS) case.


On 22 Jun 2010, at 07:08, Dave Scott <Dave.Scott@xxxxxxxxxxxxx> wrote:

> Hi,
> In XCP a VM "export" is a serialized VM, including metadata and usually raw 
> disk blocks. The format is a very simple tar file (really stream) with an XML 
> file at the front containing version information and metadata.
> Unfortunately VM exports containing raw disk blocks can be very large and 
> their size makes them difficult to store and distribute over the network. I 
> propose to turn on compression by default by filtering the exports through 
> gzip and to auto-detect both compressed and uncompressed exports on import.
> I've written up my proposal on the wiki:
> http://wiki.xensource.com/xenwiki/Compressing_VM_exports
> One implication is that new (compressed) exports will fail to import on older 
> servers. However (a) there's an easy workaround (gunzip); and (b) I think 
> being able to import an old (uncompressed) export on a new server is more 
> important than the other way around.
> Comments appreciated!
> Cheers,
> Dave
> _______________________________________________
> xen-api mailing list
> xen-api@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/mailman/listinfo/xen-api

xen-api mailing list

<Prev in Thread] Current Thread [Next in Thread>