Hi, On Wed, Oct 19, 2016 at 06:42:08PM +0200, Daniel Jakots wrote: > The second sentence in the FAQ is 'It covers the latest release of > OpenBSD.'. Maybe it would be worth adding a sentence about the fact > that it covers mainly current (as in -stable vmm is not enabled).
Just to keep the list in the loop, here is the version of the vmm faq diff which I now have OKs for. We have decided however, to not commit this until 6.1 release. Thanks for all the feedback. Index: faq/faq6.html =================================================================== RCS file: /home/edd/cvsync/www/faq/faq6.html,v retrieving revision 1.419 diff -u -p -r1.419 faq6.html --- faq/faq6.html 8 Oct 2016 03:17:45 -0000 1.419 +++ faq/faq6.html 21 Oct 2016 15:22:13 -0000 @@ -50,6 +50,7 @@ <li><a href="#Bridge" >Setting up a network bridge</a> <li><a href="#Multipath" >Equal-cost multipath routing</a> <li><a href="#Replace" >Adding and replacing NICs</a> +<li><a href="#VMMnet" >Networking vmm(4) guests</a> </ul> <hr> @@ -1183,6 +1184,89 @@ Some likely candidates might include: <li>Bridge configuration (<tt>/etc/hostname.bridge*</tt>) <li>Trunk configuration (<tt>/etc/hostname.trunk*</tt>) </ul> + +<h2 id="VMMnet">Networking vmm(4) guests</h2> + +Giving network access to a <a href="http://man.openbsd.org/vmm";>vmm(4)</a> +guest is easy if the host machine uses a wired connection. +You can simply put the guest's <a href="http://man.openbsd.org/tap";>tap(4)</a> +interface into a bridged virtual switch with the host's wired interface. +Inside the guest, the <a href="http://man.openbsd.org/vio";>vio(4)</a> +interface can then be configured as if it were a real machine physically +connected to the host network. +Unfortunately, this strategy does not work if the host machine uses a wireless +network interface. +Due to a limitation of the IEEE 802.11 standard, wireless interfaces cannot +participate in network bridges. +One way to work around this is to give the guest VM its own network and use +network address translation (NAT) to the host's network. + +<p> +Suppose we have a host machine with network access via a wireless <tt>iwn0</tt> +interface on the <tt>192.168.1.0/24</tt> network. +We want to install an OpenBSD guest onto the <tt>10.0.0.0/24</tt> network and +give the guest access to the host's network via NAT. +Assume that we configured the guest's host-side interface to be fixed as +<tt>tap0</tt>. +Although we could set up NAT directly between the <tt>tap0</tt> and +<tt>iwn0</tt>, this tends to complicate matters, as <tt>tap0</tt> will appear +and disappear as the guest is powered up and down. +In that case, we would have to reconfigure <tt>tap0</tt> manually after each +guest power-on. +A more robust approach is to use an always-existing +<a href="http://man.openbsd.org/vether";>vether(4)</a> interface and +have <a href="http://man.openbsd.org/vmd";>vmd(8)</a> bridge this with +<tt>tap0</tt> when the guest is powered on. +Since <tt>vether0</tt> always exists regardless of whether the guest is powered +up or not, its configuration will persist across guest power cycles. + +<p> +Let's make a <tt>vether0</tt> interface: + +<blockquote><pre> +# <b>echo "inet 10.0.0.1 255.255.255.0" > /etc/hostname.vether0</b> +# <b>sh /etc/netstart vether0</b> +</pre></blockquote> + +Add the following to <tt>/etc/pf.conf</tt>: + +<blockquote><pre> +match out on iwn0 inet from vether0:network to any nat-to (iwn0) +</pre></blockquote> + +And to finish off the NAT configuration: + +<blockquote><pre> +# <b>pfctl -f /etc/pf.conf</b> +# <b>echo "net.inet.ip.forwarding=1" >> /etc/sysctl.conf</b> +# <b>sysctl net.inet.ip.forwarding=1</b> +net.inet.ip.forwarding: 0 -> 1 +</pre></blockquote> + +In <a href="http://man.openbsd.org/vm.conf";</a>vm.conf(5)</a>, ensure that you +put <tt>vether0</tt> into a virtual switch alongside <tt>tap0</tt>. +For example: + +<blockquote><pre> +switch "my_switch" { + add vether0 + interface bridge0 +} + +vm "my_vm" { + ... + interface tap0 { switch "my_switch" } +} +</pre></blockquote> + +Inside the guest, if we now assign <tt>vio0</tt> an address on the +<tt>10.0.0.0/24</tt> network and set the default route to <tt>10.0.0.1</tt>, we +should be able to ping systems on the host network. +For convenience, you may wish to set up a DHCP server on <tt>vether0</tt>. +See <a href="http://man.openbsd.org/dhcpd";>dhcpd(8)</a> and +<a href="http://man.openbsd.org/dhcpd.conf";>dhcpd.conf(5)</a> for details on +how to set up a DHCP server (an example config file can be found at +<tt>/etc/examples/dhcpd.conf</tt>). <p> </body> Index: faq/index.html =================================================================== RCS file: /home/edd/cvsync/www/faq/index.html,v retrieving revision 1.495 diff -u -p -r1.495 index.html --- faq/index.html 2 Oct 2016 21:16:26 -0000 1.495 +++ faq/index.html 20 Oct 2016 13:36:18 -0000 @@ -112,6 +112,7 @@ that are not covered in the FAQ. <li><a href="faq6.html#Bridge" >Setting up a network bridge</a> <li><a href="faq6.html#Multipath">Equal-cost multipath routing</a> <li><a href="faq6.html#Replace" >Adding and replacing NICs</a> +<li><a href="faq6.html#VMMnet" >Networking vmm(4) guests</a> </ul> <h3><a href="faq7.html">Keyboard and Display Controls</a></h3> -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
