[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
x-blockdev-reopen & block-dirty-bitmaps
From: |
John Snow |
Subject: |
x-blockdev-reopen & block-dirty-bitmaps |
Date: |
Fri, 14 Feb 2020 13:54:36 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 |
Hi, what work remains to make this a stable interface, is it known?
We're having a problem with bitmaps where in some cases libvirt wants to
commit an image back down to a base image but -- for various reasons --
the bitmap was left enabled in the backing image, so it would accrue new
writes during the commit.
Normally, when creating a snapshot using blockdev-snapshot, the backing
file becomes RO and all of the bitmaps become RO too.
The goal is to be able to disable (or enable) bitmaps from a backing
file before (or atomically just before) a commit operation to allow
libvirt greater control on snapshot commit.
Now, in my own testing, we can reopen a backing file just fine, delete
or disable a bitmap and be done with it -- but the interface isn't
stable, so libvirt will be reluctant to use such tricks.
Probably a loaded question, but:
- What's needed to make the interface stable?
- Are there known problem points?
- Any suggestions for workarounds in the meantime?
I'm wary of workarounds, because I'd rather do it the right way.
That said, here's an absolutely awful workaround I thought of that I
think everyone will hate:
- Allow bitmap commands like "enable" and "disable" to be "queued" when
applied to readonly bitmaps ...
- On reopen, apply queued bitmap commands.
Eh, this is bad because it's basically creating a command that we will
immediately deprecate as soon as x-blockdev-reopen is formalized.
All ears for better solutions, though.
--js
- x-blockdev-reopen & block-dirty-bitmaps,
John Snow <=
- Re: x-blockdev-reopen & block-dirty-bitmaps, Kevin Wolf, 2020/02/14
- Re: x-blockdev-reopen & block-dirty-bitmaps, John Snow, 2020/02/14
- Re: x-blockdev-reopen & block-dirty-bitmaps, Kevin Wolf, 2020/02/17
- Re: x-blockdev-reopen & block-dirty-bitmaps, John Snow, 2020/02/17
- Re: x-blockdev-reopen & block-dirty-bitmaps, Peter Krempa, 2020/02/18
- Re: x-blockdev-reopen & block-dirty-bitmaps, Kevin Wolf, 2020/02/18
- Re: x-blockdev-reopen & block-dirty-bitmaps, Peter Krempa, 2020/02/18
- Re: x-blockdev-reopen & block-dirty-bitmaps, Kevin Wolf, 2020/02/18
Re: x-blockdev-reopen & block-dirty-bitmaps, Alberto Garcia, 2020/02/17