On Wed, Mar 14, 2012 at 09:14:46AM +0100, Gerd Hoffmann wrote: > Hi, > > >> Some solutions that come to my mind: > >> > >> 1. Pool the screendump file creation from a timer. > >> > >> Cons: it may return before the file is fully written to disk > >> > > > > We know what the file size should be, so we can poll for the actual > > size. Actually why do we need to poll? we could add a > > "internal.screendump.complete" or "internal-query-screendump", no? > > Marc-Andre currently looks at adding support for other file formats. > I think it would be good to team up with him. > > First, with this applied you will not know the size in advance. Also > one of the approaches discussed is to allow passing in a file handle. > That is a possible way to handle async screendumps too: just write to > the passed file handle and close it when done. Obvious drawback is that > this will not cover the classic way of specifying the output filename as > argument.
This would not be a problem from libvirt's POV - we don't really want a file on disk anyway, nor do we want to pull the whole image into memory. Our ideal approach is to just have an pipe FD with QEMU, which we just incrementally read image data from, and forward to the client app via a libvirt stream object. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
