Stacklet is changing the virtual disk formats used for Xen, XCP and KVM:
Xen 3/Xen 4; XVA
Since 2004 we have been using sparse images containing a single ext3 partition for images targeted for Xen PV. This has the advantage of being easy to loop mount and edit, as well as being highly compatible with the various generations of xen hypervisors, pygrub/pvgrub and higher-level control panels. We are retaining this format but transitioning to ext4 as the root filesystem of the domU image. Since the XCP templates are direct derivatives of the xen images this will also apply to our xva files. The recent builds of Fedora, Gentoo and Arch Linux have already made this transition without any apparent issues.
The downside is simply that users with old dom0 environments may be unable to loop mount an ext4 image or properly boot an ext4 image using pygrub.
KVM
In the full virtualization realm we have been using ext4 for a while now, embedded in a qcow2 disk image. The change here is that kvm images henceforth will be encoded as sparse raw disk images. This will achieve two things: better integration with various environments that use raw disk images exclusively or as a default. Also, it provides easier manipulation of an image with CLI tools. The downside is that qcow2 has features not available to raw disk images (eg snapshots), but this is mitigated by the fact that raw disk images can be trivially and rapidly converted to qcow2 using "qemu-img convert". [Conversions with qemu-img are bidirectional if you want to change a qcow2 to raw]. We should also mention that sparse images are best uncompressed with Gnu or BSD tar since many compression tools silently fail extracting sparse files.
SolusVM
None of the above changes impact SolusVM users since in the SolusVM Xen PV space the control panel creates the filesystem upon deployment (ext3) and there is still no KVM image format supported by SolusVM as of this writing, aside from iso.
