On 07/23/2012 03:48 AM, Daniel P. Berrange wrote:
On Mon, Jul 23, 2012 at 10:41:55AM +0100, Richard W.M. Jones wrote:
On Mon, Jul 23, 2012 at 10:28:57AM +0100, Daniel P. Berrange wrote:
I agree with the quoted text that libvirt should define a directory to use for the transient disks under /var/lib/libvirt/images perhaps, and just use 'qemu-img create' to create that, and the unlink it once QEMU has started up, so we can auto-cleanup on QEMU shutdown.
I've also seen complaints from people that /var/lib/libvirt can be a space-limited directory; we should really consider adding the notion of a per-VM storage pool (defaulting to a libvirt-internal pool at /var/lib/libvirt, but can be specified by the user to live in a different mount point) for anything that needs potentially large amounts of storage (transient disk wrappers, managed save images, and so forth).
One issue here is that 'qemu-img create' is slow. 0.4 seconds to create a qcow2 file backing another file (ie. per readonly disk, and programs like virt-df may open dozens of readonly disks).
I looked at the strace output and it seems the slowness is just overhead from the machinery of qemu's coroutines, and not connected with writing the qcow2 file, which is presumably why the qemu snapshot=on option is not noticably slow.
Other options available could be
- Enhance QEMU to allow a snapshot directory to be specified - Make libvirt actually create the empty QCow2 file. The QEMU people will probably say this is evil, but the knowledge required to a create an empty qcow2 file pointing to a backing file is pretty tiny.
Especially since libvirt already has the knowledge on how to read a qcow2 file.
Or we could even do both, using the former for new enough QEMU and the latter only for older QEMU
Daniel
-- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org