From: Stefano Panella <stefano.panella@citrix.com>
To: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: [Qemu-devel] block-layer: questions on manipulation of internal nodes
Date: Wed, 14 Mar 2018 15:07:21 +0000 [thread overview]
Message-ID: <1521040041089.43942@citrix.com> (raw)
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
next reply other threads:[~2018-03-14 15:41 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-14 15:07 Stefano Panella [this message]
2018-03-16 15:55 ` [Qemu-devel] block-layer: questions on manipulation of internal nodes Stefan Hajnoczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1521040041089.43942@citrix.com \
--to=stefano.panella@citrix.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.