[Qemu-devel] RFE- snapshot data storage location configurable

[Qemu-devel] RFE- snapshot data storage location configurable

[dmc]

I have a pretty ugly patch against qemu 0.8 which allows the location of data 
used with the -snapshot feature to be somewhere other than /var/tmp.  I have a 
use-case where I am creating many gigabytes of changes to disk in snapshot mode. 
  When 0.9 came out, I looked, but it seemed less than trivial to update my 
patch, which was a pretty ugly hack to begin with.

I don't suppose anybody else thinks this would be a useful feature?  Or at least 
someone who can rattle off the top of their heads the sorts of things I should 
keep in mind while trying to put it together myself?

A further extension, which I would like, but is also more complex to add, would 
be the ability to specify -snapshot, _per device_.

thanks,

-dmc

Re: [Qemu-devel] RFE- snapshot data storage location configurable

[J M Cerqueira Esteves]

dmc wrote:
> I have a pretty ugly patch against qemu 0.8 which allows the location of
> data used with the -snapshot feature to be somewhere other than
> /var/tmp.  I have a use-case where I am creating many gigabytes of
> changes to disk in snapshot mode.  When 0.9 came out, I looked, but it
> seemed less than trivial to update my patch, which was a pretty ugly
> hack to begin with.
> 
> I don't suppose anybody else thinks this would be a useful feature? 

It would certainly be useful, as I found out yesterday :) while testing
installation of a big software package in a Windows virtual machine in
snapshot mode (with 0.9.0) even though the (Linux) host's /tmp had about
1 GB.

I would suggest at least honoring the TMPDIR environment variable (which
is not being taken into account).


Best regards
                           J Esteves

Re: [Qemu-devel] RFE- snapshot data storage location configurable

[dmc]

[-- Attachment #1: Type: text/plain, Size: 1193 bytes --]

J M Cerqueira Esteves wrote:
> dmc wrote:
>> I have a pretty ugly patch against qemu 0.8 which allows the location of
>> data used with the -snapshot feature to be somewhere other than
>> /var/tmp.  I have a use-case where I am creating many gigabytes of
>> changes to disk in snapshot mode.  When 0.9 came out, I looked, but it
>> seemed less than trivial to update my patch, which was a pretty ugly
>> hack to begin with.
>>
>> I don't suppose anybody else thinks this would be a useful feature? 
> 
> It would certainly be useful, as I found out yesterday :) while testing
> installation of a big software package in a Windows virtual machine in
> snapshot mode (with 0.9.0) even though the (Linux) host's /tmp had about
> 1 GB.
> 
> I would suggest at least honoring the TMPDIR environment variable (which
> is not being taken into account).

Yeah, my 0.8.1 solution was QEMU_COW_TMPDIR, since I was too lazy to do 
something like tracking down all the places in the code that a more general 
TMPDIR should probably be respected.

For what it's worth, attached is my trivial 0.8.1 patch.  I may take a second 
look at updating it, but it's not a high priority for me at the moment.

-dmc


[-- Attachment #2: qemu-0.8.1-cowtmpdirenv.patch --]
[-- Type: text/x-patch, Size: 857 bytes --]

diff -Naur qemu-0.8.1.orig/block.c qemu-0.8.1.cowtmpdirenv/block.c
--- qemu-0.8.1.orig/block.c	2006-06-22 02:14:55.000000000 +0000
+++ qemu-0.8.1.cowtmpdirenv/block.c	2006-06-22 02:23:03.000000000 +0000
@@ -169,8 +169,19 @@
 void get_tmp_filename(char *filename, int size)
 {
     int fd;
+    const char *tmpdir;
+
+    tmpdir = getenv("QEMU_COW_TMPDIR");
+    if (!tmpdir)
+        tmpdir = "/tmp";
+    snprintf(filename, size, "%s/vl.XXXXXX", tmpdir);
+
     /* XXX: race condition possible */
-    pstrcpy(filename, size, "/tmp/vl.XXXXXX");
+    /* COWTMPDIR: I don't understand the possible race condition in the 
+       below line of code, so I have no idea if it still applies to 
+       the above alternate method for creating filename */
+    /*    pstrcpy(filename, size, "/tmp/vl.XXXXXX"); */
+
     fd = mkstemp(filename);
     close(fd);
 }

Re: [Qemu-devel] RFE- snapshot data storage location configurable

[andrzej zaborowski]

On 01/08/07, dmc <dmc@filteredperception.org> wrote:
> I have a pretty ugly patch against qemu 0.8 which allows the location of data
> used with the -snapshot feature to be somewhere other than /var/tmp.  I have a
> use-case where I am creating many gigabytes of changes to disk in snapshot mode.
>   When 0.9 came out, I looked, but it seemed less than trivial to update my
> patch, which was a pretty ugly hack to begin with.
>
> I don't suppose anybody else thinks this would be a useful feature?  Or at least
> someone who can rattle off the top of their heads the sorts of things I should
> keep in mind while trying to put it together myself?
>
> A further extension, which I would like, but is also more complex to add, would
> be the ability to specify -snapshot, _per device_.

I also thought that would be useful earlier but now qcow2 overlays
provide much better flexibility and don't litter the commandline
syntax. I think the currently available choice between -snapshot (for
the simplest possible use case) and qcow2 overlays (for anything more
complex) is a perfect balance for usability and there's no need to add
more switches.

Regards,
Andrzej (away until mid-September(?))

Re: [Qemu-devel] RFE- snapshot data storage location configurable

[dmc]

andrzej zaborowski wrote:
> On 01/08/07, dmc <dmc@filteredperception.org> wrote:
>> I have a pretty ugly patch against qemu 0.8 which allows the location of data
>> used with the -snapshot feature to be somewhere other than /var/tmp.  I have a
>> use-case where I am creating many gigabytes of changes to disk in snapshot mode.
>>   When 0.9 came out, I looked, but it seemed less than trivial to update my
>> patch, which was a pretty ugly hack to begin with.
>>
>> I don't suppose anybody else thinks this would be a useful feature?  Or at least
>> someone who can rattle off the top of their heads the sorts of things I should
>> keep in mind while trying to put it together myself?
>>
>> A further extension, which I would like, but is also more complex to add, would
>> be the ability to specify -snapshot, _per device_.
> 
> I also thought that would be useful earlier but now qcow2 overlays
> provide much better flexibility and don't litter the commandline
> syntax. I think the currently available choice between -snapshot (for
> the simplest possible use case) and qcow2 overlays (for anything more
> complex) is a perfect balance for usability and there's no need to add
> more switches.

Excellent!

Those little tidbits in the documentation ( -b flag for qemu-img create 
) had completely gone under my radar.  That definitely gets me 
everything I want.

Thanks,

-dmc