Anthony Liguori wrote: > Avi Kivity wrote: >> Jay Mann wrote: >>> Hi, >>> >>> I just downloaded built and installed kvm-84 on ubuntu Hardy x64 >>> 2.6.24-23- >>> server and I’m getting the following 2 problems that did not exists >>> in kvm-83. >>> >>> 1. The qemu emulater (bios screen) takes a long time to start (~10 >>> seconds), and subsequently Libvirt times out when I try to start a >>> guest VM from virsh. >> >> This is caused by qemu r6404: >> >> commit 5d4cbd78aa33f6d034a62207c99ad0b64af44621 >> Author: aliguori >> Date: Thu Jan 22 18:57:22 2009 +0000 >> >> block-qcow2: keep highest allocated byte (Uri Lublin) >> We want to know the highest written offset for qcow2 images. >> This gives a pretty good (and easy to calculate) estimation to how >> much more allocation can be done for the block device. >> It can be usefull for allocating more diskspace for that image >> (if possible, e.g. lvm) before we run out-of-disk-space >> Signed-off-by: Uri Lublin >> Signed-off-by: Anthony Liguori >> >> Scanning the file at startup is slow. We need to find a better way. > > Any quick ideas? Seems like this is broken by design. Unless we can > find a quick fix, I'm going to revert this in the stable tree. > > Regards, > > Anthony Liguori > We only need to scan the given filename (no backing files). We can pass a flag to qcow_open (bdrv_open of bs->backing_hd) specifying it's a backing file. (attached 2 patches). That makes things better for small images with big backing files. It does not fix the problem for very large images. A better solution may we to allocate a qcow2-extension to keep highest-alloc and num-free-bytes so we don't have to scan refcount table of the image upon open. With that solution qcow_create initializes them, qcow_open reads them and bdrv_close updates them. We can also add a qemu-img command to scan and update those values. Regards, Uri.