Skip to content
  • Eric Blake's avatar
    68b96f15
    qemu-nbd: Add --list option · 68b96f15
    Eric Blake authored
    
    
    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 doesn't necessarily
    know about all of the qemu NBD extensions.  Thus, it is time to add
    a new mode to qemu-nbd that merely sniffs all possible information
    from the server during handshake phase, then disconnects and dumps
    the information.
    
    This patch actually implements --list/-L, while reusing other
    options such as --tls-creds for now designating how to connect
    as the client (rather than their non-list usage of how to operate
    as the server).
    
    I debated about adding this functionality to something akin to
    'qemu-img info' - but that tool does not readily lend itself
    to connecting to an arbitrary NBD server without also tying to
    a specific export (I may, however, still add ImageInfoSpecificNBD
    for reporting the bitmaps available when connecting to a single
    export).  And, while it may feel a bit odd that normally
    qemu-nbd is a server but 'qemu-nbd -L' is a client, we are not
    really making the qemu-nbd binary that much larger, because
    'qemu-nbd -c' has to operate as both server and client
    simultaneously across two threads when feeding the kernel module
    for /dev/nbdN access.
    
    Sample output:
    $ qemu-nbd -L
    exports available: 1
     export: ''
      size:  65536
      flags: 0x4ed ( flush fua trim zeroes df cache )
      min block: 512
      opt block: 4096
      max block: 33554432
      available meta contexts: 1
       base:allocation
    
    Note that the output only lists sizes if the server sent
    NBD_FLAG_HAS_FLAGS, because a newstyle server does not give
    the size otherwise.  It has the side effect that for really
    old servers that did not send any flags, the size is not
    output even though it was available.  However, I'm not too
    concerned about that - oldstyle servers are (rightfully)
    getting less common to encounter (qemu 3.0 was the last
    version where we even serve it), and most existing servers
    that still even offer oldstyle negotiation (such as nbdkit)
    still send flags (since that was added to the NBD protocol
    in 2007 to permit read-only connections).
    
    Not done here, but maybe worth future experiments: capture
    the meat of NBDExportInfo into a QAPI struct, and use the
    generated QAPI pretty-printers instead of hand-rolling our
    output loop.  It would also permit us to add a JSON output
    mode for machine parsing.
    
    Signed-off-by: default avatarEric Blake <eblake@redhat.com>
    Reviewed-by: default avatarRichard W.M. Jones <rjones@redhat.com>
    Message-Id: <20190117193658.16413-20-eblake@redhat.com>
    Reviewed-by: default avatarVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
    68b96f15
    qemu-nbd: Add --list option
    Eric Blake authored
    
    
    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 doesn't necessarily
    know about all of the qemu NBD extensions.  Thus, it is time to add
    a new mode to qemu-nbd that merely sniffs all possible information
    from the server during handshake phase, then disconnects and dumps
    the information.
    
    This patch actually implements --list/-L, while reusing other
    options such as --tls-creds for now designating how to connect
    as the client (rather than their non-list usage of how to operate
    as the server).
    
    I debated about adding this functionality to something akin to
    'qemu-img info' - but that tool does not readily lend itself
    to connecting to an arbitrary NBD server without also tying to
    a specific export (I may, however, still add ImageInfoSpecificNBD
    for reporting the bitmaps available when connecting to a single
    export).  And, while it may feel a bit odd that normally
    qemu-nbd is a server but 'qemu-nbd -L' is a client, we are not
    really making the qemu-nbd binary that much larger, because
    'qemu-nbd -c' has to operate as both server and client
    simultaneously across two threads when feeding the kernel module
    for /dev/nbdN access.
    
    Sample output:
    $ qemu-nbd -L
    exports available: 1
     export: ''
      size:  65536
      flags: 0x4ed ( flush fua trim zeroes df cache )
      min block: 512
      opt block: 4096
      max block: 33554432
      available meta contexts: 1
       base:allocation
    
    Note that the output only lists sizes if the server sent
    NBD_FLAG_HAS_FLAGS, because a newstyle server does not give
    the size otherwise.  It has the side effect that for really
    old servers that did not send any flags, the size is not
    output even though it was available.  However, I'm not too
    concerned about that - oldstyle servers are (rightfully)
    getting less common to encounter (qemu 3.0 was the last
    version where we even serve it), and most existing servers
    that still even offer oldstyle negotiation (such as nbdkit)
    still send flags (since that was added to the NBD protocol
    in 2007 to permit read-only connections).
    
    Not done here, but maybe worth future experiments: capture
    the meat of NBDExportInfo into a QAPI struct, and use the
    generated QAPI pretty-printers instead of hand-rolling our
    output loop.  It would also permit us to add a JSON output
    mode for machine parsing.
    
    Signed-off-by: default avatarEric Blake <eblake@redhat.com>
    Reviewed-by: default avatarRichard W.M. Jones <rjones@redhat.com>
    Message-Id: <20190117193658.16413-20-eblake@redhat.com>
    Reviewed-by: default avatarVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Loading