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

Ruben Diez rdiez at cesga.es
Fri Sep 17 00:22:54 PDT 2010


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 

by this one:

exec_and_log "ssh $DST_HOST dd if=/dev/zero of=$DST_PATH bs=1M 

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 

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???


More information about the Users mailing list