[Qemu-devel] block-layer: questions on manipulation of internal nodes
Hi everybody,
I am a relatively new user of qemu block layer. I am interested in it mainly
because it looks very powerful and general and I am hoping to integrate it on
our product and to contribute to it for new usecases.
I have existing use cases where we work with a model of a disk process per VM
disk and I am experimenting with qemu and qmp to build something similar.
At the moment I have managed to build a new binary, called qemu-dp (probably
should be called qemu-bl for block layer) which is basically starting as a qmp
server and accepting qmp block layer commands to operate on disks.
just to give you an example this is the kind of thing I am doing:
EXTERNALLY:
/usr/lib64/xen/bin/qemu-img create -f qcow2 -o size=1M /root/a
/usr/lib64/xen/bin/qemu-img create -f qcow2 -b /root/a -o size=1M /root/b
/usr/lib64/xen/bin/qemu-img create -f qcow2 -b /root/b -o size=1M /root/c
/usr/lib64/xen/bin/qemu-img create -f qcow2 -b /root/c -o size=1M /root/d
/usr/lib64/xen/bin/qemu-img create -f qcow2 -b /root/d -o size=1M /root/e
let's assume there were some data in every layer
Than:
USING QMP:
{ "execute": "qmp_capabilities" }
{
"execute": "blockdev-add",
"arguments": {
"driver": "qcow2",
"node-name": "qemu_node",
"discard": "unmap",
"cache": {
"direct": true
},
"file": {
"driver": "file",
"filename": "/root/e"
}
}
}
{
"execute": "nbd-server-start",
"arguments": {
"addr": {
"type": "unix",
"data": {
"path": "/tmp/nbd.test1"
}
}
}
}
{
"execute": "nbd-server-add",
"arguments": {
"device": "qemu_node",
"writable": true
}
}
after this the chain looks like:
a < b < c < d < e < NBD_server
now I make a full copy of b and c which I call b1 and c1 and for example I run
externally qemu-img commit c1 -> b1 while qemu-dp has still the chain opened.
I would now like to send a qmp command to tell qemu-dp to hold any IO from the
NBD_server and forget about a, b, c and insert b1 as d's child, like this:
a < b1 < d < e < NBD_server
I have tried to implement this qmp command and looked at
qmp_change_backing_file()
qmp_x_blockdev_change()
https://lists.gnu.org/archive/html/qemu-devel/2017-08/msg02660.html
but did not figure out a way of doing that yet...
I suspect my problem is that I am still very confused about the semantics of
the object model in the block layer, the ref counting, the graph manipulation,
the monitor etc. etc.
I have tried to have some interactive chats on irc and they have been very
useful so far (thanks again stefanha, kwolf, berto, eblake) but maybe a proper
email would be a good starting point as stefanha has suggested.
Please if somebody could point me to a bit of code to achieve my example that
would be great, otherwise if there is no code for that kind of functionality,
it would be good to have a little guide on the sequence of block primiteve I
should call and on which node, including refs, locking, drain, caches, reopen
etc...
Thanks a lot,
Stefano
Re: [Qemu-devel] [Qemu-block] [PATCH 2/2] iotests: add 208 nbd-server + blockdev-snapshot-sync test case
On Wed, Mar 7, 2018 at 4:16 PM, Stefan Hajnoczi <stefa...@gmail.com> wrote: > > On Wed, Mar 7, 2018 at 1:57 PM, Stefano Panella <spane...@gmail.com> wrote: > > On Wed, Mar 7, 2018 at 10:55 AM, Stefan Hajnoczi <stefa...@gmail.com> wrote: > >> > >> On Tue, Mar 6, 2018 at 11:25 PM, Stefano Panella <spane...@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
Re: [Qemu-devel] [Qemu-block] [PATCH 2/2] iotests: add 208 nbd-server + blockdev-snapshot-sync test case
On Wed, Mar 7, 2018 at 10:55 AM, Stefan Hajnoczi <stefa...@gmail.com> wrote: > > On Tue, Mar 6, 2018 at 11:25 PM, Stefano Panella <spane...@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
Re: [Qemu-devel] [PATCH 2/2] iotests: add 208 nbd-server + blockdev-snapshot-sync test case
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 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
> ---
> 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 00..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
> +#
> +# 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 00..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
>
[Qemu-devel] xhci and ehci qemu emulation performance
Hi, I am very new to the qemu list, Thanks for your time in advance if you can answer some of my questions. I see you have done a big work on xhci emulation support for qemu! I would like to ask: - what is it the status of xhci support for SS usb3 devices? - Is it available any performance measurement on the emulation compared to native (for example attaching an usb3 SSD drive etc.)? Thanks again, Stefano
Re: [Qemu-devel] xhci and ehci qemu emulation performance
On 11/08/2012 03:20 PM, Gerd Hoffmann wrote: On 11/08/12 16:08, Stefano Panella wrote: Hi, I am very new to the qemu list, Thanks for your time in advance if you can answer some of my questions. I see you have done a big work on xhci emulation support for qemu! I would like to ask: - what is it the status of xhci support for SS usb3 devices? no streams support yet, otherwise it should work in theory. There might be bugs though, and xhci hasn't seen that much testing yet. I would like to try it under Xen, do you think that would be feasible? Where can I find some documentation on how to use it? - Is it available any performance measurement on the emulation compared to native (for example attaching an usb3 SSD drive etc.)? I don't have benchmark numbers. cheers, Gerd Thanks + Regards, Stefano
