KVM

Convert Xen XVA to KVM

by

Citrix Xen uses a custom virtual appliance format for import/export called “XVA”. it’s basically a strangely crafted tar-file. You don’t need this program to unpack this tar-file, just use your favourite tar unpacker (tar, gtar, bsdtar). Once unpacked you will end up with a lot of different files, ova.xml (which contains the settings for the virtual appliance, think VMware vmx) and a number of folders called Ref:/, this is your disks. Each of these folders contain hundreds of files named 00000000, 00000001 with a accompanying .CHECKSUM file (SHA1). Each file is a 1MB slice of the disk, but some of the files in the sequence will probably be missing this is because XVA do not use compression; instead it will exclude slices of the disk that only contains zeros (are empty). This tool can assemble the disk for you (you will end up with a RAW disk) that can easily be mounted and modified. It can then also split the file again and generate checksum. Once ready, you will probably want to use the “package” command to rebuild the XVA file.

I’m running this conversion into a Debian 11 Server. First thing, you need to install xvz-img package from git repo into Debian server. Let’s install some essential package first-

Read more

Share

Reclaim disk space from a sparse image file qcow2/ vmdk

by

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.

Read more

Share

Clone KVM-based Virtual Machines on Redhat / CentOS Linux

by

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/.

Read more

Share

Convert .ova and import it on Proxmox KVM virtualization

by

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

Read more

Share