On 1/17/19 4:05 AM, Vladimir Sementsov-Ogievskiy wrote:
> 12.01.2019 20:58, Eric Blake wrote:
>> We want to be able to detect whether a given qemu NBD server is
>> exposing the right export(s) and dirty bitmaps, at least for
>> regression testing. We could use 'nbd-client -l' from the upstream
>>
17.01.2019 19:58, Eric Blake wrote:
> On 1/17/19 4:05 AM, Vladimir Sementsov-Ogievskiy wrote:
>> 12.01.2019 20:58, Eric Blake wrote:
>>> We want to be able to detect whether a given qemu NBD server is
>>> exposing the right export(s) and dirty bitmaps, at least for
>>> regression testing. We
On 1/17/19 10:39 AM, Kevin Wolf wrote:
> Am 17.01.2019 um 16:33 hat Eric Blake geschrieben:
>> 'qemu-img info' is useful for showing additional information
>> about an image - but sometimes the interesting information is
>> specific to the protocol rather than to the format layer. Set
>> the
On Thu 17 Jan 2019 04:50:20 PM CET, Eric Blake wrote:
>> Removing the backing file can be done by simply passing the option {
>> ..., "backing": null } to x-blockdev-reopen.
>>
> Hmm - that makes my proposal of "option":null as an explicit request
> to the default a bit trickier, if we are
Am 17.01.2019 um 16:33 hat Eric Blake geschrieben:
> 'qemu-img info' is useful for showing additional information
> about an image - but sometimes the interesting information is
> specific to the protocol rather than to the format layer. Set
> the groundwork for showing this information; further
Paolo Bonzini writes:
> On 16/01/19 09:33, Markus Armbruster wrote:
>> What problem exactly are we trying to solve here?
>> To the best of my knowledge, typedefs.h has been working just fine for
>> us, and I can't see why it shouldn't continue to work just fine.
>
> Patches don't have to solve
17.01.2019 6:21, Eric Blake wrote:
> On 1/16/19 9:43 AM, Vladimir Sementsov-Ogievskiy wrote:
>
>>> @@ -839,9 +842,25 @@ static int nbd_list_meta_contexts(QIOChannel *ioc,
>>>
>>>ret = nbd_receive_one_meta_context(ioc,
>>> NBD_OPT_LIST_META_CONTEXT,
>>>
> -Original Message-
> From: Alex Bennée [mailto:alex.ben...@linaro.org]
> Sent: 17 January 2019 08:21
> To: Andrew Cooper
> Cc: peter.mayd...@linaro.org; Kevin Wolf ; Stefano
> Stabellini ; open list:Block layer core bl...@nongnu.org>; qemu-de...@nongnu.org; Max Reitz ;
> Paul Durrant ;
Andrew Cooper writes:
> On 16/01/2019 12:13, Alex Bennée wrote:
>> The %lu format string is different depending on the host architecture
>> which causes builds like the debian-armhf-cross build to fail. Use the
>> correct PRi64 format string.
>>
>> Signed-off-by: Alex Bennée
>> ---
>>
"Michael S. Tsirkin" writes:
> On Wed, Jan 16, 2019 at 12:49:07PM +0100, Paolo Bonzini wrote:
>> On 16/01/19 12:34, Gerd Hoffmann wrote:
>> > Hi,
>> >
>> >> typedefs.h is useful to avoid rebuilding the world too often if a type
>> >> is used many times as a pointer, but rarely as a struct and
I got tired of debugging whether a server was advertising the
correct things during negotiation by inspecting the trace
logs of qemu-io as client - not to mention that without SOME
sort of client tracing particular commands, we can't easily
regression test the server for correct behavior. The
We have a race between the nbd server and the client both trying
to report errors at once which can make the test sometimes fail
if the output lines swap order under load. Break the race by
collecting server messages into a file and then replaying that
at the end of the test.
Signed-off-by: Eric
The next commit will add an EXAMPLES section to qemu-nbd.8;
for that to work, we need to recognize EXAMPLES in texi2pod.
We also need to add a dependency from all man pages against
the generator script, since a change to the generator may
cause the resulting man page to differ.
Signed-off-by:
On 12/21/18 8:58 AM, yuchenlin wrote:
> There is a possible hang in original binary searsh implemtation. That is
> if chunk1 = 4, chunk2 = 5, chunk3 = 4, and we go else case.
>
> The chunk1 will be still 4, and so on.
>
> Signed-off-by: yuchenlin
Generally we ask that people use their full
Commit 3d068aff forgot to advertise available qemu: contexts
when the client requests a list with 0 queries. Furthermore,
3.0 shipped with a qemu-img hack of x-dirty-bitmap (commit
216ee365) that _silently_ acts as though the entire image is
clean if a requested bitmap is not present. Both bugs
Right now, nbd_receive_list() is only called by
nbd_receive_query_exports(), which in turn is only called if the
server lacks NBD_OPT_GO but has working option negotiation, and is
merely used as a quality-of-implementation trick since servers
can't give decent errors for NBD_OPT_EXPORT_NAME.
Rename the function to nbd_opt_info_or_go() with an added parameter
and slight changes to comments and trace messages, in order to
reuse the function for NBD_OPT_INFO.
Signed-off-by: Eric Blake
---
v4: split out new patch [Vladimir]
---
nbd/client.c | 36
We want to be able to detect whether a given qemu NBD server is
exposing the right export(s) and dirty bitmaps, at least for
regression testing. We could use 'nbd-client -l' from the upstream
NBD project to list exports, but it's annoying to rely on
out-of-tree binaries; furthermore, nbd-client
We want to be able to detect whether a given qemu NBD server is
exposing the right export(s) and dirty bitmaps, at least for
regression testing. We could use 'nbd-client -l' from the upstream
NBD project to list exports, but it's annoying to rely on
out-of-tree binaries; furthermore, nbd-client
An upcoming patch will add the ability for qemu-nbd to list
the services provided by an NBD server. Share the common
code of the TLS handshake by splitting the initial exchange
into a separate function, leaving only the export handling
in the original function. Functionally, there should be no
Document some useful qemu-nbd command lines. Mention some restrictions
on particular options, like -p being only for MBR images, or -c/-d
being Linux-only. Update some text given the recent change to no
longer serve oldstyle protocol (missed in commit 7f7dfe2a). Also,
consistently use trailing
Our copy-and-pasted open-coding of strtol handling forgot to
handle overflow conditions. Use qemu_strto*() instead.
In the case of --partition, since we insist on a user-supplied
partition to be non-zero, we can use 0 rather than -1 for our
initial value to distinguish when a partition is not
On 1/17/19 2:29 PM, John Snow wrote:
>
>
> On 12/21/18 8:58 AM, yuchenlin wrote:
>> There is a possible hang in original binary searsh implemtation. That is
>> if chunk1 = 4, chunk2 = 5, chunk3 = 4, and we go else case.
>>
>> The chunk1 will be still 4, and so on.
>>
>> Signed-off-by:
When the user requests a partition, we were using data read
from the disk as disk offsets without a bounds check. We got
lucky that even when computed offsets are out-of-bounds,
blk_pread() will gracefully catch the error later (so I don't
think a malicious image can crash or exploit qemu-nbd, and
We want to be able to detect whether a given qemu NBD server is
exposing the right export(s) and dirty bitmaps, at least for
regression testing. We could use 'nbd-client -l' from the upstream
NBD project to list exports, but it's annoying to rely on
out-of-tree binaries; furthermore, nbd-client
Refactor nbd_negotiate_simple_meta_context() to pull out the
code that can be reused to send a LIST request for 0 or 1 query.
No semantic change. The old comment about 'sizeof(uint32_t)'
being equivalent to '/* number of queries */' is no longer
needed, now that we are computing 'sizeof(queries)'
Although our compile-time environment is set up so that we always
support long files with 64-bit off_t, we have no guarantee whether
off_t is the same type as int64_t. This requires casts when
printing values, and prevents us from directly using qemu_strtoi64()
(which will be done in the next
We only had two callers to nbd_export_new; qemu-nbd.c always
passed a valid offset/length pair (because it already checked
the file length, to ensure that offset was in bounds), while
blockdev-nbd.c always passed 0/-1. Then nbd_export_new reduces
the size to a multiple of BDRV_SECTOR_SIZE (can
Extract portions of nbd_negotiate_simple_meta_context() to
a new function nbd_receive_one_meta_context() that copies the
pattern of nbd_receive_list() for performing the argument
validation of one reply. The error message when the server
replies with more than one context changes slightly, but
Refactor the 'name' parameter of nbd_receive_negotiate() from
being a separate parameter into being part of the in-out 'info'.
This also spills over to a simplification of nbd_opt_go().
The main driver for this refactoring is that an upcoming patch
would like to add support to qemu-nbd to list
Another refactoring creating nbd_negotiate_finish_oldstyle()
for further reuse during 'qemu-nbd --list'.
Signed-off-by: Eric Blake
Reviewed-by: Richard W.M. Jones
---
nbd/client.c | 49 -
1 file changed, 32 insertions(+), 17 deletions(-)
diff
Any good new feature deserves some regression testing :)
Coverage includes:
- 223: what happens when there are 0 or more than 1 export,
proof that we can see multiple contexts including qemu:dirty-bitmap
- 233: proof that we can list over TLS, and that mix-and-match of
plain/TLS listings will
Pass 'info' instead of three separate parameters related to info,
when requesting the server to set the meta context. Update the
NBDExportInfo struct to rename the received id field to match the
fact that we are currently overloading the field to match whatever
context the user supplied through
The function could only ever return 0 or -EINVAL; make this
clearer by dropping a useless 'fail:' label.
Signed-off-by: Eric Blake
Reviewed-by: Richard W.M. Jones
Reviewed-by: Vladimir Sementsov-Ogievskiy
Message-Id: <20181215135324.152629-16-ebl...@redhat.com>
---
nbd/client.c | 51
On 1/9/19 2:21 PM, Eric Blake wrote:
> Why are we restricting things to only export disabled bitmaps?
Late reply, but the original thought almost surely was that we would
only be exporting bitmaps for fleecing use, which should have a
non-changing bitmap attached to it.
Just some error
12.01.2019 20:58, Eric Blake wrote:
> We want to be able to detect whether a given qemu NBD server is
> exposing the right export(s) and dirty bitmaps, at least for
> regression testing. We could use 'nbd-client -l' from the upstream
> NBD project to list exports, but it's annoying to rely on
>
On Tue, Jan 15, 2019 at 03:29:42PM +0200, Alberto Garcia wrote:
> Here's how to reproduce the crash:
>
> { "execute": "qmp_capabilities" }
> { "execute": "blockdev-add", "arguments": {"driver": "null-co", "node-name":
> "hd0"}}
> { "execute": "object-add", "arguments": {"qom-type": "iothread",
On Thu 17 Jan 2019 11:23:31 AM CET, Stefan Hajnoczi wrote:
> I'm asking because x-blockdev-set-iothread is a low-level testing
> command and it can create IOThread configurations that real-world
> users never reach.
I see, I suppose I had the wrong assumption about that command then!
Berto
12.01.2019 20:57, Eric Blake wrote:
> I got tired of debugging whether a server was advertising the
> correct things during negotiation by inspecting the trace
> logs of qemu-io as client - not to mention that without SOME
> sort of client tracing particular commands, we can't easily
> regression
On Wed 16 Jan 2019 02:54:44 PM CET, Stefan Hajnoczi wrote:
> The x-blockdev-set-iothread command is for low-level tests so I don't
> expect users to invoke it.
As I said in a different e-mail maybe this is not necessary then.
> This patch series makes virtio-blk and virtio-scsi more robust,
>
16.01.2019 19:02, Max Reitz wrote:
> On 29.12.18 13:20, Vladimir Sementsov-Ogievskiy wrote:
>> Backup-top filter does copy-before-write operation. It should be
>> inserted above active disk and has a target node for CBW, like the
>> following:
>>
>> +---+
>> | Guest |
>>
Kevin,
could you please take a look at my last comments?
Thanks!
Denis
On 15.01.2019 10:22, Denis Plotnikov wrote:
> ping ping ping ping
>
> On 09.01.2019 11:18, Denis Plotnikov wrote:
>> ping ping!!!
>>
>> On 18.12.2018 11:53, Denis Plotnikov wrote:
>>> ping ping
>>>
>>> On 14.12.2018
On 1/12/19 11:58 AM, Eric Blake wrote:
> Any good new feature deserves some regression testing :)
> Coverage includes:
> - 223: what happens when there are 0 or more than 1 export,
> proof that we can see multiple contexts including qemu:dirty-bitmap
> - 233: proof that we can list over TLS, and
On 1/17/19 5:38 AM, Vladimir Sementsov-Ogievskiy wrote:
>> Since v2:
>> - Several patches merged already
>> - 3 new patches based on audit of off_t vs. strtol
>> - rebase patches on top of other changes, such as qemu-nbd --bitmap
>> - address various review comments [Vladimir, Rich]
>> - drop
On 1/16/19 8:23 AM, Vladimir Sementsov-Ogievskiy wrote:
> We generally do very similar things around nbd_read: error_prepend,
> specifying, what we have tried to read and be_to_cpu conversion of
> integers.
>
> So, it seems reasonable to move common things to helper functions,
> which:
> 1.
On 1/17/19 2:07 AM, Vladimir Sementsov-Ogievskiy wrote:
> 17.01.2019 6:21, Eric Blake wrote:
>> On 1/16/19 9:43 AM, Vladimir Sementsov-Ogievskiy wrote:
>>
@@ -839,9 +842,25 @@ static int nbd_list_meta_contexts(QIOChannel *ioc,
ret = nbd_receive_one_meta_context(ioc,
Am 17.01.2019 um 13:57 hat Denis Plotnikov geschrieben:
> Kevin,
>
> could you please take a look at my last comments?
I read it, and what it told me is essentially that I need to work on it
myself to fully understand the problem and possible acceptable solutions
because you can't seem to find
Expose information that the NBD client remembers from its handshake
with the server. This is comparable to what 'qemu-nbd --list'
outputs when describing a server's capability, so a future patch
may refactor that to reuse this QAPI type.
The display of flags is interesting - rather than compute
When analyzing performance, it might be nice to let 'qemu-img info'
expose details that it learned from the underlying file or block
device. Start the process by picking a few useful items determined
during raw_open_common().
Signed-off-by: Eric Blake
---
qapi/block-core.json | 24
'qemu-img info' is useful for showing additional information
about an image - but sometimes the interesting information is
specific to the protocol rather than to the format layer. Set
the groundwork for showing this information; further patches
will then enable specific pieces of information.
Signed-off-by: Alberto Garcia
---
block/commit.c | 8
1 file changed, 8 insertions(+)
diff --git a/block/commit.c b/block/commit.c
index 53148e610b..8824d135e0 100644
--- a/block/commit.c
+++ b/block/commit.c
@@ -73,6 +73,8 @@ static int commit_prepare(Job *job)
{
CommitBlockJob
Of all options of type BlockdevRef used to specify children in
BlockdevOptions, 'backing' is the only one that is optional.
For "x-blockdev-reopen" we want that if an option is omitted then it
must be reset to its default value. The default value of 'backing'
means that QEMU opens the backing
bdrv_reopen_prepare() receives a BDRVReopenState with (among other
things) a new set of options to be applied to that BlockDriverState.
If an option is missing then it means that we want to reset it to its
default value rather than keep the previous one. This way the state
of the block device
Children in QMP are specified with BlockdevRef / BlockdevRefOrNull,
which can contain a set of child options, a child reference, or
NULL. In optional attributes like "backing" it can also be missing.
Only the first case (set of child options) is being handled properly
by bdrv_reopen_queue(). This
This patch adds several tests for the x-blockdev-reopen QMP command.
Signed-off-by: Alberto Garcia
---
tests/qemu-iotests/224 | 1001
tests/qemu-iotests/224.out |5 +
tests/qemu-iotests/group |1 +
3 files changed, 1007 insertions(+)
Hi,
here's a patch series to implement a QMP command for bdrv_reopen().
This is not too different from the previous iteration (RFC v2, see
changes below), but I'm not tagging it as RFC any longer.
The new command is called x-blockdev-reopen, and it's designed to be
similar to blockdev-add. It
Signed-off-by: Alberto Garcia
---
block/stream.c | 16
1 file changed, 16 insertions(+)
diff --git a/block/stream.c b/block/stream.c
index 7a49ac0992..39a2e10892 100644
--- a/block/stream.c
+++ b/block/stream.c
@@ -54,6 +54,14 @@ static int coroutine_fn
Signed-off-by: Alberto Garcia
---
block/mirror.c | 8
1 file changed, 8 insertions(+)
diff --git a/block/mirror.c b/block/mirror.c
index 22bef9f7e9..afbc30da61 100644
--- a/block/mirror.c
+++ b/block/mirror.c
@@ -630,6 +630,10 @@ static int mirror_exit_common(Job *job)
}
This parameter has been unused since 1a63a907507fbbcfaee3f622907ec244b
Signed-off-by: Alberto Garcia
---
block.c | 4 ++--
block/replication.c | 3 +--
include/block/block.h | 2 +-
qemu-io-cmds.c| 2 +-
4 files changed, 5 insertions(+), 6 deletions(-)
diff --git
The bdrv_reopen_queue() function is used to create a queue with
the BDSs that are going to be reopened and their new options. Once
the queue is ready bdrv_reopen_multiple() is called to perform the
operation.
The original options from each one of the BDSs are kept, with the new
options passed to
This patch adds two new fields to BlockDriver:
- runtime_opts: list of runtime options for a particular block
driver. We'll use this list later to detect what options are
missing when we try to reopen a block device.
- mutable_opts: names of the runtime options that can be reset
This patch allows the user to change the backing file of an image that
is being reopened. Here's what it does:
- In bdrv_reopen_prepare(): check that the value of 'backing' points
to an existing node or is null. If it points to an existing node it
also needs to make sure that replacing the
This command allows reopening an arbitrary BlockDriverState with a
new set of options. Some options (e.g node-name) cannot be changed
and some block drivers don't allow reopening, but otherwise this
command is modelled after 'blockdev-add' and the state of the reopened
BlockDriverState should
Our permission system is useful to define what operations are allowed
on a certain block node and includes things like BLK_PERM_WRITE or
BLK_PERM_RESIZE among others.
One of the permissions is BLK_PERM_GRAPH_MOD which allows "changing
the node that this BdrvChild points to". The exact meaning of
On 1/17/19 9:33 AM, Alberto Garcia wrote:
>
> Changing options
>
> The general idea is quite straightforward, but the devil is in the
> details. Since this command tries to mimic blockdev-add, the state of
> the block device after being reopened should generally be equivalent
>
On 17.01.2019 17:23, Kevin Wolf wrote:
> Am 17.01.2019 um 13:57 hat Denis Plotnikov geschrieben:
>> Kevin,
>>
>> could you please take a look at my last comments?
>
> I read it, and what it told me is essentially that I need to work on it
> myself to fully understand the problem and possible
66 matches
Mail list logo
