0

BACKGROUND: Up to now, I have been provisioning VMs as follows:

Create template/gold VM:

  • Create new CentOS 6.6 VM with raw 200GB disk (1 .xml file, 1 .img file)
  • LVM partitioning with: /boot, swap, and / partitions (most space in /)
  • Install desired packages

The above results in a VM such as:

200GB /var/lib/libvirt/images/mytemplate.img

To produce guest images from the above I do:

  • dd if=mytemplate.img of=myguest.img iflag=direct oflag=direct (vs cp for better copying speed)
  • use guestfish to modify the /etc/sysconfig/network, /etc/sysconfig/network-scripts/ifcfg-eth0
    • uuidgen and a MAC address generator script generate these ids
    • static ip addresses are pulled from an available pool

The above works just fine: we have one .xml file and one .img file that can easily be moved around our data farm.

PROBLEM: The problem is that the above is thick provisioning. The images are 200GB in size, even though the majority of the image may be unused disk space. I'd like to have these thinly provisioned with a maximum growth size to make moving the images across the network faster. We'd want commands such as df / inside the guest VM to show the maximum size of the guest filesystem if at all possible.

Also, we'd like to consider qcow2 instead of raw for the image file so as to make it possible to take snapshots.

QUESTION: How do I create thinly-provisioned KVM images that are LVM partitioned as described above? Can I virt-sparsify the existing mytemplate.img file and still allow the image to grow to the maximum size and have the / filesystem have the behavior I want? Please feel free to offer alternatives for consideration.

Improve this question

2 Answers 2

Reset to default
1
  1. yes, virt-sparsify is what you need.
  2. to clone VMs, you can use virt-clone
  3. to properly copy disk images, qemu-img convert is the better approach.

To really save disk space, you can make the golden image, then create some snapshots of it using qemu-img, and base your VMs on those snapshots. This way the base data will remain in the base image and the VMs will be on very small images that will only contain the differences between the actual VM and the golden image. The downside will be in performance of course, so the choice is yours, whether to sacrifice space or performance.

Improve this answer
1
  • Can you provide specific details? Actual commands to issue? Also, my question is very much concerned with the max growth of the VM and whether the / filesystem shows the max amount or some smaller amount and whether any resizing is needed or not. Thanks for the proposed answer... more details are needed, though. Also, thanks for suggesting the notion of base image with smaller VMs as a result. Again, can you provide specific details (commands) so that I know exactly what you mean?
    – Steve Amerige
    Feb 4, 2015 at 13:30
0

Replace this:

dd if=mytemplate.img of=myguest.img iflag=direct oflag=direct (vs cp for better copying speed)

With:

cp --sparse=always mytemplate.img mynewguest.img

Assuming your file is sparse on the tail end, that will result in a much much smaller file. If it doesn't result in a smaller file, mount the template image:

kpartx -va mytemplate.img
mount /dev/mapper/loop#p# /mnt/target
dd if=/dev/zero of=/mnt/target/zeroes #let it fill the entire drive.
rm -f /mnt/target/zeroes
umount /mnt/target
kpartx -vd mytemplate.img

Then redo the cp command (don't forget the sparse always part).

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .