[libvirt] potential bug in qemu snapshots

[Eric Blake]

Right now, we create qemu snapshots to a file by using an exec: monitor
command that passes 'compressor | { dd && dd; }' with stdout connected
to the target file.  However, since dd is using a larger bs= than
PIPE_MAX, it is conceivable that under heavy machine load, that dd will
get a short read from the pipe, and unless we use the GNU extension of
iflag=fullblock, that short read will be padded out to the output block
size and result in data corruption in the destination file.

The possibility of corruption due to short reads when dd is fed input
through a pipe but produces output through a large block size has
occurred several times on the coreutils mailing list:
http://lists.gnu.org/archive/html/bug-coreutils/2010-11/msg00092.html
Coreutils currently obeys the (non-intuitive) POSIX requirements for
this short read behavior, and while it is being considered to make dd
when POSIXLY_CORRECT is unset be more sensible, you can't rely on that
being a default.

Should we refuse to make snapshots if we don't detect the GNU extension
of 'dd iflag=fullblock'?  Probably safe to do on GNU/Linux machines, but
I'm wondering if it will have negative effects on BSD machines where GNU
coreutils is not installed.

Is there a way to make monitor commands use fd: style migration, where
we can avoid dd altogether by just passing an already open fd that has
already positioned correctly via lseek()?  Then again, it seems like fd:
migration requires passing an open fd, which only seems possible on the
command line at startup rather than something you can do on the fly with
monitor commands.

-- 
Eric Blake   eblake at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20101222/a3445861/attachment-0001.sig>