Date: Tue, 6 Oct 2020 11:10:01 +0200 From: Kashyap Chamarthy To: qemu-devel@nongnu.org, qemu-block@nongnu.org Cc: berto@igalia.com, eblake@redhat.com Subject: Plans to bring QMP 'x-blockdev-reopen' out of experimental? Message-ID: <20201006091001.GA64583@paraplu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Hi, folks If this was already discussed on the list, please point me to the thread. I took a quick look at my local archives, I didn't find any, besides patches to tests. I learn that `x-blockdev-reopen` enables a couple of interesting use cases: (#) Allowing one to live-change the backing file to point to a different location, with the target having content identical to original. This one I was already familiar with. (#) Yesterday I learnt another use case from Peter Krempa and Eric Blake. Allow me to quote (paraphrasing) Eric's example from IRC. E.g. we have (where 'overlay1' has a bitmap): base <- overlay1 Then create a temporary snapshot (which results a bitmap being created in 'overlay2', because 'overlay1' had one): base <- overlay1 <- overlay2 If you want to do a `block-commit` to merge 'overlay2' back into 'overlay1', currently upstream QEMU does not merge the bitmap states from 'overlay2' back into 'overlay1' properly. This current limitation is because QEMU can't merge the bitmaps unless it can reopen 'overlay1' [for read-write] _prior_ to doing the commit — but the only way to do that is with `x-blockdev-reopen`. - - - >From an old chat with Berto on #qemu, he was looking for some more robust testing, before lifting it out of experimental mode, as it was a rather complicated command to implement. Currently, I see there are some 'qemu-iotests' that exercise 'x-blockdev-reopen': 155, 165, 245, and 248. What else kind of tests can give more confidence? (I personally don't have an urgent need for this, so I'm not trying to rush anything. :-)) -- /kashyap