All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Wheeler <nbd@lists.ewheeler.net>
To: "Richard W.M. Jones" <rjones@redhat.com>
Cc: "Daniel P. Berrangé" <berrange@redhat.com>,
	QEMU <qemu-devel@nongnu.org>,
	nbd@other.debian.org, "Nir Soffer" <nsoffer@redhat.com>,
	libguestfs <libguestfs@redhat.com>
Subject: Re: [Libguestfs] Provide NBD via Browser over Websockets
Date: Fri, 29 May 2020 21:08:29 +0000 (UTC)	[thread overview]
Message-ID: <alpine.LRH.2.11.2005292107180.10871@mail.ewheeler.net> (raw)
In-Reply-To: <20200529141315.GU3888@redhat.com>

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3018 bytes --]

On Fri, 29 May 2020, Richard W.M. Jones wrote:
> On Fri, May 29, 2020 at 08:58:06AM -0500, Eric Blake wrote:
> > On 5/29/20 8:50 AM, Daniel P. Berrangé wrote:
> > 
> > >>>(2) You need to persuade qemu's NBD client to read from a WebSocket.
> > >>>I didn't really know anything about WebSockets until today but it
> > >>>seems as if they are a full-duplex protocol layered on top of HTTP [a].
> > >>>Is there a WebSocket proxy that turns WS into plain TCP (a bit like
> > >>>stunnel)?  Google suggests [b].
> > >>>
> > >>>[a] https://en.wikipedia.org/wiki/WebSocket#Protocol_handshake
> > >>>[b] https://github.com/novnc/websockify
> > >>
> > >>qemu already knows how to connect as a client to websockets; Dan Berrange
> > >>knows more about that setup.  I suspect it would not be too difficult to
> > >>teach the qemu NBD client code to use a WebSocket instead of a Unix or TCP
> > >>socket as its data source.
> > >
> > >Actually the inverse. The QIOChannelWebsocket impl is only the server
> > >side of the problem, as used by QEMU's VNC server. We've never implemented
> > >the client side. There is nothing especially stopping us doing that - just
> > >needs someone motivated with time to work on it.
> > 
> > In the meantime, you may still be able to set up something like:
> > 
> > local machine:
> > iso -> NBD server -> Unix socket -> websockify -> WebSocket
> 
> I guess the idea is to have a zero-install solution for the browser.
> As I said in the email earlier this is very common for IPMI-type
> remote access to blade servers and in my experience is implemented
> using a Java applet and a proprietary protocol terminated at the BMC
> (which then emulates a virtual CDROM to the server).  There are some
> HP blade servers on Red Hat's internal Beaker instance where you can
> play with this.  For qemu we wouldn't need to invent a new protocol
> when NBD is available and already implemented (albeit not yet on top
> of WebSockets).
> 
> The NBD server must run inside the browser and therefore be either
> written from scratch in Javascript, or an existing server
> cross-compiled to WASM (if that is possible - I don't really know).

Interesting idea about WASM.  I'll see if I can build one of the simple 
nbd servers that are around.  Not sure how to link it to the JS file IO, 
however.

--
Eric Wheeler


> > remote machine:
> > WebSocket -> websockify -> Unix socket -> qemu NBD client
> > 
> > Adding websocket client support into qemu would reduce the length of
> > the chain slightly (for less data copying) by getting rid of a
> > websockify proxy middleman, but would not necessarily improve
> > performance (it's hard to say where the latency bottlenecks will be
> > in the chain).
> 
> Rich.
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> libguestfs lets you edit virtual machines.  Supports shell scripting,
> bindings from many languages.  http://libguestfs.org
> 
> 

  reply	other threads:[~2020-05-29 22:21 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <alpine.LRH.2.11.1810131833150.18520@mx.ewheeler.net>
     [not found] ` <CAMRbyytcufK8-XdFu7LU+UwO_FRoGJO2FhhBHtH9etf3A2htwQ@mail.gmail.com>
     [not found]   ` <alpine.LRH.2.11.2005280014150.13970@mail.ewheeler.net>
     [not found]     ` <20200528090443.GN7304@redhat.com>
     [not found]       ` <alpine.LRH.2.11.2005282147410.13970@mail.ewheeler.net>
     [not found]         ` <20200529093744.GS3888@redhat.com>
2020-05-29 12:50           ` [Libguestfs] Provide NBD via Browser over Websockets Eric Blake
2020-05-29 13:50             ` Daniel P. Berrangé
2020-05-29 13:58               ` Eric Blake
2020-05-29 14:13                 ` Richard W.M. Jones
2020-05-29 21:08                   ` Eric Wheeler [this message]
2020-05-30  9:27                     ` Richard W.M. Jones
2020-06-01 20:04                       ` Eric Wheeler

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=alpine.LRH.2.11.2005292107180.10871@mail.ewheeler.net \
    --to=nbd@lists.ewheeler.net \
    --cc=berrange@redhat.com \
    --cc=libguestfs@redhat.com \
    --cc=nbd@other.debian.org \
    --cc=nsoffer@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rjones@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.