View Single Post
  #4   (View Single Post)  
Old 11th November 2014
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,984
Default

Whenever I want to experiment with some new (to me) feature or function in OpenBSD, I always start with testing/learning in a virtual machine-based laboratory environment before provisioning the solution in production.

I use QEMU virtual machines, as my host environment is also OpenBSD. For network solutions testing, I interconnect virtual machines with QEMU's multicast sockets.

Edited to add:
---------------

In the last 18 months I've used this to design solutions with carp(4), pflow(4), gif(4), and iked(8) that I then deployed in production. I've also used this to design information infrastructures for large server farms, And, over the years I've also used the same "lab" to try to recreate problems people have reported here, in an effort to assist with problem determination and possible solutions.

Virtual machines are rarely functional hardware tests, because there is always a software layer between the host and guests. Only when that layer is the hardware's own microcode could you consider the hardware directly involved. If there is a host OS or a hypervisor, then the guest is divorced from the hardware. We could argue how large a separation that is, but there is still a separation from the hardware.

Last edited by jggimi; 11th November 2014 at 03:11 PM.
Reply With Quote