All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: "Richard W.M. Jones" <rjones@redhat.com>,
	Eric Wheeler <nbd@lists.ewheeler.net>
Cc: "Nir Soffer" <nsoffer@redhat.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	QEMU <qemu-devel@nongnu.org>, libguestfs <libguestfs@redhat.com>,
	nbd@other.debian.org
Subject: Re: [Libguestfs] Provide NBD via Browser over Websockets
Date: Fri, 29 May 2020 07:50:14 -0500	[thread overview]
Message-ID: <13571029-5bf4-2dfa-6879-0ad2642afb3f@redhat.com> (raw)
In-Reply-To: <20200529093744.GS3888@redhat.com>

[adding qemu list]

On 5/29/20 4:37 AM, Richard W.M. Jones wrote:
> Going back to the original email from 2018:
> 
>> It might be neat to attach ISOs to KVM guests via websockets.  Basically
>> the  browser would be the NBD "server" and an NBD client would run on the
>> hypervisor, then use `virsh change-media vm1 hdc --insert /dev/nbd0` could
>> use an ISO from my desk to boot from.
>>
>> Here's an HTML5 open file example:
>> https://stackoverflow.com/questions/3582671/how-to-open-a-local-disk-file-with-javascript
>>
>> and the NBD protocol looks simple enough to implement in javascript:
>> https://stackoverflow.com/questions/17295140/where-is-the-network-block-device-format-describled
> 
> So I think what you mean here is that in a browser you'd open a local
> (eg) ISO, and then that ISO could be shared with a remote VM.  The
> browser runs a Javascript NBD server.  The remote VM is qemu.  Between
> the two is a WebSocket.
> 
> I've seen this being done with an HP blade server of some kind and
> IIRC the client side used a Java applet.  No idea what the protocol
> was but likely something proprietary.  It was nevertheless a useful
> feature, eg to boot the server from an install CD that you have
> locally.
> 
> I guess the problem is two-fold:
> 
> (1) You need to write an NBD server in Javascript.  Not especially
> difficult, particularly if you avoid any complicated features, and I
> guess you only need read support.

Or use an existing NBD server over a Unix socket paired to a WebSocket 
proxy that forwards all traffic from the Unix socket over a WebSocket. 
That may be easier than writing the NBD server itself in Javascript.

> 
> (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.

> 
> ...
> 
>> When qemu is running headless using a VNC or Spice display we can access
>> the display of https+websockets using things like noVNC---which is out of
>> scope to this converstation---but I'm just saying that such an existing
>> web front-end for the display could be extended to have an "Insert CDROM"
>> button and use the javascript file IO for the user to reference a local
>> file and pass it to qemu over nbd, perhaps via nbdkit.
> 
> I'm not sure how nbdkit would be involved, unless it was compiled
> to WASM or something like that.
> 
> But the plan above sounds feasible, albeit a chunk of work.
> 
> Rich.
> 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org



       reply	other threads:[~2020-05-29 12:51 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           ` Eric Blake [this message]
2020-05-29 13:50             ` [Libguestfs] Provide NBD via Browser over Websockets 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
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=13571029-5bf4-2dfa-6879-0ad2642afb3f@redhat.com \
    --to=eblake@redhat.com \
    --cc=berrange@redhat.com \
    --cc=libguestfs@redhat.com \
    --cc=nbd@lists.ewheeler.net \
    --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.