---
categories: ['OpenBSD','System','Base']
date: 2021-02-21T19:54:31+01:00
description: "Tips to virtualize serenely under OpenBSD with vmd, where host and guest(s) are part of the same network!"
draft: false
tags: ["OpenBSD","vmd"]
title: "[OpenBSD :: Virtualization] Host and guests on the same network"
translationKey: "openbsd-vmd-host-guest-same-network"
---

## 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:

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

The result should be:

⇒ for Intel CPU: 

```ksh
vmm0 at mainbus0: VMX/EPT
```

⇒ for AMD CPU: 

```ksh
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.

{{< note info >}}
In relation with Meltdow and Spectre attacks, few Intel CPU are patched
to mitigate [L1TF](https://www.intel.fr/content/www/fr/fr/architecture-and-technology/l1tf.html).

On OpenBSD, these CPUs receive an appropriate patch. Sadly, this impact
the virtualization, make it impossible. 
{{</note>}}


## 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:
```ksh
$ 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: 

```ksh
$ vmctl create -s 50G disk.qcow2
```

⇒ Start the install: 

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

{{< note warning >}}
You need to declare a network interface, with the option `-i`. This allows
automatically one **[tap(4)](https://man.openbsd.org/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.*
{{</note>}}

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: `~~.`. 


{{<note 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!
{{</note>}}


## 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](https://www.fdn.fr/actions/dns/): 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)](https://man.openbsd.org/man4/em.4)** Intel firmware.

*Change segun your case, if necessary.*

Configue the `/etc/hostname.em0` file:

```cfg
inet 192.168.1.2
```

### vm.conf

`/etc/vm.conf` is the file configuration:

```cfg
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: 

```ksh
# 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

{{<note warning>}}
DO NOT use the [uRPF](https://www.openbsd.org/faq/pf/filter.html#urpf) 
feature with vm; otherwize yours VMs can not communicate!
{{</note>}}

According to the [notes of the bridge manpage](https://man.openbsd.org/bridge.4#NOTES), 
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**:

```cfg
pass on tap
```

{{<note info>}}
If you prefer to manage individually all interfaces **tap**, you can declare,
by exemple, only **tap0**:

`pass on tap0`
{{</note>}}

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

---

⇒ create a table to manage all the VMs:

```cfg
table <vm_tap> const { 192.168.1.3 192.168.1.4 }
```

and, for the exemple, authozise SSH to VMs:

```cfg
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](https://man.openbsd.org/vm.conf.5#SWITCH_CONFIGURATION)… 

And use [MAKEDEV(8)](https://man.openbsd.org/MAKEDEV.8), as:
```ksh
# sh MAKEDEV tap5
```

Egual, it's possible to assign such pseudo virtual device tap to such VM.
Use the keyword **[interface](https://man.openbsd.org/vm.conf.5#interface)**:

```cfg
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](https://man.openbsd.org/vmctl.8#LOCAL_INTERFACES)**:
> 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][1]** in order to understand the 
different informations needed. 

* It's highly interesting to read the manpages:
    * {{< man vmctl 8 >}}
    * {{< man vmd 8 >}}
    * {{< man "vm.conf" 5 >}}
    * {{< man vmm 4 >}}
    * sans oublier {{< man bridge 4 >}}    

---

* Here an [example](http://daemonforums.org/showthread.php?t=11628) of a 
patched L1TF Intel CPU where the boot media was not found, with error 
message in `dmesg`: <br>
`vmx_fault_page: uvm_fault returns 14, GPA=0xffffca78, rip=0xfbd49`

---

***Enjoy-IT! <br> Enjoy-ID!***

---

[1]: https://www.openbsd.org/faq/faq16.html