In this post, we’ll walk through the process of getting virtual machines on two different hosts to communicate over an overlay network created using the support for VXLAN in Open vSwitch (or OVS). The test environment For this post, I’ll be working with two systems: node0.ovs.virt at address 192.168.122.107 node1.ovs.virt at address 192.168.122.174 These hosts are running CentOS 8, although once we get past the package installs the instructions will be similar for other distributions.

This is part of a series of posts about my experience working with OpenShift and CNV. In this post, I’ll look at how the recently released CNV 2.4 resolves some issues in managing virtual machines that are attached directly to local layer 2 networks In an earlier post, I discussed some issues around the management of virtual machine MAC addresses in CNV 2.3: in particular, that virtual machines are assigned a random MAC address not just at creation time but every time they boot.

Have you ever wished that you could use libvirt domain names as hostnames? So that you could do something like this: $ virt-install -n anewhost … $ ssh clouduser@anewhost Since this is something that would certainly make my life convenient, I put together a small script called virt-hosts that makes this possible. You can find virt-hosts in my virt-utils GitHub repository: https://raw.github.com/larsks/virt-utils/master/virt-hosts Run by itself, with no options, virt-hosts will scan through your running domains for interfaces on the libvirt default network, look up those MAC addresses up in the corresponding default.

A recent update to Arch Linux replaced the qemu-kvm package with an updated version of qemu. A side effect of this change is that the qemu-kvm binary is no longer available, and any libvirt guests on your system utilizing that binary will no longer operate. As is typical with Arch, there is no announcement about this incompatible change, and queries to #archlinux will be met with the knowledge, grace and decorum you would expect of that channel:

Occasionally we will deploy a virtual instance into our KVM infrastructure and realize after the fact that we need more local disk space available. This is the process we use to expand the disk image. This process assumes the following: You’re using legacy disk partitions. The process for LVM is similar and I will describe that in another post (it’s generally identical except for an additional pvresize thrown in and lvextend in place of resize2fs).