Page MenuHomeFreeBSD

Add support to devel/libhyve-remote. (VNC Server)
AbandonedPublic

Authored by araujo on Jul 28 2017, 4:14 AM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Mar 18, 11:37 AM
Unknown Object (File)
Feb 21 2024, 3:56 AM
Unknown Object (File)
Feb 1 2024, 3:21 PM
Unknown Object (File)
Jan 12 2024, 4:41 PM
Unknown Object (File)
Dec 23 2023, 3:07 PM
Unknown Object (File)
Dec 20 2023, 2:48 AM
Unknown Object (File)
Dec 10 2023, 12:35 PM
Unknown Object (File)
Nov 6 2023, 10:12 AM

Details

Reviewers
tychon
jhb
jceel
gnn
bcr
rgrimes
Group Reviewers
manpages
bhyve
Summary

The libhyve-remote aims to abstract functionalities from other third party libraries such like libvncserver, freerdp and spice to be used in hypervisor implementation. With a basic data structure it is easy to implement any remote desktop protocol without dig into the protocol specification or third part libraries, you can check some of our examples.

We don't static link any third party library, instead we use dynamic linker and we load only functionalities that we believe is necessary to launch the service.

Our target is to abstract functionalities from libvncserver, freerdp and spice. Right now libhyve-remote only supports libvncserver. It is possible to launch a vnc server with different screen resolution as well as with authentication.

With this patch we implement support to bhyve use libhyve-remote that basically abstract some functionalities from libvncserver.
We can:

  • Enable wait state.
  • Enable authentication.
  • Enable different resolutions.
  • Have a better compression.

Also we add a new flag to be called with -s that is vncserver, if the libhyve-remote library is not present in the system we fallback to bhyve RFB implementation, ex.:
-s 2,fbuf,tcp=0.0.0.0:5937,w=800,h=600,password=1234567,vncserver,wait

Test Plan

Tested with (guests):

  • Windows10.
  • Fedora Workstation.
  • FreeBSD12.

Tested with VNC (clients):

  • RealVNC.
  • net/tigervnc.
  • net/tightvnc.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 10737
Build 11134: arc lint + arc unit

Event Timeline

araujo edited the test plan for this revision. (Show Details)
araujo added reviewers: grehan, tychon, jhb.
araujo edited the test plan for this revision. (Show Details)

Update manpage.

araujo retitled this revision from Add support to devel/libhyve-remote. to Add support to devel/libhyve-remote. (VNC Server).Jul 28 2017, 4:36 AM
This revision is now accepted and ready to land.Jul 28 2017, 8:38 AM

Small comment on the man page change.

usr.sbin/bhyve/bhyve.8
197

... provides a VNC server.
or
... provides the VNC server.

araujo edited edge metadata.

Address @bcr change request.

This revision now requires review to proceed.Jul 29 2017, 3:26 AM

OK from manpages. Thanks!

This revision is now accepted and ready to land.Jul 29 2017, 10:12 AM
grehan requested changes to this revision.Jul 29 2017, 6:29 PM

I'm looking at this now. I think there will need to be some changes in the mechanics for this, and also the abstraction. I'll write up something longer with more detail.

On naming - the term "vnc" was explicitly avoided in bhyve since much of the display code could be used with any remote protocol.

This revision now requires changes to proceed.Jul 29 2017, 6:29 PM

Some high-level comments:

  • the shared library interface is a bit fragile, since it searches for only symbol names and seems to imply a copy of an internal data structure (the vncserver_softc struct). A better approach would be something like bhyveload, where there is a single struct that contains a version and function pointers. That should be exported to a header file (along with any other structs used in the api) and go somewhere like <bhyve/extvnc.h> or similar.
  • the 'enable_http' function isn't used and maybe should be removed.
  • the frame-buffer differencing engine has been copy-pasted into vncserver.c. A better approach might be to make the existing rfb code an implementation of the function pointers, and allow an override to an external shared library on the command line (perhaps named to allow alternate ones). The differencing engine would then just call a function pointer, allowing a single copy of the code to be used.
  • the hard-coded path to the ports shared library should at the minimum be a #define, and better, extracted from the command line.

There are some unnecessary style changes that create additional extraneous diffs - these should be removed.

This revision is now accepted and ready to land.Feb 20 2019, 6:09 PM