Bare Metal VS Vertualization

[Flipper99]

I do not have the money or space to have multipole bare metal instances. Here in lies my main question. Does Virtualizing my instance of OpenBSD? Less of a contributing member of the userbase?

[yeti]

No.

[J65nko]

In 2014 I wrote a guide how to create OpenBSD Virtual Machines on a Linux box using KVM.
See Create OpenBSD guest for Linux KVM (Kernel-based Virtual Machine) with 'virt-install'
With KVM you can run X Window in a VM. This is something that you cannot do yet using OpenBSDs native VMs

[Entropic]

This thread is interesting for anyone like me who is looking for a means of operating within the security of OpenBSD but also adding the ability to do Zoom or Widevine dependent streaming (Netflix/Prime etc.) via say a Linux guest OS.

In other words I'd be looking to do the reverse of what you J65nko have explained in your article What hypervisor would I need to run in OpenBSD to get a Linux distro up and running so as to Zoom and Stream whilst still protected (at base level) by OpenBSD?

[jggimi]

There is only one hypervisor in OpenBSD: vmm(4). The FAQ has a virtualization chapter discussing it: http://www.openbsd.org/faq/faq16.html. Please take careful note: this hypervisor does not have a virtual graphics card, guests must use virtual serial consoles. Graphical applications are only available via network connections (X11 forwarding, VNC, etc.)

[Entropic]

Originally Posted by jggimi

There is only one hypervisor in OpenBSD: vmm(4). The FAQ has a virtualization chapter discussing it: http://www.openbsd.org/faq/faq16.html. Please take careful note: this hypervisor does not have a virtual graphics card, guests must use virtual serial consoles. Graphical applications are only available via network connections (X11 forwarding, VNC, etc.)

Thanks for the reply jggimi. I've been trawling through much of this forums past discussions trying to find noob useful posts that can augment my basic knowledge, and have seen your helpful replies so I'm glad of your input.

Now regarding the link, I've taken a look at it to understand the implications and I'm still unclear as its written with a higher level of tech speak than I'm used to. Can you help me understand it?
The gist of what I'm getting is that I can't expect to run a Linux guest that will output the streaming content to the graphics cards (and thus screen) of my laptop. That to have any hope of outputting this kind of content I'll need it sent to another device over a network connection using X11 forwarding or VNC? How then do OpenBSD hosts even see the console or GUI of their Linux guests (whilst operating within them), if they can't output their processes to the screen for interaction purposes? This is rather puzzling...

EDIT: I've just found this interesting thread regarding a similar concern (getting Netflix/Prime etc. to stream on a non dual booting OpenBSD system) Would running this Linux "Void" distro get around the issue? What about the suggestion of having a USB only linux "live" option per the second last reply starting "LIFEHACK". Is it easy to encrypt the HDD in OpenBSD as that poster suggests as a means of protecting the main OpenBSD host installation?

[jggimi]

There are two parts to your question, which I'll try to answer briefly below. Note that you've inadvertently "hijacked" the original thread from Flipper99, so I expect one of our mods to split this discussion off into its own thread, soon, to help keep forum discussions organized.

A. Graphics and consoles.

The "console" is where the operator can input operational commands and/or see operational messages. For Unix-like systems, this isn't graphical in nature and console messages typically begin appearing long before a graphical subsystem (X11, Wayland) even gets started. For OpenBSD, the console shows bootloader messages, offers the operator interaction with with the bootloader, outputs the system message buffer during boot, and shows the output from rc(8) during a standard multi-user boot.

The vmm(4) hypervisor offers only one type of console. A virtual serial connection.

To my understanding, there are three ways for a guest OS that has no graphics card and only a serial console can communicate "graphically" and provide graphics output to the host (or, over a network, to some other host):

1. The guest can operate a web server and provide all graphics and multimedia via HTML.
2. The guest can operate a VNC server and provide X11 graphics output to a VNC client. This is usually more efficient than option 3 below, but more work to provision.
3. The guest can provide X11 output directly over the network. This is usually done via ssh X11 forwarding to mitigate the security implications of X11 networking. Why? X11 graphics were historically designed to be transmitted over a network, from a central multi-user computer to multiple graphical "X terminals". (See https://en.wikipedia.org/wiki/X_terminal for more.) This predated modern security considerations. This network-capable feature of X11 is disabled and unavailable in OpenBSD's X11 Display Manager xenodm(1), and also blocked by recommendation via the default pf.conf(5) configuration. We enable X11 forwarding in SSH instead.

B. What they're talking about in that link.

The discussion there appears to me to be mostly about dual booting, not running multiple OSes simultaneously.

[Entropic]

Originally Posted by jggimi

There are two parts to your question, which I'll try to answer briefly below. Note that you've inadvertently "hijacked" the original thread from Flipper99, so I expect one of our mods to split this discussion off into its own thread, soon, to help keep forum discussions organized.

Quite right and my apologies to Flipper99 if this concerns them in any way. I'm not averse to it being separated into another thread either way. With it now being two months since there was any activity in the thread Flipper might even be glad his thread has been 'reactivated' albeit in a slightly different vein .0

A. Graphics and consoles.

The "console" is where the operator can input operational commands and/or see operational messages. For Unix-like systems, this isn't graphical in nature and console messages typically begin appearing long before a graphical subsystem (X11, Wayland) even gets started. For OpenBSD, the console shows bootloader messages, offers the operator interaction with with the bootloader, outputs the system message buffer during boot, and shows the output from rc(8) during a standard multi-user boot.

So in simplified terms, I'm getting that in the same way the old DOS environment I used as a kid (before WIN 3.11) used a console for doing everything, OpenBSD has an equivalent console for doing everything? Yes I already knew this and it doesn't perturb me much (yet).

The vmm(4) hypervisor offers only one type of console. A virtual serial connection.

To my understanding, there are three ways for a guest OS that has no graphics card and only a serial console can communicate "graphically" and provide graphics output to the host (or, over a network, to some other host):

1. The guest can operate a web server and provide all graphics and multimedia via HTML.
2. The guest can operate a VNC server and provide X11 graphics output to a VNC client. This is usually more efficient than option 3 below, but more work to provision.
3. The guest can provide X11 output directly over the network. This is usually done via ssh X11 forwarding to mitigate the security implications of X11 networking. Why? X11 graphics were historically designed to be transmitted over a network, from a central multi-user computer to multiple graphical "X terminals". (See https://en.wikipedia.org/wiki/X_terminal for more.) This predated modern security considerations. This network-capable feature of X11 is disabled and unavailable in OpenBSD's X11 Display Manager xenodm(1), and also blocked by recommendation via the default pf.conf(5) configuration. We enable X11 forwarding in SSH instead.

Option 1 sounds horrendously difficult for someone like me whose never created a web server. HTML5 sounds familiar as the means by which we watch youtube content in browsers, but thats where the browser is doing all the hard work translating it into a graphical format that I can enjoy on screen. Its going to be hard enough for me doing the basics in OpenBSD yet alone building something that I've previously taken for granted within a web browser system.

Option 2 sounds like the most viable option mainly because option 3 seems to imply creating security holes which is exactly why I'm moving to OpenBSD (to avoid these holes). So the next question is, if I'm looking to watch the streamed content (Say an SD Netflix stream) on an M2 macbook receiving its feed from the OpenBSD machine running on a 10 year old x86 laptop (i5) running the VNC server in this context, would it have a normal frame rate or just be unfeasibly slow?

[jggimi]

Consoles:

Consider, if you will, the time in history before the advent of personal computers. Before DOS. The time in history when Unix was first developed and deployed.

A single central computer running Unix would typically have multiple users sitting at a network of devices called computer terminals -- initially paper teletype machines with keyboards, then later CRTs and keyboards, and finally, graphical X terminals with mice -- each connected to the central computer, sharing its resources simultaneously. This technology was known as "time sharing".

The people who used those terminals were "users" and they each logged in with their own individual "userid" and the terminals might be across a building or across a campus. One terminal device would be physically a part of the central computer, for its human "operator" to use. This central single terminal used by its operator was the computer's console. A single large mainframe computer might have had hundreds of simultaneously connected users, and thousands of individual users with their own userid accounts. But it would had a single console for the operator.

Graphics:

The easiest mechanism to provision is X11 Forwarding.

1. The guest OS runs the SSH server sshd(8), with "X11Forwarding yes" provisioned in its sshd_config(5) file. If the guest is OpenBSD, sshd(8) is enabled and running by default, and only one change is needed to the config file to enable X11 forwarding.
2. The user on the host (or on another system elsewhere, if the guest is on a real network) connects to the guest OS with the ssh(1) client, using the -X or -Y option to enable an SSH session with X11 forwarding. This provides a shell on the guest with the correct $DISPLAY environment variable set.
3. The user then runs the requested graphical X application from that shell. The graphics will be tunneled through SSH securely back for display, while mouse movements, clicks, and keyboard entries will be sent back to the guest OS for processing.