[OpenBSD :: Virtualization] Host and guests on the same network

Article published the21 February 2021 ; modified the16 November 2023
5 minutes to read

This article has 903 words.
RAW source of the article:
Commit version: f445092

Description

To virtualize on OpenBSD, since 5.9, is easy; you need to pay attention to certains details.

This article is about to virtualize host and guests on same network.

Version : native
OS : OpenBSD 6.4 → 6.9

Prerequisites

First, check if the machine is CPU compliant:

$ dmesg | egrep '(VMX/EPT|SVM/RVI)'

The result should be:

⇒ for Intel CPU:

vmm0 at mainbus0: VMX/EPT

⇒ for AMD CPU:

vmm0 at mainbus0: SVM/RVI

If the system returns no result, then the virtualization is not possible, never. Just in case, check on your BIOS|UEFI, and see if the option is disabled.

Info

In relation with Meltdow and Spectre attacks, few Intel CPU are patched to mitigate L1TF.

On OpenBSD, these CPUs receive an appropriate patch. Sadly, this impact the virtualization, make it impossible.

Creation

After downloading the ultime instalXX.iso, and checking it…

Why using, preferably, the iso image? To install OpenBSD by option cd, because the install sets are on.

For instance, with the 6.9 release:

$ ftp https://cdn.openbsd.org/pub/OpenBSD/6.9/amd64/{install69.iso,SHA256,SHA256.sig}
$ sha256 -C SHA256 install69.iso
(SHA256) install69.iso: OK
$ signify -Cp /etc/signify/openbsd-69-base.pub -x SHA256.sig install69.iso
Signature Verified
install69.iso: OK

⇒ Create the VM:

$ vmctl create -s 50G disk.qcow2

⇒ Start the install:

# vmctl start -c -m 1G -i 1 -r installXX.iso -d disk.qcow2 test

Warning

You need to declare a network interface, with the option -i. This allows automatically one tap(4) interface to the VM.

Egual, do not use the option -L to manage host and guests on same network; this option declare a local interface, preventing communication with the bridge. In this cas, we need to configure forwarding, sysctl, etc.

Do the install, and after a few minutes, at the end, choose [halt] to shutdown correctly the OS into the VM. To leave the serial console, use the escape sequence : ~.; or if you are on SSH session: ~~..

Info

Another reason why you need to stop the VM: if you do not, the VM reboot normally, without any problem… but, without network connections. Do not try to modify yours networks parameters, perhaps just to verify adresses IP gateway and DNS resolver.

The tip: configure the file /etc/vm.conf on the host, restart the vmd daemon et after start the VM. Now, the network should work correctly!

Configuration

Assuming that:

the network segment is on Class C, as 192.168.1.0
address IP of gateway: 192.168.1.1
DNS resolvers: perhaps those about FDN…

These informations are the network parameters to configure the VM.

The following parameters are made on:

Networking

Only the Ethernet devices, not Wireless, can be used.

Prefer to use static adress IP, because dhcp can complicate matters.

hostname.iface

In this article, we assume that your network interface is managed by the em(4) Intel firmware.

Change segun your case, if necessary.

Configue the /etc/hostname.em0 file:

inet 192.168.1.2

vm.conf

/etc/vm.conf is the file configuration:

switch "sw" {
    interface bridge0
}

vm "test" {    
    disk /home/your_user/disk.qcow2 format qcow2
    enable
    memory 1G
    interface { switch "sw" }
    owner your_user
}

Bridge

Configure the bridge to manage em0:

# echo 'add em0' > /etc/hostname.bridge0
# sh /etc/netstart bridge0

Voilà!

Which is not mentioned in the FAQ, has a lot to do with PF, mainly.

Another important information: when the VM is running, on tap interface is created and mounted by the bridge.

PF

Warning

DO NOT use the uRPF feature with vm; otherwize yours VMs can not communicate!

According to the notes of the bridge manpage, set the rules on PF to manage the bridge is possible, but you need to be very fine-tuned and have an excellent understanding about the network flow within PF.

Do simple:

⇒ pass all on the interface group tap:

pass on tap

Info

If you prefer to manage individually all interfaces tap, you can declare, by exemple, only tap0:

pass on tap0

Now, you need to manage the physical network interface; here: em0

⇒ create a table to manage all the VMs:

table <vm_tap> const { 192.168.1.3 192.168.1.4 }

and, for the exemple, authozise SSH to VMs:

pass in log on em0 inet proto tcp from any to <vm_tab> port 22

Of course, these PF rules are minimalist. It’s up to you!

Finally, remember to manage PF rules within the VM.

tap - Ethernet tunnel pseudo-device

OpenBSD create 4 tap interfaces, by default. If you need more VM, you need to create more tap interfaces.

See the note…

And use MAKEDEV(8), as:

# sh MAKEDEV tap5

Egual, it’s possible to assign such pseudo virtual device tap to such VM. Use the keyword interface:

vm "test" { 
    (…)
    interface tap5 { … }
    (…)
}

Another information to understand: as long as the VM is not active, the matching tap interface will not be created and mounted on the bridge. Compare with ifconfig command, before and after. ;-)

sysctl

NO, it’s not necessary to configure systcl to forward the trafic. We do not make NAT!

See the manpage vmctl:

If NAT is desired, the net.inet.ip.forwarding sysctl(8) must also be set to 1.

So, in the bridge context where host and guests are on same network, no need to forward the flow.

Documentations

See the official FAQ Virtualisation in order to understand the different informations needed.
It’s highly interesting to read the manpages:
- vmctl(8)
- vmd(8)
- vm.conf(5)
- vmm(4)
- sans oublier bridge(4)

Here an example of a patched L1TF Intel CPU where the boot media was not found, with error message in dmesg: vmx_fault_page: uvm_fault returns 14, GPA=0xffffca78, rip=0xfbd49

Enjoy-IT! Enjoy-ID!