On Mon, Jul 03, 2017 at 02:36:20PM -0400, J Doe wrote: > > >> On 27 Jun 2017 10:45 am, "Stuart Henderson" <s...@spacehopper.org> wrote: > >> > >>> On 2017-06-26, Josh Stephens <bsd...@gmail.com> wrote: > >>> I could be wrong when I say this but the only gotcha that you will run > >> into > >>> with virtual box will be the guest additions. > >> > >> Does virtualbox still do that thing where it patches the running > >> kernel when it detects OpenBSD? > > Hi, > > > Just thought I'd chime in that I've had success with OpenBSD 5.x to > 6.0 running under VMware Fusion (Mac OS X version of VMware). There > isn't support for guest additions with the most recent version of > Fusion (8.x), but I haven't had any issues. >
I don't know what you mean with "there isn't support for guest additions". We don't support VMware's 3rd party tools but we use our own drivers. VMware Fusion Pro 8.5.8 with version 12 VMs works fine, vmt(4) attaches, provides guest services such as shutdown/reboot, timedelta sensor, and access to VMware's guestinfo key/value via hostctl(8) (eg. hostctl guestinfo.ip). X11-related features are provide by vmwh in ports, but I've never tested it. We also have vmx(4) for vmxnet3 networking but you manually have to edit the .vmx file and change ethernetX.virtualDev = "vmxnet3" (VMware has ignored all of our requests to add a device profile for OpenBSD). The only issue that I just saw with -current is that ahci(4) initialization hangs on boot - I had to disable ahci and use SCSI or IDE. I haven't noticed this on ESXi. I mostly used Fusion for testing and development for ESXi/vSphere but I switched to OpenBSD VMM for most of the testing. > I saw in the thread that someone was mentioning full screen support. > There's no problem with that under Fusion, but you are limited to > legacy style video output (ie: not a high res display). The easiest > way around that is I run OpenBSD minimized and SSH in from Terminal on > Mac OS X, then use the full-screen mode on OS X Terminal. > > If you're interested in OpenBSD in virtual machines in the cloud, I > have nothing but praise for the people at RootBSD [1], which have > supported OpenBSD for a while. IIRC they run OpenBSD on top of Xen, > so the previous comments about security not being the same as running > it natively do apply, but it's definitely an option. > > I believe Undeadly recently posted about partial support for Hyper-V > has been committed, which also opens up the future possibly of running > OpenBSD on Azure. Seems like the only holdout is AWS, but there is > now official support for FreeBSD on it, so here's hoping its' more > secure cousin will make it's way to Amazon. You cannot really compare FreeBSD in Azure or AWS to OpenBSD. We have totally different drivers for Hyper-V and Xen. But Hyper-V is "fully" supported on OpenBSD, the latest hvs(4) driver adds support for StorVSC paravirtual SCSI. mikeb@ has done some great work to implement all the missing drivers and I helped where I could and focussed on the part to get it from Hyper-V/Xen to the "cloud". The situation in Azure is about the same as in AWS: we don't provide OpenBSD images in the marketplaces or community images yet, but there are scripts and howtos to create your OpenBSD VMs in Azure. This might change as soon as we feel confident enough with the VM "layout" and the (mandatory) agent. But, for now, use the tools from unofficial external github projects: For AWS: https://github.com/ajacoutot/aws-openbsd For Azure (also works in AWS and under VMM): https://github.com/reyk/cloud-openbsd (create images with cloud-agent) https://github.com/reyk/cloud-agent (an alternative to waagent in ports) https://github.com/reyk/meta-data (test + boot cloud images under VMM) We also have VirtIO drivers for OpenBSD VMM and KVM, as used by most other clouds, and I'm planning to add support for OpenStack (JSON) and OpenNebula (contexts) to my cloud-agent. But please note that we're currently trying to find ways to create VM images that still provide the benefits of OpenBSD-style things like KARL. The problem with pre-provisioned VM images is that they all have the "same random values" in the filesystem, kernel, and libraries where the installer usually makes each installation unique. A pre-provisioned image is always the same, at least on first boot, unless we create something that prepares or installs everything before getting a new VM instance online. The first real* OpenBSD image on Azure will probably be fully pre-provisioned, but maybe we switch to a totally different model later. In summary, I think all x86 VM hypervisors are more or less supported. Just like real hardware platforms, some of them have problems, and others work better. But we're in a pretty good shape and it was an interesting journey over the last years to get to this point. *) There is currently only my company's OpenBSD-based product in Azure. Some PR got it wrong and announced that OpenBSD itself is now available in Azure, but it is an appliance which is not plain OpenBSD. I'm sorry for the unintended confusion. The reality is: OpenBSD is now supported in Azure, you can create your own images for it, and we're hoping to make real OpenBSD images available very soon. Reyk
