Skip to content
Snippets Groups Projects
  1. Jul 12, 2022
  2. Jun 24, 2022
    • Xie Yongji's avatar
      vduse-blk: Add name option · 779d82e1
      Xie Yongji authored
      
      Currently we use 'id' option as the name of VDUSE device.
      It's a bit confusing since we use one value for two different
      purposes: the ID to identfy the export within QEMU (must be
      distinct from any other exports in the same QEMU process, but
      can overlap with names used by other processes), and the VDUSE
      name to uniquely identify it on the host (must be distinct from
      other VDUSE devices on the same host, but can overlap with other
      export types like NBD in the same process). To make it clear,
      this patch adds a separate 'name' option to specify the VDUSE
      name for the vduse-blk export instead.
      
      Signed-off-by: default avatarXie Yongji <xieyongji@bytedance.com>
      Message-Id: <20220614051532.92-7-xieyongji@bytedance.com>
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      779d82e1
    • Xie Yongji's avatar
      vduse-blk: Add serial option · 0862a087
      Xie Yongji authored
      
      Add a 'serial' option to allow user to specify this value
      explicitly. And the default value is changed to an empty
      string as what we did in "hw/block/virtio-blk.c".
      
      Signed-off-by: default avatarXie Yongji <xieyongji@bytedance.com>
      Message-Id: <20220614051532.92-6-xieyongji@bytedance.com>
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      0862a087
    • Stefan Hajnoczi's avatar
      qsd: document vduse-blk exports · ca941c40
      Stefan Hajnoczi authored
      
      Document vduse-blk exports in qemu-storage-daemon --help and the
      qemu-storage-daemon(1) man page.
      
      Based-on: <20220523084611.91-1-xieyongji@bytedance.com>
      Cc: Xie Yongji <xieyongji@bytedance.com>
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Message-Id: <20220525121947.859820-1-stefanha@redhat.com>
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      ca941c40
  3. May 28, 2022
  4. Apr 21, 2022
  5. Apr 20, 2022
  6. Mar 22, 2022
  7. Mar 04, 2022
    • Hanna Reitz's avatar
      qsd: Add --daemonize · 2525edd8
      Hanna Reitz authored
      
      To implement this, we reuse the existing daemonizing functions from the
      system emulator, which mainly do the following:
      - Fork off a child process, and set up a pipe between parent and child
      - The parent process waits until the child sends a status byte over the
        pipe (0 means that the child was set up successfully; anything else
        (including errors or EOF) means that the child was not set up
        successfully), and then exits with an appropriate exit status
      - The child process enters a new session (forking off again), changes
        the umask, and will ignore terminal signals from then on
      - Once set-up is complete, the child will chdir to /, redirect all
        standard I/O streams to /dev/null, and tell the parent that set-up has
        been completed successfully
      
      In contrast to qemu-nbd's --fork implementation, during the set up
      phase, error messages are not piped through the parent process.
      qemu-nbd mainly does this to detect errors, though (while os_daemonize()
      has the child explicitly signal success after set up); because we do not
      redirect stderr after forking, error messages continue to appear on
      whatever the parent's stderr was (until set up is complete).
      
      Signed-off-by: default avatarHanna Reitz <hreitz@redhat.com>
      Message-Id: <20220303164814.284974-4-hreitz@redhat.com>
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      2525edd8
    • Hanna Reitz's avatar
      qsd: Add pre-init argument parsing pass · 79d51d73
      Hanna Reitz authored
      
      In contrast to qemu-nbd (where it is called --fork) and the system
      emulator, QSD does not have a --daemonize switch yet.  Just like them,
      QSD allows setting up block devices and exports on the command line.
      When doing so, it is often necessary for whoever invoked the QSD to wait
      until these exports are fully set up.  A --daemonize switch allows
      precisely this, by virtue of the parent process exiting once everything
      is set up.
      
      Note that there are alternative ways of waiting for all exports to be
      set up, for example:
      - Passing the --pidfile option and waiting until the respective file
        exists (but I do not know if there is a way of implementing this
        without a busy wait loop)
      - Set up some network server (e.g. on a Unix socket) and have the QSD
        connect to it after all arguments have been processed by appending
        corresponding --chardev and --monitor options to the command line,
        and then wait until the QSD connects
      
      Having a --daemonize option would make this simpler, though, without
      having to rely on additional tools (to set up a network server) or busy
      waiting.
      
      Implementing a --daemonize switch means having to fork the QSD process.
      Ideally, we should do this as early as possible: All the parent process
      has to do is to wait for the child process to signal completion of its
      set-up phase, and therefore there is basically no initialization that
      needs to be done before the fork.  On the other hand, forking after
      initialization steps means having to consider how those steps (like
      setting up the block layer or QMP) interact with a later fork, which is
      often not trivial.
      
      In order to fork this early, we must scan the command line for
      --daemonize long before our current process_options() call.  Instead of
      adding custom new code to do so, just reuse process_options() and give
      it a @pre_init_pass argument to distinguish the two passes.  I believe
      there are some other switches but --daemonize that deserve parsing in
      the first pass:
      
      - --help and --version are supposed to only print some text and then
        immediately exit (so any initialization we do would be for naught).
        This changes behavior, because now "--blockdev inv-drv --help" will
        print a help text instead of complaining about the --blockdev
        argument.
        Note that this is similar in behavior to other tools, though: "--help"
        is generally immediately acted upon when finding it in the argument
        list, potentially before other arguments (even ones before it) are
        acted on.  For example, "ls /does-not-exist --help" prints a help text
        and does not complain about ENOENT.
      
      - --pidfile does not need initialization, and is already exempted from
        the sequential order that process_options() claims to strictly follow
        (the PID file is only created after all arguments are processed, not
        at the time the --pidfile argument appears), so it makes sense to
        include it in the same category as --daemonize.
      
      - Invalid arguments should always be reported as soon as possible.  (The
        same caveat with --help applies: That means that "--blockdev inv-drv
        --inv-arg" will now complain about --inv-arg, not inv-drv.)
      
      This patch does make some references to --daemonize without having
      implemented it yet, but that will happen in the next patch.
      
      Signed-off-by: default avatarHanna Reitz <hreitz@redhat.com>
      Reviewed-by: default avatarVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
      Message-Id: <20220303164814.284974-3-hreitz@redhat.com>
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      79d51d73
  8. Feb 01, 2022
  9. Jan 14, 2022
  10. Oct 29, 2021
  11. Oct 06, 2021
  12. Aug 11, 2021
  13. Mar 29, 2021
    • Hanna Reitz's avatar
      qsd: Document FUSE exports · 220222a0
      Hanna Reitz authored
      
      Implementing FUSE exports required no changes to the storage daemon, so
      we forgot to document them there.  Considering that both NBD and
      vhost-user-blk exports are documented in its man page (and NBD exports
      in its --help text), we should probably do the same for FUSE.
      
      Signed-off-by: default avatarMax Reitz <mreitz@redhat.com>
      Message-Id: <20210217115844.62661-1-mreitz@redhat.com>
      Reviewed-by: default avatarEric Blake <eblake@redhat.com>
      220222a0
  14. Mar 19, 2021
  15. Mar 08, 2021
  16. Feb 15, 2021
  17. Feb 02, 2021
  18. Jan 12, 2021
  19. Dec 18, 2020
    • Stefan Hajnoczi's avatar
      docs: generate qemu-storage-daemon-qmp-ref(7) man page · 23c02ace
      Stefan Hajnoczi authored
      
      Although individual qemu-storage-daemon QMP commands are identical to
      QEMU QMP commands, qemu-storage-daemon only supports a subset of QEMU's
      QMP commands. Generate a manual page of just the commands supported by
      qemu-storage-daemon so that users know exactly what is available in
      qemu-storage-daemon.
      
      Add an h1 heading in storage-daemon/qapi/qapi-schema.json so that
      block-core.json is at the h2 heading level.
      
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Message-Id: <20201209103802.350848-2-stefanha@redhat.com>
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      23c02ace
  20. Dec 11, 2020
  21. Nov 11, 2020
  22. Oct 23, 2020
  23. Oct 15, 2020
    • Kevin Wolf's avatar
      qemu-storage-daemon: Remove QemuOpts from --object parser · 8db1efd3
      Kevin Wolf authored
      
      The command line parser for --object parses the input twice: Once into
      QemuOpts just for detecting help options, and then again into a QDict
      using the keyval parser for actually creating the object.
      
      Now that the keyval parser can also detect help options, we can simplify
      this and remove the QemuOpts part.
      
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      Reviewed-by: default avatarEric Blake <eblake@redhat.com>
      Reviewed-by: default avatarMarkus Armbruster <armbru@redhat.com>
      Message-Id: <20201007164903.282198-5-kwolf@redhat.com>
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      8db1efd3
    • Kevin Wolf's avatar
      keyval: Parse help options · 8bf12c4f
      Kevin Wolf authored
      
      This adds a special meaning for 'help' and '?' as options to the keyval
      parser. Instead of being an error (because of a missing value) or a
      value for an implied key, they now request help, which is a new boolean
      output of the parser in addition to the QDict.
      
      A new parameter 'p_help' is added to keyval_parse() that contains on
      return whether help was requested. If NULL is passed, requesting help
      results in an error and all other cases work like before.
      
      Turning previous error cases into help is a compatible extension. The
      behaviour potentially changes for implied keys: They could previously
      get 'help' as their value, which is now interpreted as requesting help.
      
      This is not a problem in practice because 'help' and '?' are not a valid
      values for the implied key of any option parsed with keyval_parse():
      
      * audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
        "help" and "?" are not among its values
      
      * display: union DisplayOptions, implied key "type" is enum
        DisplayType, "help" and "?" are not among its values
      
      * blockdev: union BlockdevOptions, implied key "driver is enum
        BlockdevDriver, "help" and "?" are not among its values
      
      * export: union BlockExport, implied key "type" is enum BlockExportType,
        "help" and "?" are not among its values
      
      * monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
        "help" and "?" are not among its values
      
      * nbd-server: struct NbdServerOptions, no implied key.
      
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
      Reviewed-by: default avatarEric Blake <eblake@redhat.com>
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      8bf12c4f
  24. Oct 02, 2020
Loading