[Thincrust-devel] packaging of sparse raw disk images

[Bryan Kearney]

Perry Myers wrote:
> Perry Myers wrote:
>> In the latest appliance-tools you can use .tar.bz2 among other formats 
>> for packaging up your appliances.
>>
>> I've tried building appliances with sparse raw disks and a disk that 
>> should have been empty ends up being non sparse (and 20GB of zeros) 
>> after extracting from the tar.bz2.
>>
>> Doing a stupid sanity check, I did the following:
>> qemu-img create -f raw foo.img 100M
>> tar -cvf foo.tar foo.img
>> tar -xvf foo.tar
>>
>> And the image is non-sparse.
>>
>> This really doesn't affect the distribution of appliances, since 
>> whether the image is non-sparse and compressed via gz/bz2 or qcow 
>> compress doesn't matter.  In the end the difference in archive size 
>> will be negligible.
>>
>> Just wanted to point this out...
> 
> Just thought...
> 
> Where this does matter is if you want to package your appliance with a 
> secondary data disk.  Right now there are two methods for doing this:
> 
> 1. Make a large empty secondary disk that is part of the kickstart used to
>    create the appliance.  Using this method, the virt-image XML is created
>    correctly to have both disks and the disk is formatted and mounted
>    properly in /etc/fstab
> 2. Kickstart only contains primary disk, don't create data disk until
>    appliance deployment.  This means the end user will need to:
>    a. Create a disk manually using qemu-img
>    b. Edit virt-image XML to add the new disk
>    c. Boot the appliance with the new disk, partition, format and mount it
> 
> Option 1 is fine until you need to package up the images in a tarball or 
> zip and then you have XGB of compression to do and then when you extract 
> you need to decompress as well.
> 
> If option 2 can be simplified and automated by the appliance-tools then 
> this is not that big of a problem.

Ideally.. I could describe (2) in the virt-image.xml file and have 
virt-image do it for me.

Anyone know if OVF has a similar concept?

-- bk