[jjstorm]

Originally Posted by jggimi

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.

Very interesting. I plan on using my virtual environment in similar ways.