| Message ID | cover.1612809837.git.berto@igalia.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Allow changing bs->file on reopen | expand |
08.02.2021 21:44, Alberto Garcia wrote: > Hi, > > this series allows changing bs->file using x-blockdev-reopen. Read > here for more details: > > https://lists.gnu.org/archive/html/qemu-block/2021-01/msg00437.html > > Version 2 of the series introduces a very significant change: > x-blockdev-reopen now receives a list of BlockdevOptions instead of > just one, so it is possible to reopen multiple block devices using a > single transaction. > > This is still an RFC, I haven't updated the documentation and the > structure of the patches will probably change in the future, but I'd > like to know your opinion about the approach. > > These patches apply on top of Vladimir's branch: > > git: https://src.openvz.org/scm/~vsementsov/qemu.git > tag: up-block-topologic-perm-v2 Patchew understands "Based-on: MESSAGE_ID" tag, so, you can add: Based-on: <20201127144522.29991-1-vsementsov@virtuozzo.com> > > Regards, > > Berto > > Alberto Garcia (4): > block: Allow changing bs->file on reopen > iotests: Update 245 to support replacing files with x-blockdev-reopen > block: Support multiple reopening with x-blockdev-reopen > iotests: Test reopening multiple devices at the same time > > qapi/block-core.json | 2 +- > include/block/block.h | 2 + > block.c | 81 +++++++++++++++++++++-- > blockdev.c | 85 +++++++++++++----------- > tests/qemu-iotests/155 | 9 ++- > tests/qemu-iotests/165 | 4 +- > tests/qemu-iotests/245 | 128 ++++++++++++++++++++++++++++++++----- > tests/qemu-iotests/245.out | 4 +- > tests/qemu-iotests/248 | 2 +- > tests/qemu-iotests/248.out | 2 +- > tests/qemu-iotests/298 | 4 +- > 11 files changed, 254 insertions(+), 69 deletions(-) >
Am 08.02.2021 um 19:44 hat Alberto Garcia geschrieben: > Hi, > > this series allows changing bs->file using x-blockdev-reopen. Read > here for more details: > > https://lists.gnu.org/archive/html/qemu-block/2021-01/msg00437.html > > Version 2 of the series introduces a very significant change: > x-blockdev-reopen now receives a list of BlockdevOptions instead of > just one, so it is possible to reopen multiple block devices using a > single transaction. Adding Peter to Cc for this one. > This is still an RFC, I haven't updated the documentation and the > structure of the patches will probably change in the future, but I'd > like to know your opinion about the approach. I like the direction where this is going. You have a test case for adding a throttling filter. Can we also remove it again or is there still a problem with that? I seem to remember that that was a bit trickier, though I'm not sure what it was. Was it that we can't have the throttle node without a file, so it would possibly still have permission conflicts? Kevin
On Wed, Feb 10, 2021 at 18:26:57 +0100, Kevin Wolf wrote: > Am 08.02.2021 um 19:44 hat Alberto Garcia geschrieben: > > Hi, > > > > this series allows changing bs->file using x-blockdev-reopen. Read > > here for more details: > > > > https://lists.gnu.org/archive/html/qemu-block/2021-01/msg00437.html > > > > Version 2 of the series introduces a very significant change: > > x-blockdev-reopen now receives a list of BlockdevOptions instead of > > just one, so it is possible to reopen multiple block devices using a > > single transaction. > > Adding Peter to Cc for this one. For now I've only used blockdev-reopen for turning backing files read-write and back for bitmap manipulation. In such case I presume it doesn't really make sense to use the batching if I ever need to reopen multiple images. Other than that, the blockdev-reopen code is still dormant in libvirt so it's easy to add the extra required wrapping without any problem.
On Wed 10 Feb 2021 06:26:57 PM CET, Kevin Wolf wrote: > You have a test case for adding a throttling filter. Can we also > remove it again or is there still a problem with that? I seem to > remember that that was a bit trickier, though I'm not sure what it > was. Was it that we can't have the throttle node without a file, so it > would possibly still have permission conflicts? There is no problem with removing the filter anymore. See here for a description of the original problem: https://lists.gnu.org/archive/html/qemu-block/2020-12/msg00090.html But this series is based on Vladimir's branch ("update graph permissions update") which reworks how the permissions are calculated on reopen and solves the issue. Berto
Am 16.02.2021 um 17:36 hat Alberto Garcia geschrieben: > On Wed 10 Feb 2021 06:26:57 PM CET, Kevin Wolf wrote: > > > You have a test case for adding a throttling filter. Can we also > > remove it again or is there still a problem with that? I seem to > > remember that that was a bit trickier, though I'm not sure what it > > was. Was it that we can't have the throttle node without a file, so it > > would possibly still have permission conflicts? > > There is no problem with removing the filter anymore. See here for a > description of the original problem: > > https://lists.gnu.org/archive/html/qemu-block/2020-12/msg00090.html Ah, nice. Can we just add removing the filter again to the test then? > But this series is based on Vladimir's branch ("update graph permissions > update") which reworks how the permissions are calculated on reopen and > solves the issue. Yes, I'm aware of this. I still hope we can get a stable blockdev-reopen for 6.0. Kevin
On Tue 16 Feb 2021 05:48:07 PM CET, Kevin Wolf wrote: >> There is no problem with removing the filter anymore. See here for a >> description of the original problem: >> >> https://lists.gnu.org/archive/html/qemu-block/2020-12/msg00090.html > > Ah, nice. Can we just add removing the filter again to the test then? That is already in this series, see patch #2. Berto
Am 16.02.2021 um 18:25 hat Alberto Garcia geschrieben: > On Tue 16 Feb 2021 05:48:07 PM CET, Kevin Wolf wrote: > > >> There is no problem with removing the filter anymore. See here for a > >> description of the original problem: > >> > >> https://lists.gnu.org/archive/html/qemu-block/2020-12/msg00090.html > > > > Ah, nice. Can we just add removing the filter again to the test then? > > That is already in this series, see patch #2. Oh, indeed. I missed the second reopen, probably expected the code to be longer than that. :-) Kevin