OpenBSD in KVM, remotely

I needed an OpenBSD virtual machine to test various things for a client install (and port various software). After a bit of thought I concluded it would be most convenient if it were located on my hosted server, which runs KVM (after the conversion from Xen to KVM last year, rather than simply setting up a VMWare Fusion instance on my laptop. (Amongst other things, my hosted server had more spare disk space than the total disk space on my laptop...)

My hosted server is, well, hosted, and thus remote. It was installed without a graphical console, and all the other KVM virtual machines are running using serial console (to a pty), which Linux supports via kernel command line arguments -- making for an easier install process. However getting OpenBSD to use a serial console during install requires editing the CD image, which requires an OpenBSD system in the first place -- catch 22 (and they'd only got pre-edited CD images through a year old version of OpenBSD).

Thus at least to install the OpenBSD virtual machine under KVM, I needed a way of remotely getting at a video console for it (even if it was just displaying text mode on an emulated VGA card). (After the install I could use it via ssh, and/or configure the OpenBSD install for serial console which is fairly easily done when you can write to the boot media.) The most convenient option seemed to be a VNC remote console, since I could reach that via a ssh port forward on the ssh login into my hosted server.

Set up is (all square brackets replaced by XML angle brackets in config files):

Add a graphics and video section to the libvirt KVM device configuration:
```
[input type='mouse' bus='ps2'/]
[graphics type='vnc' port='-1' autoport='yes' listen='127.0.0.1'/]
[video]
  [model type='cirrus' vram='9216' heads='1'/]
[/video]
```
(You could, and I did, specify an explicit port and set autoport='no', or just let it auto-assign them starting at 5900. You could presumably also specify an IP other than 127.0.0.1, if you were in an environment where you could safely expose the console to local/remote networks.)
Set up a ssh port forward for the console port (eg, 5900):
```
ssh -L 5900:localhost:5900 HOSTED-SERVER
```
Start virtual machine
Connect VNC viewer to the remote console:
```
vncviewer localhost:5900
```
(or whatever the port was on the local end of the port forward.)

And thus you have an encrypted path to the console of the remote machine. It works basically as well as any other "remote KVM" solution (including the one built into my host machine).

The install was done from a copy of the ISO image of the OpenBSD boot CD (cd48.iso), saved onto the file system of the host machine (plus the network, since there was an unofficial mirror of OpenBSD very nearby; the install48.iso CD image could be used instead if there isn't). There were a couple of small niggles:

OpenBSD doesn't play nicely with the default KVM emulated NIC, a RealTek 8139, and/or the emulation is insufficiently accurate, so it was necessary to specify another NIC type to emulate. (The symptoms are very poor network performance, and many reports of "re0: watchdog timeout".) I choose "e1000" both because I found it suggested, and because conveniently it happens to be one of the NIC types that will be in the final hardware onto which this work will be installed. To change the NIC type emulated, add:
```
[model type='e1000'/]
```
to the interface section of the drivers.
I found that I couldn't get OpenBSD to boot from the CDROM with SCSI bus attachment for the ISO file (as I use with Linux).
It worked better when the emulated devices were IDE. (Presumably I could have found a SCSI controller type to emulate which would have worked, but given the low usage IDE is fine.) To do this, in the disk section, specify, eg:
```
[disk type='block' device='disk']
    [....]
    [target dev='hda' bus='ide'/]
    [....]
[disk type='file' device='cdrom']
    [....]
    [target dev='hdc' bus='ide'/]
```
for the hard drive and CDROM respectively. And then it operates like a traditional 1990s PC (one disk per IDE channel, as master, with the hard drive on the primary and the CDROM on the secondary controller).

The final thing to resolve was the boot order, which can be specified in the "os" section. The easiest option seemed to be to simulate the traditional BIOS search order, and just change it around as required in the config. So for the original install:

[boot dev='cdrom'/]
[boot dev='hd'/]

and then once the install was complete:

[boot dev='hd'/]
[boot dev='cdrom'/]

which seemed to work fine.

Apart from those niggles, the install worked just like any other OpenBSD install, and one could assume that it was just a remote console on physical hardware. I installed the base, development tools, and manual but omitted the games and X11 portions.

After the install it was useful to enable installing packages, and install the bash shell and make that the shell for my account (many years of bits of shell environment work better that way):

Add to ~/.profile:

PKG_PATH="ftp://ftp.citylink.co.nz/pub/OpenBSD/`uname -r`/packages/`machine -a`"
export PKG_PATH

Update environment from profile:
```
cd
. .profile
```

Install package and change shell

sudo pkg_add -v bash-4.1.7p0
chsh -s /usr/local/bin/bash

Then log out/log in again to start using the new shell.

(I installed the AMD64 version of OpenBSD, but I believe the same config should work with an i686 install too. You should pick your nearest mirror of OpenBSD to fetch packages from, for speed; or even choose the CD.)

Full KVM config attached.