[one-users] blktap module and image files with "holes"

[Jaime Melis]

Hi Rubén,

Qemu provides an utility to create sparse images. I have compared the
sparse image generated by the dd command and by the qemu-img command,
and although they offer the same functionality, they are not the same:

$ dd if=/dev/zero of=sparse-dd.img bs=1 count=1 seek=1073741823 2>/dev/null
$ qemu-img create -f raw sparse-qemu.img 1G
Formatting 'sparse-qemu.img', fmt=raw size=1073741824
$ ls -l sparse-*
-rw-r--r-- 1 jmelis jmelis 1073741824 Sep 17 12:07 sparse-dd.img
-rw-r--r-- 1 jmelis jmelis 1073741824 Sep 17 12:07 sparse-qemu.img
$ du sparse-*
4       sparse-dd.img
0       sparse-qemu.img

You could try:
exec_and_log "ssh $DST_HOST qemu-img create -f raw $DST_PATH $SIZE"
see if it gives a better result? Make sure you have the qemu utils
installed in the worker node.

regards,
Jaime


On Fri, Sep 17, 2010 at 9:22 AM, Ruben Diez <rdiez at cesga.es> wrote:
> Hi:
>
> Recently, we has study a strange issue about the i/o performance in virtual
> machines created with OpenNebula over xen....
>
> The symptoms of these i/o related issues was:
>
> 1) A massive "scp" command to the VM report various "stalled" status and are
> very slow.
> 2) dd command of the type "dd if=/dev/urandom bs=1M count=500 of=probe.raw"
> fail sometimes (usually after a heavy "scp" stress), by writing less data
> that it would do.
>
> After a lot of tests, we found this:
>
> The problem appears in the disks (usually scratch) created with the  '' type
>   = "fs" '' way in opennebula. When the xen "deployment.0" file is created,
> the blktap module is used (with the xen "tap:aio" mechanism).
>
> OpenNebula creates the scratch disk by using dd for make files "with holes".
> This is very fast, but these archives seems to fail when are used by xen
> with the blktap module...
>
> If in the "tm_mkimage.sh" file we change the line:
>
> exec_and_log "ssh $DST_HOST dd if=/dev/zero of=$DST_PATH bs=1 count=1
> seek=${SIZE}M"
>
> by this one:
>
> exec_and_log "ssh $DST_HOST dd if=/dev/zero of=$DST_PATH bs=1M
> count=${SIZE}"
>
> the problems disappears....
>
> But then the VM deployment is slow, if the scratch disk is large....
>
> The system is a Centos 5.5. The xen hypervisor version is the standard one
> with centos 5.5: the "3.0.3", and the kernel is a "2.6.18-194.8.1.el5xen"
>
> We suppose that this issue is a bug in the blktap module distributed with
> xen. One possibility is to upgrade the xen version. There are a centos xen
> repository at http://www.gitco.de/repo/, but it is only the hypervisor. The
> blktap module seems to be distributed with the xen patched kernel.... Any of
> you know about a centos xen-kernel recent version repository?? Are the
> compilation the only way to upgrade the xen kernel to a recent version???
>
> Regards.
>
>
>
>
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opennebula.org
> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>