[libvirt] [PATCH v2 2/2] qemuProcessStop: Remove image metadata for running mirror jobs

[Peter Krempa]

On Thu, Nov 21, 2019 at 17:00:37 +0100, Michal Privoznik wrote:
> On 11/21/19 3:31 PM, Peter Krempa wrote:
> > On Thu, Nov 21, 2019 at 14:02:49 +0100, Michal Privoznik wrote:
> > > On 11/20/19 3:22 PM, Peter Krempa wrote:
> > > > 
> 
> New commit message:
> 
>     qemuProcessStop: Remove image metadata for running mirror jobs
> 
>     If user starts a blockcommit or a blockcopy then we modify access
>     for qemu on both images and leave it like that until pivot is

until the job terminates

>     executed. So far so good. Problem is, if user instead of issuing
>     pivot (where we would modify the access again so that the state

instead of terminating the job (where ...

>     before the job is restored) calls destroy on the domain or if
>     qemu dies whilst executing the block job. In this case we don't
>     ever clear the access we granted at the beginning. To fix this,
>     maybe a bit harsh approach is used, but it works: after all
>     labels were restored (that is after qemuSecurityRestoreAllLabel()
>     was called), we iterate over each disk in the domain and remove
>     XATTRs from the whole backing chain and also from any file the
>     disk is being mirrored to.
> 
>     This would have been done at the time of pivot, but it isn't
>     because user decided to kill the domain instead. If we don't do
>     this and leave some XATTRs behind the domain might be unable to
>     start.
> 
>     Also, secdriver can't do this because it doesn't know if there is
>     any job running. It's outside of its scope - the hypervisor
>     driver is responsible for calling secdriver's APIs.
> 
>     Moreover, this is safe to call because we don't remember labels
>     for any member of a backing chain instead of the top layer. But

s/instead/except/

>     that one was restored in qemuSecurityRestoreAllLabel() call done
>     earlier. Therefore, not only we don't remember labels (and thus
>     this is basically a NOP for other images in the backing chain) it
>     is also safe to call this when no blockjob was started in the
>     first place, or if some parts of the backing chain are shared
>     with some other domains - this is NOP, unless a block job is
>     active at the time of domain destroy.
> 
>     https://bugzilla.redhat.com/show_bug.cgi?id=1741456#c19
> 
>     Signed-off-by: Michal Privoznik <mprivozn at redhat.com>

Reviewed-by: Peter Krempa <pkrempa at redhat.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20191121/d8be2e97/attachment-0001.sig>