Re: [Qemu-devel] Safely reopening image files by stashing fds

[Kevin Wolf <kwolf@redhat.com>]

Am 05.08.2011 10:40, schrieb Stefan Hajnoczi:
> We've discussed safe methods for reopening image files (e.g. useful for
> changing the hostcache parameter).  The problem is that closing the file first
> and then opening it again exposes us to the error case where the open fails.
> At that point we cannot get to the file anymore and our options are to
> terminate QEMU, pause the VM, or offline the block device.
> 
> This window of vulnerability can be eliminated by keeping the file descriptor
> around and falling back to it should the open fail.
> 
> The challenge for the file descriptor approach is that image formats, like
> VMDK, can span multiple files.  Therefore the solution is not as simple as
> stashing a single file descriptor and reopening from it.

So far I agree. The rest I believe is wrong because you can't assume
that every backend uses file descriptors. The qemu block layer is based
on BlockDriverStates, not fds. They are a concept that should be hidden
in raw-posix.

I think something like this could do:

struct BDRVReopenState {
    BlockDriverState *bs;
    /* can be extended by block drivers */
};

.bdrv_reopen(BlockDriverState *bs, BDRVReopenState **reopen_state, int
flags);
.bdrv_reopen_commit(BDRVReopenState *reopen_state);
.bdrv_reopen_abort(BDRVReopenState *reopen_state);

raw-posix would store the old file descriptor in its reopen_state. On
commit, it closes the old descriptors, on abort it reverts to the old
one and closes the newly opened one.

Makes things a bit more complicated than the simple bdrv_reopen I had in
mind before, but it allows VMDK to get an all-or-nothing semantics.

Kevin