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 <rd...@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@lists.opennebula.org > http://lists.opennebula.org/listinfo.cgi/users-opennebula.org > _______________________________________________ Users mailing list Users@lists.opennebula.org http://lists.opennebula.org/listinfo.cgi/users-opennebula.org