Virtual Media

Ed Tanous ed.tanous at intel.com
Tue Dec 11 06:13:29 AEDT 2018


On 12/10/18 9:43 AM, Adriana Kobylak wrote:
> Hi Ed,
>
>>  - the nbd infrastructure allows us to use a unix domain socket (rather
>>    than a network socket) for that interface.
>
>>  - Using a websocket proxy, we can connect that process' stdio to a
>>    websocket.
>
> As you pointed out, the Redfish schema for Virtual Media may not fit
> with this design, so wanted to get your thoughts on how/if we could
> somehow implement having the client request to mount the device via a
> websocket, like by calling the VirtualMedia/<device_id> api, or could
> we leverage some other schemas, or what would be your suggestion? Thanks!
>
> Reference:
> https://gerrit.openbmc-project.xyz/#/c/openbmc/bmcweb/+/16481/
> https://gerrit.openbmc-project.xyz/#/c/openbmc/phosphor-rest-server/+/14752/
>
>
I think the root of the issue here is that the Virtual Media Redfish
interface was designed to be able to mount a host from a network share,
rather than proxying over a websocket.  I think in the long term, if
we're going to support all the use cases we want to, we will eventually
need both mechanisms, but for the moment, if we want to get something
that works up quickly, and iterate, we're probably better off just
continuing to make the websocket implementation work reliably.  In my
head (i.e. I haven't backed this up with actual data) I see websocket as
one implementation of a transport layer, with other transport layers
(samba, NFS, ect) that could be supported at a later date.

I suspect the best approach here is to simply add a url handler under
the existing name (/kvmws0) that does the websocket.  When and if
someone goes to build out the Redfish interface for Virtual Media, we
can go implement the redfish specific urls.  If you'd prefer to do it in
the reverse order, that would work as well.

-Ed



More information about the openbmc mailing list