From: "Richard W.M. Jones" <rjones@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: kwolf@redhat.com, qemu-devel@nongnu.org
Subject: Re: Some comments on using qemu-storage-daemon
Date: Wed, 30 Sep 2020 10:08:27 +0100 [thread overview]
Message-ID: <20200930090827.GB29698@redhat.com> (raw)
In-Reply-To: <20200930084900.GB2264779@redhat.com>
On Wed, Sep 30, 2020 at 09:49:00AM +0100, Daniel P. Berrangé wrote:
> On Wed, Sep 30, 2020 at 09:40:59AM +0100, Richard W.M. Jones wrote:
> > I understand that QSD is at an early stage of development and I'm sure
> > you have plans to fix these things. Nevertheless here are my comments
> > after trying to add an interop test with libnbd.
> >
> > (1) Documentation! (Or complete lack of it ...) I had to ask Kevin
> > how to construct the command line because several things were not
> > obvious. In particular the --blockdev parameters only make sense if
> > you're already used to constructing blockdev parameters (and these
> > are, separately, not well-documented). And you have to supply the
> > parameters in a particular order on the command line, else it doesn't
> > work.
> >
> > (2) There seems to be no --pid-file option, so there's no way of
> > knowing when the server is ready to accept connections, except to
> > start QSD and then "sleep for a bit".
>
> It supports QMP via the normal chardev framework, so you can pre-create
> a UNIX listener socket and pass in the pre-opened FD. The parent just
> sends the QMP handshake, and waits until it gets EOF (exited during
> startup) or gets the QMP response (successfully running).
This is all fine when run from libvirt (and I do understand that QSD
is all about that, not necessarily a standalone general purpose
server), but also that's a massive hassle for anyone else trying to
use QSD. I'm not confident I could correctly formulate the set of QMP
commands that would be needed to make this work, even with the
documentation and full source code.
Also this moves the problem to "when is the chardev socket ready",
especially when not using chardev over stdio.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
prev parent reply other threads:[~2020-09-30 9:09 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-30 8:40 Some comments on using qemu-storage-daemon Richard W.M. Jones
2020-09-30 8:49 ` Daniel P. Berrangé
2020-09-30 9:08 ` Richard W.M. Jones [this message]
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=20200930090827.GB29698@redhat.com \
--to=rjones@redhat.com \
--cc=berrange@redhat.com \
--cc=kwolf@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).