| Message ID | 20191110190310.19799-1-dplotnikov@virtuozzo.com |
|---|---|
| Headers | show |
| Series | allow to set 'drive' property on a realized block device | expand |
Ping! On 10.11.2019 22:03, Denis Plotnikov wrote: > This allows to replace the file on a block device and is useful > to workaround the cases (migration) when the VM image is placed on > some shared storage with exclusive file opening model but the image > should be open form more than one app. > > The previous version of approaching the workaround was based on the > "blockdev-change-medium" command modification but had some flaws: > * semantics: blockdev-change-medium is aimed to be used with removable devices > only > * interface: it can't accept all possible combination of parameters for > the "drive" replacement (creation). > > More details here: http://patchwork.ozlabs.org/patch/1179329/ > > The current series suggests another approach: > 1. blockdev-add > 2. qom-set disk.drive = the blockdev added (this is what the series adds) > > > Denis Plotnikov (2): > qdev-properties-system: extend set_pionter for unrealized devices > block: allow to set 'drive' property on a realized block device > > hw/core/qdev-properties-system.c | 117 +++++++++++++++++++++++++------ > 1 file changed, 96 insertions(+), 21 deletions(-) >
Am 10.11.2019 um 20:03 hat Denis Plotnikov geschrieben: > This allows to replace the file on a block device and is useful > to workaround the cases (migration) when the VM image is placed on > some shared storage with exclusive file opening model but the image > should be open form more than one app. > > The previous version of approaching the workaround was based on the > "blockdev-change-medium" command modification but had some flaws: > * semantics: blockdev-change-medium is aimed to be used with removable devices > only > * interface: it can't accept all possible combination of parameters for > the "drive" replacement (creation). > > More details here: http://patchwork.ozlabs.org/patch/1179329/ > > The current series suggests another approach: > 1. blockdev-add > 2. qom-set disk.drive = the blockdev added (this is what the series adds) Are you still planning to send another version? Kevin
On 02.03.2020 16:38, Kevin Wolf wrote: > Am 10.11.2019 um 20:03 hat Denis Plotnikov geschrieben: >> This allows to replace the file on a block device and is useful >> to workaround the cases (migration) when the VM image is placed on >> some shared storage with exclusive file opening model but the image >> should be open form more than one app. >> >> The previous version of approaching the workaround was based on the >> "blockdev-change-medium" command modification but had some flaws: >> * semantics: blockdev-change-medium is aimed to be used with removable devices >> only >> * interface: it can't accept all possible combination of parameters for >> the "drive" replacement (creation). >> >> More details here: http://patchwork.ozlabs.org/patch/1179329/ >> >> The current series suggests another approach: >> 1. blockdev-add >> 2. qom-set disk.drive = the blockdev added (this is what the series adds) > Are you still planning to send another version? > > Kevin Not in the near future :) There is an unresolved problem with bitmap-migration is case of block dev replacement. Still don't know how to do it in the proper way. Denis >
Am 02.03.2020 um 14:55 hat Denis Plotnikov geschrieben: > > > On 02.03.2020 16:38, Kevin Wolf wrote: > > Am 10.11.2019 um 20:03 hat Denis Plotnikov geschrieben: > > > This allows to replace the file on a block device and is useful > > > to workaround the cases (migration) when the VM image is placed on > > > some shared storage with exclusive file opening model but the image > > > should be open form more than one app. > > > > > > The previous version of approaching the workaround was based on the > > > "blockdev-change-medium" command modification but had some flaws: > > > * semantics: blockdev-change-medium is aimed to be used with removable devices > > > only > > > * interface: it can't accept all possible combination of parameters for > > > the "drive" replacement (creation). > > > > > > More details here: http://patchwork.ozlabs.org/patch/1179329/ > > > > > > The current series suggests another approach: > > > 1. blockdev-add > > > 2. qom-set disk.drive = the blockdev added (this is what the series adds) > > Are you still planning to send another version? > > > > Kevin > Not in the near future :) There is an unresolved problem with > bitmap-migration is case of block dev replacement. > Still don't know how to do it in the proper way. I seem to remember that in some discussion a while ago we came to the conclusion that we need a way for the managemnt tool to provide a mapping from source node-names to destination node-names. Or is the problem you mean unrelated to identifying the node to which a bitmap should belong? Kevin
02.03.2020 18:39, Kevin Wolf wrote: > Am 02.03.2020 um 14:55 hat Denis Plotnikov geschrieben: >> >> >> On 02.03.2020 16:38, Kevin Wolf wrote: >>> Am 10.11.2019 um 20:03 hat Denis Plotnikov geschrieben: >>>> This allows to replace the file on a block device and is useful >>>> to workaround the cases (migration) when the VM image is placed on >>>> some shared storage with exclusive file opening model but the image >>>> should be open form more than one app. >>>> >>>> The previous version of approaching the workaround was based on the >>>> "blockdev-change-medium" command modification but had some flaws: >>>> * semantics: blockdev-change-medium is aimed to be used with removable devices >>>> only >>>> * interface: it can't accept all possible combination of parameters for >>>> the "drive" replacement (creation). >>>> >>>> More details here: http://patchwork.ozlabs.org/patch/1179329/ >>>> >>>> The current series suggests another approach: >>>> 1. blockdev-add >>>> 2. qom-set disk.drive = the blockdev added (this is what the series adds) >>> Are you still planning to send another version? >>> >>> Kevin >> Not in the near future :) There is an unresolved problem with >> bitmap-migration is case of block dev replacement. >> Still don't know how to do it in the proper way. > > I seem to remember that in some discussion a while ago we came to the > conclusion that we need a way for the managemnt tool to provide a > mapping from source node-names to destination node-names. Yes, it's planned solution for bitmaps migration, but it doesn't help here. > > Or is the problem you mean unrelated to identifying the node to which a > bitmap should belong? > The problem here is following: We need to workaround migration on shared fs, which doesn't allow to open file on node A if it is opened RW on node B (and visa-versa). So, we tried to start target with null-co stub instead of shared qcow2 and than switch to correct file at some moment. The problem with bitmaps migration is that we migrate bitmaps to null-co and than they are lost... So we need to implement some moving bitmaps from null-co to qcow2 node, keeping in mind that they are in progress of migration. We didn't try to implement such moving, it seemed too tricky. I also had an idea of a flag for file-posix to close fd on inactivation.. But then we need to not open it when openining in inactive mode, and this needs support in qcow2, which doesn't seem better than null-co stub. So, I see two ways of solving this: 1. Use null-co stub and deal with moving bitmaps during postcopy 2. Move to UNOPENED mode for bdrv, which is similar to INACTIVE, but doesn't allow to open any files on fs. We'll have to provide size as an option anyway.. Sounds bad. Could you give an advice?
This allows to replace the file on a block device and is useful to workaround the cases (migration) when the VM image is placed on some shared storage with exclusive file opening model but the image should be open form more than one app. The previous version of approaching the workaround was based on the "blockdev-change-medium" command modification but had some flaws: * semantics: blockdev-change-medium is aimed to be used with removable devices only * interface: it can't accept all possible combination of parameters for the "drive" replacement (creation). More details here: http://patchwork.ozlabs.org/patch/1179329/ The current series suggests another approach: 1. blockdev-add 2. qom-set disk.drive = the blockdev added (this is what the series adds) Denis Plotnikov (2): qdev-properties-system: extend set_pionter for unrealized devices block: allow to set 'drive' property on a realized block device hw/core/qdev-properties-system.c | 117 +++++++++++++++++++++++++------ 1 file changed, 96 insertions(+), 21 deletions(-)