This test case adds an NBD server export and then invokes
blockdev-snapshot-sync, which changes the BlockDriverState node that the
NBD server's BlockBackend points to. This is an interesting scenario to
test and exercises the code path fixed by the previous commit.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
---
tests/qemu-iotests/208 | 55 ++++++++++++++++++++++++++++++++++++++++++++++
tests/qemu-iotests/208.out | 9 ++++++++
tests/qemu-iotests/group | 1 +
3 files changed, 65 insertions(+)
create mode 100755 tests/qemu-iotests/208
create mode 100644 tests/qemu-iotests/208.out
diff --git a/tests/qemu-iotests/208 b/tests/qemu-iotests/208
new file mode 100755
index 0000000000..4e82b96c82
--- /dev/null
+++ b/tests/qemu-iotests/208
@@ -0,0 +1,55 @@
+#!/usr/bin/env python
+#
+# Copyright (C) 2018 Red Hat, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <http://www.gnu.org/licenses/>.
+#
+# Creator/Owner: Stefan Hajnoczi <stefanha@redhat.com>
+#
+# Check that the runtime NBD server does not crash when stopped after
+# blockdev-snapshot-sync.
+
+import iotests
+
+with iotests.FilePath('disk.img') as disk_img_path, \
+ iotests.FilePath('disk-snapshot.img') as disk_snapshot_img_path, \
+ iotests.FilePath('nbd.sock') as nbd_sock_path, \
+ iotests.VM() as vm:
+
+ img_size = '10M'
+ iotests.qemu_img_pipe('create', '-f', iotests.imgfmt, disk_img_path, img_size)
+
+ iotests.log('Launching VM...')
+ (vm.add_drive(disk_img_path, 'node-name=drive0-node', interface='none')
+ .launch())
+
+ iotests.log('Starting NBD server...')
+ iotests.log(vm.qmp('nbd-server-start', addr={
+ "type": "unix",
+ "data": {
+ "path": nbd_sock_path,
+ }
+ }))
+
+ iotests.log('Adding NBD export...')
+ iotests.log(vm.qmp('nbd-server-add', device='drive0-node', writable=True))
+
+ iotests.log('Creating external snapshot...')
+ iotests.log(vm.qmp('blockdev-snapshot-sync',
+ node_name='drive0-node',
+ snapshot_node_name='drive0-snapshot-node',
+ snapshot_file=disk_snapshot_img_path))
+
+ iotests.log('Stopping NBD server...')
+ iotests.log(vm.qmp('nbd-server-stop'))
diff --git a/tests/qemu-iotests/208.out b/tests/qemu-iotests/208.out
new file mode 100644
index 0000000000..3687e9d0dd
--- /dev/null
+++ b/tests/qemu-iotests/208.out
@@ -0,0 +1,9 @@
+Launching VM...
+Starting NBD server...
+{u'return': {}}
+Adding NBD export...
+{u'return': {}}
+Creating external snapshot...
+{u'return': {}}
+Stopping NBD server...
+{u'return': {}}
diff --git a/tests/qemu-iotests/group b/tests/qemu-iotests/group
index a2dfe79d86..01c03019dd 100644
--- a/tests/qemu-iotests/group
+++ b/tests/qemu-iotests/group
@@ -202,3 +202,4 @@
203 rw auto
204 rw auto quick
205 rw auto quick
+208 rw auto quick
--
2.14.3
I have applied this patch and when I run the following qmp commands I I do
not see the crash anymore but there is still something wrong because only
/root/a is opened from qemu. It looks like nbd-server-stop is also getting
rid of the nodes added with blockdev-snapshot-sync, therfore is than not
possible to do blockdev-del on /root/d because node-name is not found
{ "execute": "qmp_capabilities" }
{
"execute": "blockdev-add",
"arguments": {
"driver": "qcow2",
"node-name": "/root/a",
"discard": "unmap",
"cache": {
"direct": true
},
"file": {
"driver": "file",
"filename": "/root/a"
}
}
}
{
"execute": "nbd-server-start",
"arguments": {
"addr": {
"type": "unix",
"data": {
"path": "/tmp/nbd.test1"
}
}
}
}
{
"execute": "nbd-server-add",
"arguments": {
"device": "/root/a",
"writable": true
}
}
{
"execute": "blockdev-snapshot-sync",
"arguments": {
"node-name": "/root/a",
"snapshot-node-name": "/root/b",
"snapshot-file": "/root/b"
}
}
{
"execute": "blockdev-snapshot-sync",
"arguments": {
"node-name": "/root/b",
"snapshot-node-name": "/root/c",
"snapshot-file": "/root/c"
}
}
{
"execute": "blockdev-snapshot-sync",
"arguments": {
"node-name": "/root/c",
"snapshot-node-name": "/root/d",
"snapshot-file": "/root/d"
}
}
{
"execute": "nbd-server-stop"
}
On Tue, Mar 6, 2018 at 8:48 PM, Stefan Hajnoczi <stefanha@redhat.com> wrote:
>
> This test case adds an NBD server export and then invokes
> blockdev-snapshot-sync, which changes the BlockDriverState node that the
> NBD server's BlockBackend points to. This is an interesting scenario to
> test and exercises the code path fixed by the previous commit.
>
> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> ---
> tests/qemu-iotests/208 | 55
++++++++++++++++++++++++++++++++++++++++++++++
> tests/qemu-iotests/208.out | 9 ++++++++
> tests/qemu-iotests/group | 1 +
> 3 files changed, 65 insertions(+)
> create mode 100755 tests/qemu-iotests/208
> create mode 100644 tests/qemu-iotests/208.out
>
> diff --git a/tests/qemu-iotests/208 b/tests/qemu-iotests/208
> new file mode 100755
> index 0000000000..4e82b96c82
> --- /dev/null
> +++ b/tests/qemu-iotests/208
> @@ -0,0 +1,55 @@
> +#!/usr/bin/env python
> +#
> +# Copyright (C) 2018 Red Hat, Inc.
> +#
> +# This program is free software; you can redistribute it and/or modify
> +# it under the terms of the GNU General Public License as published by
> +# the Free Software Foundation; either version 2 of the License, or
> +# (at your option) any later version.
> +#
> +# This program is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License
> +# along with this program. If not, see <http://www.gnu.org/licenses/>.
> +#
> +# Creator/Owner: Stefan Hajnoczi <stefanha@redhat.com>
> +#
> +# Check that the runtime NBD server does not crash when stopped after
> +# blockdev-snapshot-sync.
> +
> +import iotests
> +
> +with iotests.FilePath('disk.img') as disk_img_path, \
> + iotests.FilePath('disk-snapshot.img') as disk_snapshot_img_path, \
> + iotests.FilePath('nbd.sock') as nbd_sock_path, \
> + iotests.VM() as vm:
> +
> + img_size = '10M'
> + iotests.qemu_img_pipe('create', '-f', iotests.imgfmt, disk_img_path,
img_size)
> +
> + iotests.log('Launching VM...')
> + (vm.add_drive(disk_img_path, 'node-name=drive0-node',
interface='none')
> + .launch())
> +
> + iotests.log('Starting NBD server...')
> + iotests.log(vm.qmp('nbd-server-start', addr={
> + "type": "unix",
> + "data": {
> + "path": nbd_sock_path,
> + }
> + }))
> +
> + iotests.log('Adding NBD export...')
> + iotests.log(vm.qmp('nbd-server-add', device='drive0-node',
writable=True))
> +
> + iotests.log('Creating external snapshot...')
> + iotests.log(vm.qmp('blockdev-snapshot-sync',
> + node_name='drive0-node',
> + snapshot_node_name='drive0-snapshot-node',
> + snapshot_file=disk_snapshot_img_path))
> +
> + iotests.log('Stopping NBD server...')
> + iotests.log(vm.qmp('nbd-server-stop'))
> diff --git a/tests/qemu-iotests/208.out b/tests/qemu-iotests/208.out
> new file mode 100644
> index 0000000000..3687e9d0dd
> --- /dev/null
> +++ b/tests/qemu-iotests/208.out
> @@ -0,0 +1,9 @@
> +Launching VM...
> +Starting NBD server...
> +{u'return': {}}
> +Adding NBD export...
> +{u'return': {}}
> +Creating external snapshot...
> +{u'return': {}}
> +Stopping NBD server...
> +{u'return': {}}
> diff --git a/tests/qemu-iotests/group b/tests/qemu-iotests/group
> index a2dfe79d86..01c03019dd 100644
> --- a/tests/qemu-iotests/group
> +++ b/tests/qemu-iotests/group
> @@ -202,3 +202,4 @@
> 203 rw auto
> 204 rw auto quick
> 205 rw auto quick
> +208 rw auto quick
> --
> 2.14.3
>
On Tue, Mar 6, 2018 at 11:25 PM, Stefano Panella <spanella@gmail.com> wrote: > I have applied this patch and when I run the following qmp commands I I do > not see the crash anymore but there is still something wrong because only > /root/a is opened from qemu. It looks like nbd-server-stop is also getting > rid of the nodes added with blockdev-snapshot-sync, therfore is than not > possible to do blockdev-del on /root/d because node-name is not found Nodes are reference counted. If nothing holds a refcount then the node is freed. The blockdev-add command holds a reference to the node. The node will stay alive until blockdev-del, which releases that reference. blockdev-snapshot-sync does not hold a reference. Therefore snapshot nodes are freed once nothing is using them anymore. When the snapshot node is created, the users of the parent node are updated to point to the snapshot node instead. This is why the NBD server switches to the snapshot mode after blockdev-snapshot-sync. This is why the snapshot nodes disappear after the NBD server is stopped while /root/a stays alive. I'm not sure if the current blockdev-snapshot-sync behavior is useful. Perhaps the presence of the "snapshot-node-name" argument should cause the snapshot node to be treated as monitor-owned, just like blockdev-add. This would introduce leaks for existing QMP clients though, so it may be necessary to add yet another argument for this behavior. Anyway, I hope this explains the current behavior. I don't see a problem with it, but it's something the API users need to be aware of. If it is a problem for your use case, please explain what you are trying to do. Stefan
On Wed, Mar 7, 2018 at 10:55 AM, Stefan Hajnoczi <stefanha@gmail.com> wrote: > > On Tue, Mar 6, 2018 at 11:25 PM, Stefano Panella <spanella@gmail.com> wrote: > > I have applied this patch and when I run the following qmp commands I I do > > not see the crash anymore but there is still something wrong because only > > /root/a is opened from qemu. It looks like nbd-server-stop is also getting > > rid of the nodes added with blockdev-snapshot-sync, therfore is than not > > possible to do blockdev-del on /root/d because node-name is not found > > Nodes are reference counted. If nothing holds a refcount then the > node is freed. Thanks, that explains the behaviour > > The blockdev-add command holds a reference to the node. The node will > stay alive until blockdev-del, which releases that reference. > > blockdev-snapshot-sync does not hold a reference. Therefore snapshot > nodes are freed once nothing is using them anymore. When the snapshot > node is created, the users of the parent node are updated to point to > the snapshot node instead. This is why the NBD server switches to the > snapshot mode after blockdev-snapshot-sync. > > This is why the snapshot nodes disappear after the NBD server is > stopped while /root/a stays alive. > > I'm not sure if the current blockdev-snapshot-sync behavior is useful. > Perhaps the presence of the "snapshot-node-name" argument should cause > the snapshot node to be treated as monitor-owned, just like > blockdev-add. This would introduce leaks for existing QMP clients > though, so it may be necessary to add yet another argument for this > behavior. that would be nice, I mean to add an extra parameter so it is added to the monitor > > Anyway, I hope this explains the current behavior. I don't see a > problem with it, but it's something the API users need to be aware of. > Yes, I was not aware of that behaviour, the problem is that many examples refer to having a device associated with the blockdev-add'd node therefore we do not see this problem. > If it is a problem for your use case, please explain what you are trying to do. > It is not strictly a problem for my usecase but it would be nice to have the extra param to blockdev-snapshot-sync. That would also fix the problem of running multiple snap-sync after blockdev-add but before there is any user. > Stefan
On Wed, Mar 7, 2018 at 1:57 PM, Stefano Panella <spanella@gmail.com> wrote: > On Wed, Mar 7, 2018 at 10:55 AM, Stefan Hajnoczi <stefanha@gmail.com> wrote: >> >> On Tue, Mar 6, 2018 at 11:25 PM, Stefano Panella <spanella@gmail.com> >> wrote: >> > I have applied this patch and when I run the following qmp commands I I >> > do >> > not see the crash anymore but there is still something wrong because >> > only >> > /root/a is opened from qemu. It looks like nbd-server-stop is also >> > getting >> > rid of the nodes added with blockdev-snapshot-sync, therfore is than not >> > possible to do blockdev-del on /root/d because node-name is not found >> >> Nodes are reference counted. If nothing holds a refcount then the >> node is freed. > Thanks, that explains the behaviour >> >> The blockdev-add command holds a reference to the node. The node will >> stay alive until blockdev-del, which releases that reference. >> >> blockdev-snapshot-sync does not hold a reference. Therefore snapshot >> nodes are freed once nothing is using them anymore. When the snapshot >> node is created, the users of the parent node are updated to point to >> the snapshot node instead. This is why the NBD server switches to the >> snapshot mode after blockdev-snapshot-sync. >> >> This is why the snapshot nodes disappear after the NBD server is >> stopped while /root/a stays alive. >> >> I'm not sure if the current blockdev-snapshot-sync behavior is useful. >> Perhaps the presence of the "snapshot-node-name" argument should cause >> the snapshot node to be treated as monitor-owned, just like >> blockdev-add. This would introduce leaks for existing QMP clients >> though, so it may be necessary to add yet another argument for this >> behavior. > that would be nice, I mean to add an extra parameter so it is added to the > monitor >> >> Anyway, I hope this explains the current behavior. I don't see a >> problem with it, but it's something the API users need to be aware of. >> > Yes, I was not aware of that behaviour, the problem is that many examples > refer > to having a device associated with the blockdev-add'd node therefore we do > not > see this problem. >> If it is a problem for your use case, please explain what you are trying >> to do. >> > It is not strictly a problem for my usecase but it would be nice to have the > extra param to > blockdev-snapshot-sync. That would also fix the problem of running multiple > snap-sync > after blockdev-add but before there is any user. Max Reitz mentioned that the 'blockdev-snapshot' command is preferred over 'blockdev-snapshot-sync'. 'blockdev-snapshot-sync' is a legacy command that implicitly creates the snapshot node. The difference is that 'blockdev-snapshot' requires that the user first creates the snapshot file (e.g. using qemu-img create), then uses 'blockdev-add' to add the snapshot node, and finally uses 'blockdev-snapshot' to install the snapshot node. When 'blockdev-snapshot' is used, the user must delete snapshot nodes using 'blockdev-del' since they created using 'blockdev-add'. Stefan
On Wed, Mar 7, 2018 at 4:16 PM, Stefan Hajnoczi <stefanha@gmail.com> wrote: > > On Wed, Mar 7, 2018 at 1:57 PM, Stefano Panella <spanella@gmail.com> wrote: > > On Wed, Mar 7, 2018 at 10:55 AM, Stefan Hajnoczi <stefanha@gmail.com> wrote: > >> > >> On Tue, Mar 6, 2018 at 11:25 PM, Stefano Panella <spanella@gmail.com> > >> wrote: > >> > I have applied this patch and when I run the following qmp commands I I > >> > do > >> > not see the crash anymore but there is still something wrong because > >> > only > >> > /root/a is opened from qemu. It looks like nbd-server-stop is also > >> > getting > >> > rid of the nodes added with blockdev-snapshot-sync, therfore is than not > >> > possible to do blockdev-del on /root/d because node-name is not found > >> > >> Nodes are reference counted. If nothing holds a refcount then the > >> node is freed. > > Thanks, that explains the behaviour > >> > >> The blockdev-add command holds a reference to the node. The node will > >> stay alive until blockdev-del, which releases that reference. > >> > >> blockdev-snapshot-sync does not hold a reference. Therefore snapshot > >> nodes are freed once nothing is using them anymore. When the snapshot > >> node is created, the users of the parent node are updated to point to > >> the snapshot node instead. This is why the NBD server switches to the > >> snapshot mode after blockdev-snapshot-sync. > >> > >> This is why the snapshot nodes disappear after the NBD server is > >> stopped while /root/a stays alive. > >> > >> I'm not sure if the current blockdev-snapshot-sync behavior is useful. > >> Perhaps the presence of the "snapshot-node-name" argument should cause > >> the snapshot node to be treated as monitor-owned, just like > >> blockdev-add. This would introduce leaks for existing QMP clients > >> though, so it may be necessary to add yet another argument for this > >> behavior. > > that would be nice, I mean to add an extra parameter so it is added to the > > monitor > >> > >> Anyway, I hope this explains the current behavior. I don't see a > >> problem with it, but it's something the API users need to be aware of. > >> > > Yes, I was not aware of that behaviour, the problem is that many examples > > refer > > to having a device associated with the blockdev-add'd node therefore we do > > not > > see this problem. > >> If it is a problem for your use case, please explain what you are trying > >> to do. > >> > > It is not strictly a problem for my usecase but it would be nice to have the > > extra param to > > blockdev-snapshot-sync. That would also fix the problem of running multiple > > snap-sync > > after blockdev-add but before there is any user. > > Max Reitz mentioned that the 'blockdev-snapshot' command is preferred > over 'blockdev-snapshot-sync'. 'blockdev-snapshot-sync' is a legacy > command that implicitly creates the snapshot node. > > The difference is that 'blockdev-snapshot' requires that the user > first creates the snapshot file (e.g. using qemu-img create), then > uses 'blockdev-add' to add the snapshot node, and finally uses > 'blockdev-snapshot' to install the snapshot node. > > When 'blockdev-snapshot' is used, the user must delete snapshot nodes > using 'blockdev-del' since they created using 'blockdev-add'. > That is a very usefull info, I was not aware that blockdev-snapshot-sync was not recommended. I will try to run some examples with blockdev-snapshot. In case I want to achieve A <- B and I do: blockdev_add A create external snapshot with qemu-img B with A as backing image blockdev_add B blockdev_snapshot B -> A What do I need to do to delete A and B? is it fine to just call blockdev_del B ? or should I call blockdev_del A as well? Thanks again for your help!!! > Stefan
On 2018-03-07 17:43, Stefano Panella wrote: > > > On Wed, Mar 7, 2018 at 4:16 PM, Stefan Hajnoczi <stefanha@gmail.com > <mailto:stefanha@gmail.com>> wrote: >> >> On Wed, Mar 7, 2018 at 1:57 PM, Stefano Panella <spanella@gmail.com > <mailto:spanella@gmail.com>> wrote: >> > On Wed, Mar 7, 2018 at 10:55 AM, Stefan Hajnoczi <stefanha@gmail.com > <mailto:stefanha@gmail.com>> wrote: >> >> >> >> On Tue, Mar 6, 2018 at 11:25 PM, Stefano Panella > <spanella@gmail.com <mailto:spanella@gmail.com>> >> >> wrote: >> >> > I have applied this patch and when I run the following qmp > commands I I >> >> > do >> >> > not see the crash anymore but there is still something wrong because >> >> > only >> >> > /root/a is opened from qemu. It looks like nbd-server-stop is also >> >> > getting >> >> > rid of the nodes added with blockdev-snapshot-sync, therfore is > than not >> >> > possible to do blockdev-del on /root/d because node-name is not found >> >> >> >> Nodes are reference counted. If nothing holds a refcount then the >> >> node is freed. >> > Thanks, that explains the behaviour >> >> >> >> The blockdev-add command holds a reference to the node. The node will >> >> stay alive until blockdev-del, which releases that reference. >> >> >> >> blockdev-snapshot-sync does not hold a reference. Therefore snapshot >> >> nodes are freed once nothing is using them anymore. When the snapshot >> >> node is created, the users of the parent node are updated to point to >> >> the snapshot node instead. This is why the NBD server switches to the >> >> snapshot mode after blockdev-snapshot-sync. >> >> >> >> This is why the snapshot nodes disappear after the NBD server is >> >> stopped while /root/a stays alive. >> >> >> >> I'm not sure if the current blockdev-snapshot-sync behavior is useful. >> >> Perhaps the presence of the "snapshot-node-name" argument should cause >> >> the snapshot node to be treated as monitor-owned, just like >> >> blockdev-add. This would introduce leaks for existing QMP clients >> >> though, so it may be necessary to add yet another argument for this >> >> behavior. >> > that would be nice, I mean to add an extra parameter so it is added > to the >> > monitor >> >> >> >> Anyway, I hope this explains the current behavior. I don't see a >> >> problem with it, but it's something the API users need to be aware of. >> >> >> > Yes, I was not aware of that behaviour, the problem is that many > examples >> > refer >> > to having a device associated with the blockdev-add'd node therefore > we do >> > not >> > see this problem. >> >> If it is a problem for your use case, please explain what you are > trying >> >> to do. >> >> >> > It is not strictly a problem for my usecase but it would be nice to > have the >> > extra param to >> > blockdev-snapshot-sync. That would also fix the problem of running > multiple >> > snap-sync >> > after blockdev-add but before there is any user. >> >> Max Reitz mentioned that the 'blockdev-snapshot' command is preferred >> over 'blockdev-snapshot-sync'. 'blockdev-snapshot-sync' is a legacy >> command that implicitly creates the snapshot node. >> >> The difference is that 'blockdev-snapshot' requires that the user >> first creates the snapshot file (e.g. using qemu-img create), then >> uses 'blockdev-add' to add the snapshot node, and finally uses >> 'blockdev-snapshot' to install the snapshot node. >> >> When 'blockdev-snapshot' is used, the user must delete snapshot nodes >> using 'blockdev-del' since they created using 'blockdev-add'. >> > That is a very usefull info, I was not aware that blockdev-snapshot-sync > was not > recommended. Yeah, well... Someone (O:-)) needs to go over all the block QMP commands and see which are good and which should be deprecated at some point. I don't think we have a central list of everything yet... > I will try to run some examples with blockdev-snapshot. > In case I want to achieve > A <- B > and I do: > blockdev_add A > create external snapshot with qemu-img B with A as backing image > blockdev_add B > blockdev_snapshot B -> A > > What do I need to do to delete A and B? > is it fine to just call blockdev_del B ? > or should I call blockdev_del A as well? You need to call both. The basic idea is that you have to pair every blockdev-add with a blockdev-del. (You have to delete B first, though, because you cannot delete a node while it is in use (and A is in use by B as long as B exists).) Don't forget the '"backing": null" parameter for the blockdev-add B command, or B will already have A opened as its backing image (which is not good, you don't want qemu to open the same image twice). (Or maybe blockdev-add B will not even work without '"backing": null' because qemu figures out that you are trying to open the same image (A) twice and prevent that.) Max
On 2018-03-07 11:55, Stefan Hajnoczi wrote: > On Tue, Mar 6, 2018 at 11:25 PM, Stefano Panella <spanella@gmail.com> wrote: >> I have applied this patch and when I run the following qmp commands I I do >> not see the crash anymore but there is still something wrong because only >> /root/a is opened from qemu. It looks like nbd-server-stop is also getting >> rid of the nodes added with blockdev-snapshot-sync, therfore is than not >> possible to do blockdev-del on /root/d because node-name is not found > > Nodes are reference counted. If nothing holds a refcount then the > node is freed. > > The blockdev-add command holds a reference to the node. The node will > stay alive until blockdev-del, which releases that reference. > > blockdev-snapshot-sync does not hold a reference. I think that's a bug. When you specify a node name for the new node, it should get a reference. > Therefore snapshot > nodes are freed once nothing is using them anymore. When the snapshot > node is created, the users of the parent node are updated to point to > the snapshot node instead. This is why the NBD server switches to the > snapshot mode after blockdev-snapshot-sync. > > This is why the snapshot nodes disappear after the NBD server is > stopped while /root/a stays alive. > > I'm not sure if the current blockdev-snapshot-sync behavior is useful. > Perhaps the presence of the "snapshot-node-name" argument should cause > the snapshot node to be treated as monitor-owned, just like > blockdev-add. This would introduce leaks for existing QMP clients > though, so it may be necessary to add yet another argument for this > behavior. That's true. > Anyway, I hope this explains the current behavior. I don't see a > problem with it, but it's something the API users need to be aware of. Hm, OK. As an explanation: blockdev-snapshot-sync is from before we had node names and blockdev-add. You'd just create something that needs the block layer (like a guest device or an NBD server) and then you'd open the BDS chain you want to go with it (mostly by just specifying the filename of the top image, and maybe its format). Then you'd use blockdev-snapshot-sync to just create an overlay during runtime, and since there weren't any node names it was clear that it would go away if you deleted whatever was using the chain (like the NBD server). Then we introduced node names, and blockdev-snapshot-sync gained the ability to give one to the overlay -- basically as an afterthought. I think we didn't really have a fleshed-out concept of monitor references back then... So we forgot to give the overlay an additional reference in such a case (because we didn't know better). As you pointed to in your other reply, blockdev-snapshot is the "pure" blockdev command that should ideally be used. It allows you much more control over the overlay (because you have to do the blockdev-add yourself), and it doesn't have this reference issue. Max
On 03/06/2018 02:48 PM, Stefan Hajnoczi wrote: > This test case adds an NBD server export and then invokes > blockdev-snapshot-sync, which changes the BlockDriverState node that the Do we want to test 'blockdev-snapshot' instead (or in addition), given the subthread discussion about blockdev-snapshot-sync being the older non-preferred form? > NBD server's BlockBackend points to. This is an interesting scenario to > test and exercises the code path fixed by the previous commit. > > Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> > --- > tests/qemu-iotests/208 | 55 ++++++++++++++++++++++++++++++++++++++++++++++ > tests/qemu-iotests/208.out | 9 ++++++++ > tests/qemu-iotests/group | 1 + > 3 files changed, 65 insertions(+) > create mode 100755 tests/qemu-iotests/208 > create mode 100644 tests/qemu-iotests/208.out > Switching the order of the two patches in this series makes it obvious that this patch does tickle the code path in question, so you definitely get: Tested-by: Eric Blake <eblake@redhat.com> And unless answering the question about blockdev-snapshot causes you to change things for more/different QMP commands, I'm also fine with: Reviewed-by: Eric Blake <eblake@redhat.com> -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
On 2018-03-06 21:48, Stefan Hajnoczi wrote:
> This test case adds an NBD server export and then invokes
> blockdev-snapshot-sync, which changes the BlockDriverState node that the
> NBD server's BlockBackend points to. This is an interesting scenario to
> test and exercises the code path fixed by the previous commit.
>
> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> ---
> tests/qemu-iotests/208 | 55 ++++++++++++++++++++++++++++++++++++++++++++++
> tests/qemu-iotests/208.out | 9 ++++++++
> tests/qemu-iotests/group | 1 +
> 3 files changed, 65 insertions(+)
> create mode 100755 tests/qemu-iotests/208
> create mode 100644 tests/qemu-iotests/208.out
>
> diff --git a/tests/qemu-iotests/208 b/tests/qemu-iotests/208
> new file mode 100755
> index 0000000000..4e82b96c82
> --- /dev/null
> +++ b/tests/qemu-iotests/208
> @@ -0,0 +1,55 @@
> +#!/usr/bin/env python
> +#
> +# Copyright (C) 2018 Red Hat, Inc.
> +#
> +# This program is free software; you can redistribute it and/or modify
> +# it under the terms of the GNU General Public License as published by
> +# the Free Software Foundation; either version 2 of the License, or
> +# (at your option) any later version.
> +#
> +# This program is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License
> +# along with this program. If not, see <http://www.gnu.org/licenses/>.
> +#
> +# Creator/Owner: Stefan Hajnoczi <stefanha@redhat.com>
> +#
> +# Check that the runtime NBD server does not crash when stopped after
> +# blockdev-snapshot-sync.
> +
> +import iotests
> +
> +with iotests.FilePath('disk.img') as disk_img_path, \
> + iotests.FilePath('disk-snapshot.img') as disk_snapshot_img_path, \
> + iotests.FilePath('nbd.sock') as nbd_sock_path, \
> + iotests.VM() as vm:
> +
> + img_size = '10M'
> + iotests.qemu_img_pipe('create', '-f', iotests.imgfmt, disk_img_path, img_size)
> +
> + iotests.log('Launching VM...')
> + (vm.add_drive(disk_img_path, 'node-name=drive0-node', interface='none')
> + .launch())
> +
> + iotests.log('Starting NBD server...')
> + iotests.log(vm.qmp('nbd-server-start', addr={
> + "type": "unix",
> + "data": {
> + "path": nbd_sock_path,
> + }
> + }))
> +
> + iotests.log('Adding NBD export...')
> + iotests.log(vm.qmp('nbd-server-add', device='drive0-node', writable=True))
> +
> + iotests.log('Creating external snapshot...')
> + iotests.log(vm.qmp('blockdev-snapshot-sync',
> + node_name='drive0-node',
> + snapshot_node_name='drive0-snapshot-node',
> + snapshot_file=disk_snapshot_img_path))
> +
> + iotests.log('Stopping NBD server...')
> + iotests.log(vm.qmp('nbd-server-stop'))
Hm. Tests what it's supposed to test.
However, I'm not sure whether that's what we want... If I give a node
name to nbd-server-add, I'd probably expect the NBD server to stay at
that node. We have BdrvChild.stay_at_node for that, so we could
implement it. The question is whether we want to.
However, both wanting the snapshot to be below and above the NBD server
makes sense... Perhaps it's best to leave it as-is, even if it is
surprising to some, because this way we at least don't have to switch to
RO mode (which we probably would if the NBD server is suddenly below the
snapshot).
I'm sure adding atomic graph change operations to QMP will fix all of
that. I'm sure.
Anyway, since your test doesn't even check whether the NBD server is
above or below the snapshot (clever! :-))...
Reviewed-by: Max Reitz <mreitz@redhat.com>
© 2016 - 2025 Red Hat, Inc.