On Mon, Apr 09, 2012 at 21:52:14 -0600, Eric Blake wrote:
> This patch introduces a new block job, useful for live storage
> migration using pre-copy streaming.
>
> Using a live VM with the backing chain:
> base <- snap1 <- snap2
> as the starting point, we have:
>
> - virDomainBlockRebase(dom, disk, "/path/to/copy", 0,
> VIR_DOMAIN_BLOCK_REBASE_COPY)
> creates /path/to/copy with the same format as snap2, with no backing
> file, so entire chain is copied and flattened
>
> - virDomainBlockRebase(dom, disk, "/path/to/copy", 0,
> VIR_DOMAIN_BLOCK_REBASE_COPY|VIR_DOMAIN_BLOCK_REBASE_COPY_RAW)
> creates /path/to/copy as a raw file, so entire chain is copied and
> flattened
>
> - virDomainBlockRebase(dom, disk, "/path/to/copy", 0,
> VIR_DOMAIN_BLOCK_REBASE_COPY|VIR_DOMAIN_BLOCK_REBASE_SHALLOW)
> creates /path/to/copy with the same format as snap2, but with snap1 as
> a backing file, so only snap2 is copied.
In other words, this doesn't do any rebase at all, it just copies snap2 into
copy and the result is the following chain:
base <- snap1 <- copy
Did I get it right?
> - virDomainBlockRebase(dom, disk, "/path/to/copy", 0,
> VIR_DOMAIN_BLOCK_REBASE_COPY|VIR_DOMAIN_BLOCK_REBASE_REUSE_EXT)
> reuse existing /path/to/copy (must have empty contents, and format is
> probed from the metadata), and copy the full chain
Hmm, in the past we tried to avoid format probing for security reasons.
Shouldn't we avoid introducing new code that needs format probing? However,
I'm not sure that's doable at all in this case.
> - virDomainBlockRebase(dom, disk, "/path/to/copy", 0,
> VIR_DOMAIN_BLOCK_REBASE_COPY|VIR_DOMAIN_BLOCK_REBASE_REUSE_EXT|
> VIR_DOMAIN_BLOCK_REBASE_SHALLOW)
> reuse existing /path/to/copy (contents must be identical to snap1,
> and format is probed from the metadata), and copy only the contents
> of snap2
>
> - virDomainBlockRebase(dom, disk, "/path/to/copy", 0,
> VIR_DOMAIN_BLOCK_REBASE_COPY|VIR_DOMAIN_BLOCK_REBASE_REUSE_EXT|
> VIR_DOMAIN_BLOCK_REBASE_SHALLOW|VIR_DOMAIN_BLOCK_REBASE_COPY_RAW)
> reuse existing /path/to/copy (must be raw volume with contents
> identical to snap1), and copy only the contents of snap2
>
> Less useful combinations:
>
> - virDomainBlockRebase(dom, disk, "/path/to/copy", 0,
> VIR_DOMAIN_BLOCK_REBASE_COPY|VIR_DOMAIN_BLOCK_REBASE_SHALLOW|
> VIR_DOMAIN_BLOCK_REBASE_COPY_RAW)
> fail if source is not raw, otherwise create /path/to/copy as raw and
> the single file is copied (no chain involved)
>
> - virDomainBlockRebase(dom, disk, "/path/to/copy", 0,
> VIR_DOMAIN_BLOCK_REBASE_COPY|VIR_DOMAIN_BLOCK_REBASE_REUSE_EXT|
> VIR_DOMAIN_BLOCK_REBASE_COPY_RAW)
> makes little sense: the destination must be raw but have no contents,
> meaning that it is an empty file, so there is nothing to reuse
>
> The other three flags are rejected without VIR_DOMAIN_BLOCK_COPY.
>
> It would be nice if we could issue an event when pivoting from phase 1
> to phase 2, but qemu hasn't implemented that, and we would have to poll
> in order to synthesize it ourselves. Meanwhile, qemu will give us a
> distinct job info and completion event when we either cancel or pivot
> to end the job. Pivoting is accomplished via the new:
>
> virDomainBlockJobAbort(dom, disk, VIR_DOMAIN_BLOCK_JOB_ABORT_PIVOT)
>
> Management applications can pre-create the copy with a relative
> backing file name, and use the VIR_DOMAIN_BLOCK_REBASE_REUSE_EXT
> flag to have qemu reuse the metadata; if the management application
> also copies the backing files to a new location, this can be used
> to perform live storage migration of an entire backing chain.
This all sounds quite complicated but you explained it well in the
documentation block for virDomainBlockRebase. When reading the above, I
thought an example showing all steps needed to copy a disk image would be
useful but reading virDomainBlockRebase documentation clarified it enough that
I don't think the example is required :-)
This all looks good and I think sticking this functionality into
virDomainBlockRebase makes sense. Since the qemu interface is not set in stone
yet, I won't formally ack any of these block copy patches :-)
Jirka
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list