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