qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/3] qemu: implementation of transient option for qcow2 file


From: Peter Krempa
Subject: Re: [PATCH 1/3] qemu: implementation of transient option for qcow2 file
Date: Tue, 7 Jul 2020 13:48:23 +0200
User-agent: Mutt/1.14.3 (2020-06-14)

On Tue, Jul 07, 2020 at 06:36:23 -0500, Eric Blake wrote:
> On 7/7/20 2:12 AM, Peter Krempa wrote:
> > 
> > 1) the virDomainBlockCopy operation flattens the backing chain into the
> > top level only. This means that <transient/> must be stripped or the
> > operation rejected, as otherwise shutting down the VM would end up
> > removing the disk image completely.
> 
> If you have marked a disk transient, does it still make sense to allow
> copying that disk?  Rejecting the operation is easiest, as permitting it
> implies that even though you already said you don't care about changes to
> your disk, you still want to be able to back up that disk.

Back up? This is more about moving to new storage.

> > 2) the same as above is used also for non-shared-storage migration where
> > we use block-copy internally to transport the disks, same as above
> > applies. Here again it requires careful consideration of the semantics,
> > e.g whether to reject it or e.g. copy it into the original filename and
> > strip <transient/> (we can't currently copy multiple layers).
> 
> The easiest solution is to make a transient disk a migration-blocker. Of
> course, this may annoy people, so migration properly creating a transient
> destination on top of the original base, to preserve the fact that when the
> migrated guest shuts down it reverts to original contents, is a nicer (but
> more complex) goal.

To be fair, our docs already point out that <transient> prevents
migration. It still needs to be implemented.

Same appliest to snapshots.

> > 3) active-layer virDomainBlockCommit moves the data from the transient
> > overlay into the original (now backing image). The <transient> flag is
> > stored in the disk struct though, so that would mean that the original
> > disk source would be removed after stopping the VM. block commit must
> > clear the <transient> flag.
> 
> Why should commit be permitted, when you declared that disk contents
> shouldn't change?  For that matter, external snapshots should be blocked if
> there is a transient disk.

I might have read it in the qemu documentation, but commit is meant to
actually ... commit ... the changes user might want to keep.

I'm okay with forbidding it though in libvirt.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]