<div>Hi Ed,</div><div>   I am interesting to try this new feature.</div><div>Is there a demo of Virtual Media available now?</div><div>Best,</div><div>Xiuzhi</div><div>On 12/10/18 9:43 AM, Adriana Kobylak wrote:<br>> Hi Ed,<br>><br>>> ?- the nbd infrastructure allows us to use a unix domain socket (rather<br>>> ?? than a network socket) for that interface.<br>><br>>> ?- Using a websocket proxy, we can connect that process' stdio to a<br>>> ?? websocket.<br>><br>> As you pointed out, the Redfish schema for Virtual Media may not fit<br>> with this design, so wanted to get your thoughts on how/if we could<br>> somehow implement having the client request to mount the device via a<br>> websocket, like by calling the VirtualMedia/<device_id> api, or could<br>> we leverage some other schemas, or what would be your suggestion? Thanks!<br>><br>> Reference:<br>> https://gerrit.openbmc-project.xyz/#/c/openbmc/bmcweb/+/16481/<br>> https://gerrit.openbmc-project.xyz/#/c/openbmc/phosphor-rest-server/+/14752/<br>><br>><br>I think the root of the issue here is that the Virtual Media Redfish<br>interface was designed to be able to mount a host from a network share,<br>rather than proxying over a websocket.? I think in the long term, if<br>we're going to support all the use cases we want to, we will eventually<br>need both mechanisms, but for the moment, if we want to get something<br>that works up quickly, and iterate, we're probably better off just<br>continuing to make the websocket implementation work reliably.? In my<br>head (i.e. I haven't backed this up with actual data) I see websocket as<br>one implementation of a transport layer, with other transport layers<br>(samba, NFS, ect) that could be supported at a later date.<br><br>I suspect the best approach here is to simply add a url handler under<br>the existing name (/kvmws0) that does the websocket.? When and if<br>someone goes to build out the Redfish interface for Virtual Media, we<br>can go implement the redfish specific urls.? If you'd prefer to do it in<br>the reverse order, that would work as well.<br><br>-Ed<br><br><br><br>End of openbmc Digest, Vol 40, Issue 35<br>***************************************<br></div>