qemu-img baseimage creation doesn't warn for image being smaller

[Muelli]

Binary package hint: qemu-kvm

$ qemu-img create -b ../base-dont-touch.img new.img 10G

should really raise a warning if ../base-dont-touch.img is smaller than 10GB because QEmu apparently does not handle that fact. At least my guest OS didn't boot at all.
Creating an Image of the same resulted in a successful boot though.

In fact, If QEmu doesn't handle a differnent size, even a bigger one, I don't see why qemu-img create -b ... should take a size argument at all. But then again, I don't know whether QEmu handles images backed by a smaller base image.

In any case: The command line tool is very misleading. Right now it reads:

$ qemu-img
qemu-img version 0.11.0, Copyright (c) 2004-2008 Fabrice Bellard
usage: qemu-img command [command options]
QEMU disk image utility

Command syntax:
  check [-f fmt] filename
  create [-F fmt] [-b base_image] [-f fmt] [-o options] filename [size]
  commit [-f fmt] filename
  convert [-c] [-f fmt] [-O output_fmt] [-o options] [-B output_base_image] filename [filename2 [...]] output_filename
  info [-f fmt] filename
  snapshot [-l | -a snapshot | -c snapshot | -d snapshot] filename

Command parameters:
  'filename' is a disk image filename
  'base_image' is the read-only disk image which is used as base for a copy on
    write image; the copy on write image only stores the modified data
  'output_base_image' forces the output image to be created as a copy on write
    image of the specified base image; 'output_base_image' should have the same
    content as the input's base image, however the path, image format, etc may
    differ
  'fmt' is the disk image format. It is guessed automatically in most cases
  'size' is the disk image size in kilobytes. Optional suffixes
    'M' (megabyte, 1024 * 1024) and 'G' (gigabyte, 1024 * 1024 * 1024) are
    supported any 'k' or 'K' is ignored
  'output_filename' is the destination disk image filename
  'output_fmt' is the destination format
  'options' is a comma separated list of format specific options in a
    name=value format. Use -o ? for an overview of the options supported by the
    used format
  '-c' indicates that target image must be compressed (qcow format only)
  '-h' with or without a command shows this help and lists the supported formats

Parameters to snapshot subcommand:
  'snapshot' is the name of the snapshot to create, apply or delete
  '-a' applies a snapshot (revert disk to saved state)
  '-c' creates a snapshot
  '-d' deletes a snapshot
  '-l' lists all snapshots in the given image

Supported formats: cow qcow vmdk cloop dmg bochs vpc vvfat qcow2 parallels nbd host_cdrom host_floppy host_device raw tftp ftps ftp https http

and it doesn't mention the size problem at all. Even creation work without a single warning.

ProblemType: Bug
Architecture: amd64
Date: Sat Apr 17 18:17:28 2010
DistroRelease: Ubuntu 9.10
KvmCmdLine:
 UID PID PPID C SZ RSS PSR STIME TTY TIME CMD
 muelli 26589 26588 13 175490 505084 0 17:41 pts/15 00:04:50 kvm -m 512 -monitor stdio -S -hda elster.img -smb /tmp/ -snapshot
MachineType: LENOVO 766636G
Package: kvm 1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu6
PccardctlIdent:
 Socket 0:
   no product info available
PccardctlStatus:
 Socket 0:
   no card
ProcCmdLine: root=/dev/mapper/cryptroot source=UUID=9c3d5596-27c6-4fd5-bfcd-fa8eef6f1230 ro vdso32=0 quiet splash crashkernel=384M-2G:64M,2G-:128M
ProcVersionSignature: Ubuntu 2.6.32-21.31-generic 2.6.32.11+drm33.2
SourcePackage: qemu-kvm
Uname: Linux 2.6.32-21-generic x86_64
dmi.bios.date: 03/12/2009
dmi.bios.vendor: LENOVO
dmi.bios.version: 7NETC0WW (2.20 )
dmi.board.name: 766636G
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvr7NETC0WW(2.20):bd03/12/2009:svnLENOVO:pn766636G:pvrThinkPadX61:rvnLENOVO:rn766636G:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 766636G
dmi.product.version: ThinkPad X61
dmi.sys.vendor: LENOVO

[lavinog (lavinog)]

What image format is the base image?
I just tested with qcow2 format and increased the size from 6g to 10g just fine (of course the file system size remained the same)
 kvm-img create -b Lucid_64_Base.qcow2 -f qcow2 test_img.qcow2 10G

If you don't specify a format I think raw is used:
kvm-img create -b Lucid_64_Base.qcow2 test_img.qcow2 10G
Unknown option 'backing_file'
qemu-img: Backing file not supported for file format 'raw'

Try using kvm-img info [imagefile]
to see what format is being used.

[Muelli (ubuntu-bugs-auftrags-killer)]

It's qcow2 and increasing size is not what the problem is. The problem is, if the forked image is smaller than the base image. In that case, qemu-img should not create the image in first place.

[lavinog (lavinog)]

"should really raise a warning if ../base-dont-touch.img is smaller than 10GB"
Here you are saying if the forked image is larger than the base image.

"If QEmu doesn't handle a differnent size, even a bigger one, I don't see why qemu-img create -b ... should take a size argument at all."
I just showed that there is a reason why there is a size argument.

If the issue is when the forked image is smaller than the base, I suspect that the issue is that the filesystem was not reduced in size first, kvm-img is not responsible for this. Did you remember to shrink your partitions before shrinking the image size?

Also, you do not need to include a size when using -b with the kvm-image create.
Are you intentionally trying to reduce the disk size? Why? If you are trying to recover space on the host system, you can zero out the free space on the guest (bleachbit can do this) then convert your image using -c to compress the image...then use that image as a base image. Qcow2 images only use up what is needed.

[Muelli (ubuntu-bugs-auftrags-killer)]

You're right. the descriptive text is wrong. In fact, I was typing the bug report up very quickly.

I did not want to change the size of the base image. Basically I just wanted to checkpoint my machine. So in fact, I couldn't bother less about the size and I thought qemu-img made me. But now I've just realised that you don't need to provide a size argument which I thought was mandatory.

Although I think it is very a corner case to reduce the image size and qemu should raise a warning if anybody attempts to decrease the image size, this could probably be closed as NOTABUG or so.