Re: [libvirt] qemu and <transient/> disks
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(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 620 bytes)