similar to: nbdkit: Could not read L1 table when reading exported qcow2

On Wed, Nov 21, 2018 at 09:25:05AM +0000, Richard W.M. Jones wrote: > nbdkit: file.2: error: invalid request: offset and count are out of range: offset=196608 count=512 Actually what happens even more precisely is that the underlying file is not a multiple of 512 bytes (196624 ≡ 16 mod 512). qemu-img (the client) issues a request for the final "sector" of the file which goes beyond

On Wed, Nov 21, 2018 at 11:33:33AM +0800, Han Han wrote: > Hello, I face a problem on the nbdkit server: > > Version-Release number of selected component (if applicable): > nbdkit-v1.9.1 > qemu-utils-2.12+dfsg-3+b1 > > How reproducible: > 100% > > Steps: > 1. Create a qcow2 file > # qemu-img create disk 1G -f qcow2 This creates a 1GB virtual size qcow2 (real

On Wed, Nov 21, 2018 at 10:33 PM Eric Blake <eblake@redhat.com> wrote: > On 11/21/18 4:39 AM, Richard W.M. Jones wrote: > > On Wed, Nov 21, 2018 at 09:25:05AM +0000, Richard W.M. Jones wrote: > >> nbdkit: file.2: error: invalid request: offset and count are out of > range: offset=196608 count=512 > > > > Actually what happens even more precisely is that the

The docs are a lot more useful with a graphic showing how to wire together nbdkit as a bridge from old-to-new. The converse, bridging new-to-old, is best deferred until I add support for the nbd plugin connecting to a TCP socket. It is also worth mentioning use of nbdkit filters (after all, qemu-nbd 4.0 was able to deprecate its --partition option by pointing to 'nbdkit --filter=partition nbd

On 11/21/18 4:39 AM, Richard W.M. Jones wrote: > On Wed, Nov 21, 2018 at 09:25:05AM +0000, Richard W.M. Jones wrote: >> nbdkit: file.2: error: invalid request: offset and count are out of range: offset=196608 count=512 > > Actually what happens even more precisely is that the underlying file > is not a multiple of 512 bytes (196624 ≡ 16 mod 512). > > qemu-img (the client)

The first four patches are fairly routine clean up and can be reviewed/applied on their own. The fifth patch is problematic as described below. At the moment if you want to proxy through to qemu-nbd (eg. for handling qcow2 files) it's rather complicated and you end up having to manage the sockets and clean up yourself. However the library we use for the proxying supports a perfectly good

I fixed the deadlock - turned out to be an actual bug in the nbd plugin (see patch 8). I changed the command syntax so it's now: nbdkit nbd command=qemu arg=-f arg=qcow2 arg=/path/to/disk.qcow2 Nir wrote: 18:08 < nsoffer> rwmjones: regarding the nbd proxy patches, did you have specific flow that help us? 18:08 < nsoffer> rwmjones: or this is just a way to support qcow2 in the

nbdkit <= 1.1.28 defaulted to the oldstyle protocol for compatibility with qemu and libguestfs. However qemu >= 2.6 can now work with either protocol and is widely installed. Also newstyle is required for newer features such as export names and TLS. In addition nbd-client dropped support for oldstyle entirely. You can select the oldstyle protocol by adding ‘-o’, and it is still tested.

When we added support for .extents, we had nbdkit unconditionally support structured replies if the client requests them, and the plugin's .can_extents has no impact on what the server advertises. However, while the plugin API doesn't care whether the client requested SR, there are still integration situations where not advertising SR can be useful (such as comparison on what a client does

On 8/8/23 00:28, Richard W.M. Jones wrote: > Occasionally this test will choose a random seed which results in an > all-zeroes disk. The test tries to convert this to a compressed qcow2 > file, and fails because no compressed clusters are detected in the > resulting file. This happens because qcow2 stores zero clusters with > a special sparse representation, they are never stored

This parameter provided a name for the "default export" -- ie. the one and only export returned to the client by NBD_OPT_LIST. But nbdkit traditionally didn't care what export name the client requested. Since 1.16 plugins have been able to serve different content per export name (and return errors for unknown exports), but the -e option didn't reflect that and only created

Occasionally this test will choose a random seed which results in an all-zeroes disk. The test tries to convert this to a compressed qcow2 file, and fails because no compressed clusters are detected in the resulting file. This happens because qcow2 stores zero clusters with a special sparse representation, they are never stored compressed, so a disk with only zeroes in it will never contain

qemu is about to add 'qemu-nbd --list', which exercises NBD_OPT_LIST and NBD_OPT_INFO to give the user as much detail as possible about an export without actually connecting to it. For that to display more than the export name when nbdkit is the server, we need to implement NBD_OPT_INFO. Thankfully, the NBD spec intentionally made the command very similar to NBD_OPT_GO, to the point that

On Wed, Sep 11, 2019 at 08:48:28AM -0500, Eric Blake wrote: > On 9/11/19 5:40 AM, Richard W.M. Jones wrote: > > Very much a work in progress as there are still many tests using > > qemu-io which are candidates for conversion. > > > > You'll notice at the end of test-full.sh that the new test has some > > duplicated code which looks as if it ought to be

I got annoyed by qemu-nbd's default of only allowing a single connection; combine that with nbdkit's nbd plugin, and even 'qemu-nbd --list' of nbdkit counts as the single connection and immediately hangs up. If we introduce a shared mode, then 'qemu-nbd --list' can connect as many times as it wants without killing the original qemu-nbd wrapped by nbdkit. But this in turn

On 11/16/2017 05:53 AM, Richard W.M. Jones wrote: > > ACK series, with one minor change: > > Please add a reference to the new manual page in the ‘SEE ALSO’ > section at the bottom of the following two files: > > docs/nbdkit.pod This one is obvious; I also added: diff --git i/docs/nbdkit.pod w/docs/nbdkit.pod index 155fcb5..e3043ba 100644 --- i/docs/nbdkit.pod +++

On Thu, Mar 08, 2018 at 12:13:01PM +0000, Nir Soffer wrote: > On Wed, Mar 7, 2018 at 12:18 AM Richard W.M. Jones <rjones@redhat.com> > wrote: > > > Previous versions: > > v3: https://www.redhat.com/archives/libguestfs/2018-March/msg00000.html > > v2: > > https://www.redhat.com/archives/libguestfs/2018-February/msg00177.html > > v1: > >

On 04/12/2018 05:24 AM, Richard W.M. Jones wrote: > I don't think we have nbd-server in RHEL, and in any case wouldn't it > be better to use qemu-nbd? > > You just start a new qemu-nbd process instead of faffing around with > configuration files, kill the qemu-nbd process when you're done, and > qemu-nbd supports qcow2 already. That, and qemu-nbd supports

This happened on s390 in Koji, once. The key lines from the log are: + start_t=0 nbdkit: sh[1]: debug: retry 1: waiting 1 seconds before retrying nbdkit: sh[1]: debug: retry 1: waiting 1 seconds before retrying + end_t=1 Somehow nbdkit did wait 2 seconds (or at least, nbdkit_nanosleep (1, 0) was called twice by the retry filter). But in the bash script, time (as measured by $SECONDS) advanced

* Change the title so it's informative and searchable. * Remove references to the non-libnbd plugin. * Headings for examples. * Correct reference to qemu-nbd(8) man page. * General copy-editing to improve readability. * Change style in places so it matches other manual pages. --- plugins/nbd/nbdkit-nbd-plugin.pod | 192 +++++++++++++++++------------- 1 file changed, 109 insertions(+), 83