[libvirt] qemu and <transient/> disks

[Eric Blake]

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 at redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120723/f590976b/attachment-0001.sig>