[libvirt] Patch to enable transient disks in libvirt for qemu

Peter Krempa pkrempa at redhat.com
Mon May 16 06:36:49 UTC 2016


On Sat, May 14, 2016 at 09:10:12 -0400, Richard Harman wrote:
> I'm not a C coder, but hey I managed to get transient disks working.  I
> think there was some discussion years ago on the list about having
> libvirt/qemu dump the transient disk image into a default random temp
> directory wasn't the Right Way To Do Things, and I think interest
> evaporated.

You are right. There wasn't anyone motivated enough to add this feature
properly.

> 
> Anyway, have a patch.

> diff -urN libvirt-1.2.18.2/src/qemu/qemu_command.c libvirt-1.2.18.2-patched/src/qemu/qemu_command.c
> --- libvirt-1.2.18.2/src/qemu/qemu_command.c    2015-12-23 18:21:41.000000000 -0500
> +++ libvirt-1.2.18.2-patched/src/qemu/qemu_command.c    2016-05-06 17:26:55.033133087 -0400

Please post patches against the current git master tree. libvirt-1.2.18
is 9 months old already.

> @@ -3756,9 +3756,7 @@
>          virBufferAddLit(&opt, ",readonly=on");
>      }
>      if (disk->transient) {
> -        virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
> -                       _("transient disks not supported yet"));
> -        goto error;
> +       virBufferAddLit(&opt, ",snapshot=on");

Problem with snapshot=on is that qemu places the snapshot file into the
temp file path as you've pointed out.

Few reasons why this is not a good idea:

1) the temp directory isn't a good place to store huge files
   The file containing the disk overlay may grow up to the total size of
   the disk visible in the guest if every block is overwritten.

   The /tmp directory usually isn't meant to handle huge files for long
   time as it's usually either placed on the root filesystem or backed
   by tmpfs or governed by quotas. Exceeding the empty space on the
   storage will then make the VM fail to write any new sectors.

2) This wouldn't work well with migrations with shared storage.
   As the file is created in a different path than the original storage
   volume and the temp directory is not shared among hosts where the VM
   can be migrated the overlay file won't be accessible after migration.

3) Break of storage and host boundaries
   In some configurations the storage for the VMs is separated from the
   hosts providing the hypervisor. For network bakcked storage as
   gluster or ceph this would create the overlay on the local storage
   rather than the storage technology itself.

Adding the code you are suggesting would add a half-baked feature that
would work only in certain cases.

The correct approach to handle this would be to pre-create a qcow2
storage file in libvirt in the correct storage path and make it refer to
the original volume. The file then needs to be discarded after use.

For apps that use libvirt this is trivial to work around, since they can
pre-create the storage file in any path they wish and use it as source.

Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20160516/f9dc16a4/attachment-0001.sig>


More information about the libvir-list mailing list