Reclaim disk space from a sparse image file qcow2/ vmdk

Sparse disk image formats such as qcow2 only consume the physical disk space which they need. For example, if a guest is given a qcow2 image with a size of 100GB but has only written to 10GB then only 10GB of physical disk space will be used. There is some slight overhead associated, so the above example may not be strictly true, but you get the idea.

Sparse disk image files allow you to over allocate virtual disk space – this means that you could allocate 5 virtual machines 100GB of disk space, even if you only have 300GB of physical disk space. If all the guests need 100% of their 100GB disk space then you will have a problem. If you use over allocation of disk space you will need to monitor the physical disk usage very carefully.

There is another problem with sparse disk formats, they don’t automatically shrink. Let’s say you fill 100GB of a sparse disk (we know this will roughly consume 100GB of physical disk space) and then delete some files so that you are only using 50GB. The physical disk space used should be 50GB, right? Wrong. Because the disk image doesn’t shrink, it will always be 100GB on the file system even if the guest is now using less. The below steps will detail how to get round this issue. Continue reading “Reclaim disk space from a sparse image file qcow2/ vmdk” »

Share

Clone KVM-based Virtual Machines on Redhat / CentOS Linux

Prerequisite: Operating System and Software Versions

  • Operating System: – Redhat 7.3
  • Software: – libvirtd (libvirt) 2.0.0

Obtain Source Virtual Machine’s information

Before we begin cloning any virtual machine we first need to obtain some basic information about it. The absolute minimum information required about the source virtual machine we are about to clone would be its name and number of disk in use. To get virtual machines name run:

# virsh list
Id Name State
----------------------------------------------------
1 server1.local running

Next, we may would like to know the number of disk our source virtual machines is using as well as its location. The information about disks location is optional as it only provides us with a hint on where to store new clone disk files for the sake of consistency: # virsh dumpxml server1.local | grep "source file"
<source file='/var/lib/libvirt/images/server1.local.qcow2'/>
<source file='/var/lib/libvirt/images/server1.local-1.qcow2'/>
<source file='/var/lib/libvirt/images/server1.local-2.qcow2'/>

From the above output we can see that our original virtual machine has three disks stored in location /var/lib/libvirt/images/. Continue reading “Clone KVM-based Virtual Machines on Redhat / CentOS Linux” »

Share

Convert .ova and import it on Proxmox KVM virtualization

Let’s start uploading the exported ova file to the proxmox server. Extract the OVA file:

tar -xvf *.ova

This should output a couple of files from the OVA container, it should include an OVF file, which is the VM Defenition file, and a VMDK file, which is the actual hard disk image. Again, this may take a while.

Convert the vmdk to a Proxmox compatible qcow2 file:

qemu-img convert -f vmdk myvirtual-disk1.vmdk  -O qcow2 qcowdisk.qcow2

We now need to get the image into a VM with some hardware so that we can begin to use it. This is where things get tricky – the OVF file is not compatible with Proxmox and needs to be manually understood. The principle here is we are going to use the Proxmox web GUI to create a VM and replace the empty disk image which is created with our recently converted qcow2 image.

You can use vi to open the OVF file and understand some of the basic settings which are required for the VM. Open the OVF file and look for the following XML tags:

  • OperatingSystemSection
  • VirtualHardwareSection
  • Network
  • StorageControllers

Continue reading “Convert .ova and import it on Proxmox KVM virtualization” »

Share