I think it's the system admin to be responsible for the risk of over
provisioning. We have host sparse file[1] (as your example) for
preallocated image (for example, -f raw), as well as sparse image (as
supported in qcow2, vmdk, etc.). There are cases that host file system
is extended or the vm disk is moved to a larger storage when the actual
data grows closer to full, so it's not very practical to limit the
creating size, just as this is quietly valid in linux, no matter how
small your /tmp is.
# df /tmp/ -h
Filesystem Size Used Avail Use% Mounted on
tmpfs 3.8G 14M 3.8G 1% /tmp
# touch /tmp/a
# truncate /tmp/a --size 10000T
# ls -l /tmp/a
-rw-rw-r--. 1 fam fam 10995116277760000 May 8 14:33 /tmp/a
[1]: http://en.wikipedia.org/wiki/Sparse_file
On Wed, 05/08 13:18, yuxh wrote:
> Hello all,
>
> I have to consult you a qemu-img's problem.
>
> Is this reasonable to create a file which is larger than the
> available size of the fs by qemu-img cmd ?
>
> When I use qemu-img create a file which is larger than the available
> size of the fs, the creation is completed succesfully.
>
> However when I use this file in guest as a guest's disk, and write
> beyond the size the host file can provides, the guest was paused by
> qemu-kvm or libvirt and was in maybe a infinite circle where the
> guest just can't be used except I detach the disk from guest or
> destroy the guest.
>
> I read the qemu-img's code and found it just create the file as we
> required and doesn't check if the size we specify is reasonable.But
> this may let the guest in a risk of meeting the problem I describe
> above.
>
> Exp:
> [root@build mytest]# df -ah /mytest/
> Filesystem Size Used Avail Use% Mounted on
> /dev/sdb2 2.0G 3.1M 1.9G 1% /mytest
> [root@build mytest]# qemu-img create -f raw test.raw 3G
> Formatting 'test.raw', fmt=raw size=3221225472
> [root@build mytest]# ls -l test.raw
> -rw-r--r--. 1 root root 3221225472 May 8 12:23 test.raw
> [root@build mytest]#
>
> Thank you.
>
> Best Regards
> Xinghai Yu
>
--
Fam
