[CentOS-devel] The status of our Vagrant images for Hyper-V

Thu Apr 6 12:57:35 UTC 2017
Niels de Vos <ndevos at redhat.com>

On Thu, Apr 06, 2017 at 02:03:55PM +0200, Laurentiu Pancescu wrote:
> Hi there,
> 
> I created the first experimental Vagrant images for Hyper-V on March 14,
> after the CBS upgrade.  They seem to be functional, but they generate a lot
> of disk I/O during "vagrant up", according to Thomas and Michael.  I think
> we end up with 40GB files as disk images - this is the maximum size of the
> virtual hard drives we create, but most of that is empty.  I compared the
> contents of our box file to the one from kozo/centos-7, which is produced
> natively using Packer and Hyper-V: our image contains a real 40GB disk
> image, while the kozo image only has a 2.1GB image.
> 
> Image Factory converts the KVM .qcow2 image to a .vhd by calling "qemu-img
> convert -O vpc <source> <destination>".  This produces a 40GB sparse file
> taking just 1.1GB of space (both with the fixed and dynamic subformats).
> The problem occurs while packing the sparse image into the .box file:
> Python's tarfile module only has read-only support for sparse files (a GNU
> tar extension) - even in Python 3, so the archive ends up with a regular
> 40GB file.
> 
> Creating 40GB sparse files seems to be specific to qemu-img: "VBoxManage
> convertmedium disk box.vmdk box.vhd" produces a 1.1GB regular file
> (VirtualBox' convert tool doesn't seem to support QCOW2, so I had to first
> convert the QCOW2 image to VMDK).
> 
> We should probably either:
> - call GNU tar from Image Factory to preserve the sparseness of our image
> files (and hope that Windows handles them properly)
> - use VBoxManage to convert to .vhd (VirtualBox is not in our repos, but
> Oracle offers a .rpm for EL7 systems).
> 
> In the mean time, we will probably release v1703 without Hyper-V support,
> since CentOS Linux 6.9 was already released.

Maybe you can post-process the large .vhd file with "virt-sparsify"? I
do not know if it would recognize the format, but it is worth to try it.
Otherwise it should be possible to "punch holes" in the large .vhd file
with a little program that calls fallocate(2) on zero-filled areas.

HTH,
Niels

> 
> Best regards,
> Laurențiu
> 
> 
> 
> [vagrant at localhost ~]$ tar -tvzf c7.box  # that's ours
> drwxr-xr-x root/root         0 2017-03-14 11:23 Virtual Machines/
> -rw-r--r-- root/root     39100 2017-03-14 11:23 Virtual Machines/vm.XML
> -rw-r--r-- root/root       114 2017-03-14 11:23 Vagrantfile
> drwxr-xr-x root/root         0 2017-03-14 11:22 Virtual Hard Disks/
> -rwxr-xr-x root/root 42949672960 2017-03-14 11:23 Virtual Hard
> Disks/disk.vhd
> -rw-r--r-- root/root          22 2017-03-14 11:23 metadata.json
> 
> 
> [vagrant at localhost ~]$ unzip -l hyperv.box  # kozo/centos-7
> Archive:  hyperv.box.zip
>   Length      Date    Time    Name
> ---------  ---------- -----   ----
>     36898  02-25-2017 13:05   Virtual
> Machines/1BF518E8-0055-4ABF-8750-E1D703B23A47.vmcx
>     61440  02-25-2017 13:05   Virtual
> Machines/1BF518E8-0055-4ABF-8750-E1D703B23A47.VMRS
>        64  02-25-2017 12:47   metadata.json
> 2185232384  02-25-2017 13:05   Virtual Hard Disks/CentOS7.vhdx
> ---------                     -------
> 2185330786                     4 files
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20170406/6151fa01/attachment-0006.sig>