Hi, On Mon, Oct 17, 2016 at 05:28:38PM +0100, Edd Barrett wrote: > Thanks. The general consensus was to try to reduce this a lot before > commit though. I will probably only include the wireless setup in the > FAQ.
Here is the reduced version. I also moved this into the networking section. Better? OK? 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 19 Oct 2016 15:56:20 -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,96 @@ 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> + +<p> +Giving a <a href="http://man.openbsd.org/vmm";><tt>vmm(4)</tt></a> guest network +access is easy if the host machine uses a wired network interface: you can then +simply put the guest's <a href="http://man.openbsd.org/tap";><tt>tap(4)</tt></a> +interface into a bridged virtual switch with the host's wired interface. +Inside the guest, the <a href="http://man.openbsd.org/vio";><tt>vio(4)</tt></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 has a wireless +network interface. +Due to a limitation of the IEEE 802.11 standard, wireless interfaces can not +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 that 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, and that we +want to install an OpenBSD guest onto a the <tt>192.168.10.0/24</tt> network and +give the guest access to the host's network via a 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. +This would mean that we would have to reconfigure the address of <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";<tt>vether(4)</tt></a> interface and +have <a href="http://man.openbsd.org/vmd";<tt>vmd(8)</tt></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: + +<pre><blockquote> +# echo "inet 192.168.10.1 255.255.255.0" > /etc/hostname.vether0 +# sh /etc/netstart vether0 +</pre></blockquote> + +<p> +We need to add a <a href="http://man.openbsd.org/pf";<tt>pf(4)</tt></a> rule to +do the NATting. +Put in the correct place in <tt>/etc/pf.conf</tt>: + +<pre><blockquote> +match out on iwn0 inet from vether0:network to any nat-to (iwn0) +</pre></blockquote> + +<p> +And to finish off the NAT configuration: + +<pre><blockquote> +# pfctl -f /etc/pf.conf +# echo "net.inet.ip.forwarding=1" >> /etc/sysctl.conf +# sysctl net.inet.ip.forwarding=1 +net.inet.ip.forwarding: 0 -> 1 +</pre></blockquote> + +<p> +In +<a href="http://man.openbsd.org/vm.conf";</a><tt>vm.conf(5)</tt></a>, ensure +that you put <tt>vether0</tt> into a virtual switch alongside <tt>tap0</tt>. +For example: + +<pre><blockquote> +switch "my_switch" { + add vether0 + interface bridge0 +} + +vm "my_vm" { + ... + interface tap0 { switch "my_switch" } +} +</pre></blockquote> + +<p> +Inside the guest if we now assign <tt>vio0</tt> an address on the +<tt>192.168.10.0/24</tt> network, and set the default route to +<tt>192.168.10.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";</a><tt>dhcpd(8)</tt></a> and +<a href="http://man.openbsd.org/dhcpd.conf";</a><tt>dhcpd(5)</tt></a> for +details on how to set up a DHCP server. <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 19 Oct 2016 16:07:59 -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
