Test ----- 1/ Create a 10G qcow2 baseimage(with f17 os on it) - Copy two iso files of 3.4G each into the baseimage's file system (do an scp from host) 2/ Create an overlay pointing to the baseimage, with explicitly specifying "20G" as the size of the overlay (thoug this doesn't matter) 3/ Try to add 3.4G of data into overlay(just again do a copy of existing iso file into the overlay image's file system) Result: Copy obviously fails, but, when we query the overlay image with qemu-img info, it shows the virtual size as '20G' (which is dubious?) Question: If specifying '20G' as size while creating an overlay doesn't matter, shouldn't 'qemu-img' throw an error, when I attempted above, to create the overlay image by explicitly specifying 20G for its size ? (while the base image can only extend to 10G max?) - Answer, refer at the end. Inside the base image's file system: #-----------------------------------------------------------------# [root@largebase ~]# df -hT Filesystem Type Size Used Avail Use% Mounted on rootfs rootfs 10G 817M 8.7G 9% / devtmpfs devtmpfs 493M 0 493M 0% /dev tmpfs tmpfs 499M 0 499M 0% /dev/shm tmpfs tmpfs 499M 640K 498M 1% /run /dev/vda1 ext4 10G 817M 8.7G 9% / tmpfs tmpfs 499M 0 499M 0% /sys/fs/cgroup tmpfs tmpfs 499M 0 499M 0% /media [root@dhcp201-163 ~]# #-----------------------------------------------------------------# After copying two 3.4G ISOs into the baseimage's file system #-----------------------------------------------------------------# [root@largebase export]# df -hT Filesystem Type Size Used Avail Use% Mounted on rootfs rootfs 10G 7.5G 2.1G 79% / devtmpfs devtmpfs 493M 0 493M 0% /dev tmpfs tmpfs 499M 0 499M 0% /dev/shm tmpfs tmpfs 499M 644K 498M 1% /run /dev/vda1 ext4 10G 7.5G 2.1G 79% / tmpfs tmpfs 499M 0 499M 0% /sys/fs/cgroup tmpfs tmpfs 499M 0 499M 0% /media [root@guest export]# #-----------------------------------------------------------------# query the info of base image from host. #-----------------------------------------------------------------# [root@moon vmimgs2]# qemu-img info largebase.qcow2 image: largebase.qcow2 file format: qcow2 virtual size: 10G (10737418240 bytes) disk size: 7.5G cluster_size: 65536 [root@moon vmimgs2]# #-----------------------------------------------------------------# Create an overlay by *explicitly* specifying 20G as its size #-----------------------------------------------------------------# [root@moon ~]# qemu-img create -b largebase.qcow2 -f qcow2 overlay-of-largebase.qcow2 20G Formatting 'overlay-of-largebase.qcow2', fmt=qcow2 size=21474836480 backing_file='largebase.qcow2' encryption=off cluster_size=65536 lazy_refcounts=off [root@moon vmimgs2]# #-----------------------------------------------------------------# From host, query the overlay disk image info recursively: #-----------------------------------------------------------------# [kashyap@moon qemu-n]$ ./qemu-img info --backing-chain /export/vmimgs2/overlay-of-largebase.qcow2 image: /export/vmimgs2/overlay-of-largebase.qcow2 file format: qcow2 virtual size: 20G (21474836480 bytes) disk size: 196K cluster_size: 65536 backing file: largebase.qcow2 (actual path: /export/vmimgs2/largebase.qcow2) image: /export/vmimgs2/largebase.qcow2 file format: qcow2 virtual size: 10G (10737418240 bytes) disk size: 7.5G cluster_size: 65536 [kashyap@moon qemu-n]$ #-----------------------------------------------------------------# Now, let's define an xml for 'overlay-of-largebase' and start #-----------------------------------------------------------------# # virsh start overlay-of-largebase --console . . . [root@overlay ~]# df -hT Filesystem Type Size Used Avail Use% Mounted on rootfs rootfs 10G 7.5G 2.1G 79% / devtmpfs devtmpfs 493M 0 493M 0% /dev tmpfs tmpfs 499M 0 499M 0% /dev/shm tmpfs tmpfs 499M 640K 498M 1% /run /dev/vda1 ext4 10G 7.5G 2.1G 79% / tmpfs tmpfs 499M 0 499M 0% /sys/fs/cgroup tmpfs tmpfs 499M 0 499M 0% /media [root@overlay ~]# #-----------------------------------------------------------------# Now, let's copy a 3.G disk into overlay (just do a # cp /export/file1.iso / ) #-----------------------------------------------------------------# [root@overlay export]# cp -vv rhel5.3-dvd-copy.iso / `rhel5.3-dvd-copy.iso' -> `/rhel5.3-dvd-copy.iso' cp: writing `/rhel5.3-dvd-copy.iso': No space left on device cp: failed to extend `/rhel5.3-dvd-copy.iso': No space left on device [root@overlay export]# #-----------------------------------------------------------------# [root@overlay export]# df -hT Filesystem Type Size Used Avail Use% Mounted on rootfs rootfs 10G 10G 0 100% / devtmpfs devtmpfs 493M 0 493M 0% /dev tmpfs tmpfs 499M 0 499M 0% /dev/shm tmpfs tmpfs 499M 640K 498M 1% /run /dev/vda1 ext4 10G 10G 0 100% / tmpfs tmpfs 499M 0 499M 0% /sys/fs/cgroup tmpfs tmpfs 499M 0 499M 0% /media [root@overlay export]# #-----------------------------------------------------------------# From host, again, just query the overlay disk image info recursively #-----------------------------------------------------------------# [kashyap@moon qemu-n]$ ./qemu-img info --backing-chain /export/vmimgs2/overlay-of-largebase.qcow2 image: /export/vmimgs2/overlay-of-largebase.qcow2 file format: qcow2 virtual size: 20G (21474836480 bytes) disk size: 2.6G cluster_size: 65536 backing file: largebase.qcow2 (actual path: /export/vmimgs2/largebase.qcow2) image: /export/vmimgs2/largebase.qcow2 file format: qcow2 virtual size: 10G (10737418240 bytes) disk size: 7.5G cluster_size: 65536 [kashyap@moon qemu-n]$ #-----------------------------------------------------------------# [root@overlay export]# fdisk -l Disk /dev/vda: 21.5 GB, 21474836480 bytes 255 heads, 63 sectors/track, 2610 cylinders, total 41943040 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x0006a0a9 Device Boot Start End Blocks Id System /dev/vda1 * 2048 20971519 10484736 83 Linux [root@guest export]# Note to self: ---------------- (a) Only the 'virtual size' is 10G, even if a base image spans several overlays, the disk image can have a maximum of 10G - Note: When you do a df -hT inside an overlay image, it shows the consolidated disk size(including the original) (b) If we need more space to accomodate inside the overlay, we could do two things: (1) attach another disk of 10G to it, mount that blk device inside the guest to a mount point, & then copy the iso to this mount point, right?) (2) Or resize the image and the file system on it refer: http://tuxdna.wordpress.com/2011/11/29/how-to-resize-a-vm-and-its-partitions/ ---------------- so, when we do re-size(using a combination of 'truncate' & virt-resize) the overlay disk image( & its file system), now, to '30G' , *but* , the virtual size of the overlay image is 20G(can be see in the bin above). Now how can this new (resized) reality(of 30G) reflect in the 'virtual-size' of the overlay-image when we again query qemu-img info /path/to/overlay.qcow2 ? - this will reflect only when we do either an online resize(qemu's 'block_resize) or offline 'qemu-img resize' - Refer: https://bugzilla.redhat.com/show_bug.cgi?id=515775#c36 https://bugzilla.redhat.com/show_bug.cgi?id=648594#c16 https://bugzilla.redhat.com/show_bug.cgi?id=796526#c12 https://bugzilla.redhat.com/show_bug.cgi?id=693940 https://bugzilla.redhat.com/show_bug.cgi?id=515775 test to do: ----------- - to use the additonal 10G, resize the partion & the file-system inside the guest. - use 'parted'