On Wed, Feb 20, 2013 at 04:04:49PM +0000, Dietmar Maurer wrote: > > Interesting series, the backup block job makes sense to me. Regarding > > efficiency, I think incremental backup is a must, otherwise regular backups > > using this approach won't really be a win over backing files. > > Incremental backup is something different, not touched by this code. > You can add that later if needed. > > > The backup writer abstraction is a special case interface somewhere > > between an image format and live migration. I'd prefer it if the backup > > block job stuck to BlockDriverState as the destination for backup data. > > Then you could save a point-in-time copy of a disk to a raw or even > > qcow2 image. > > backup needs to work on non-seekable pipes. > > > The vmstate feature looks like vmsave duplication. The problem with > > vmsave is that it doesn't compose nicely with block jobs or the QMP > > transaction command, which would allow you to snapshot the disks and > > then capture the VM state. > > > > How would VMA fit in if the backup block job took a BlockDriverState > > destination and vmsave worked atomically with backup block jobs? You > > could have QEMU write to NBD server ports that a VMA writer process has > > open. VMA would happen outside the QEMU process. > > We want to write to pipes, so what you suggest simply does not work?
Writing to pipes still works, the data is just passed first to a process on the host which writes the archive to the pipe. The archive write process writes to the pipe, not QEMU. Stefan
