Openvswitch Cheat Sheet

Add libvirt network to be used with open vswitch

Create an xml file like below (it is going to be listed in networks)

The parameters are:

  • The name of the network
  • The forward mode is set to bridge
  • The bridge name is the bridge name
  • The virtualport is set to openvswitch

Then introduce this network to libvirt using commands below:


Add Mirror:

ovs-vsctl –id=@pout get port mir0 — –id=@sport get port eno4 — –id=@m create mirror name=obr0_mirror0 select-src-port=@sport output-port=@pout — set bridge obr0 mirrors=@m

where obr0 is the openvswitch bridge name.

mir0 is the mirror port attached to obr0

eno4 is the port to be mirrored

obr0_mirror0 is the name of the mirror

Add More than One Mirror:

ovs-vsctl –id=@pout get port mir0 — –id=@sport get port eno4 — –id=@m create mirror name=obr0_mirror0 — add bridge obr0 mirrors @m — set mirror obr0_mirror0 select-src-port=@sport select-dst-port=@sport output-port=@pout

repeat as many as mirror as you need!

Clear All Mirrors:

ovs-vsctl clear bridge ovsbr0 mirrors

List All Mirrors:

ovs-vsctl list mirror mymirror


KVM Persistent Interface Names

If you’re using KVM for virtualization you may notice that your ethernet device that is attached to the bridge may have different names each time KVM restarts, and KVM manages attaching/detaching this interface to the bridge by itself.

If you’re using standard linux bridge you can check attached ports:

brctl show

This gives you current bridges (KVM and user defined) and ports on them as shown below:

But you may have some special rules/routes/mirrors based on this interface name. If this interface name ever changes you might execute some commands that disable/cancel previous commands, and update the commands to reflect new interface name. If you’re managing many interfaces, this task may be very time consuming.

Fortunately there is a way to prevent this. You can define the interface name generated by KVM for each guest interface. To enable this feature we’ll be adding some definitions to XML presentation of virtual machine (domain in other words). To add this definition we use “virsh” as expected.

virsh edit <domain-name>

This opens a text editor (vi/vim/nano depending on your OS and configuration) to modify contents. File is in XML format. So make sure that changes result a valid XML file.

Find Interface node in the file. Add below line within the interface node defining a desired interface name:

<target dev="<interface_name>" />

Also note that longer interface names may cause errors and choose a name that is not started with “vnet”. It is obvious not to start with “vnet” because KVM uses “vnet” by default.

Restart KVM service to changes to be effective:

systemctl restart libvirtd.service

Check your bridges again and confirm that KVM guests use your new naming.

Autostart KVM Guest on System Boot

If you want your virtual machine to start when host starts, there are two ways to do this. First one uses command line and pretty straightforward. Second one uses virt-manager (a GUI to manage kvm guests)

Command line:

virsh autostart <domain>

Replace domain with your virtual machine name (case sensitive). For instance, if you have a VM named “websrv”

virsh autstart websrv

will mark websrv to autostart on host reboot/boot.

Virt-manager GUI

Open virt-manager and select your virtual machine from list.

Then display properties of virtual machine (i button next to computer monitor icon).

Select “boot” item from properties in the list (image 1):

Image 1: Virtual machine properties

From boot settings enable check box that says: “Start virtual machine on host boot up”

That’s it!

Openvswitch RPM build on Centos 7

If you ever needed to build openvswitch for Centos 7 (including kernel module) this post may help you.

Commands to build a RPM:

Download openvswitch source. I’ve tested with 2.7.x and 2.9.x series. So I recommend you to do the same. It can be found at (if link becomes absolute look for a newer one, if newer one fails, look for this one)

wget can be used to download it:


we’ll be using some build tools, so install them to the system with the following command.

yum install gcc make python-devel openssl-devel kernel-devel graphviz ernel-debug-devel autoconf automake rpm-build redhat-rpm-config libtool python-six checkpolicy selinux-policy-devel

Then prepare the directories for rpmbuild.

mkdir -p rpmbuild/SOURCES/
mkdir -p rpmbuild/SPECS/

copy source to rpmbuild/SOURCES

cp openvswitch-2.7.0.tar.gz rpmbuild/SOURCES/

Now we have two copies of openvswitch source, one in SOURCES directory the other in the directory where we executed wget. Now navigate to the latter, and extract it.

tar xzf openvswitch-2.7.0.tar.gz

We’ll copy all spec files related to rhel to rpmbuild/SPECS/ from the directory that we extracted.

cp openvswitch-2.7.0/rhel/*.spec rpmbuild/SPECS/

We also need some files to be in SOURCES, so copy them as well,

cp openvswitch-2.7.0/rhel/* rpmbuild/SOURCES/

Now, it’s time to check our kernel version:

uname -a

yours may be different, so note your kernel version.

And finally time to build our kernel module for openvswitch:

rpmbuild -bb --without check -D "kversion 3.10.0-514.el7.x86_64" rpmbuild/SPECS/openvswitch-kmod-fedora.spec

If you updated your operating system, or had a kernel update, some of your links may be broken. To be more precise, link to build directory may be broken. You can check it with:

ls -la /lib/modules/3.10.0-514.el7.x86_64/build

This path should point to a directory, and if it is broken then we have to fix it.

Fixing broken build link (note that if you have this link with contents, do not run commands to fix this issue (4 command listed just below)):

rm /lib/modules/3.10.0-514.el7.x86_64/build
cd /lib/modules/3.10.0-514.el7.x86_64/
ln -s /usr/src/kernels/3.10.0-514.el7.x86_64/ build
ls build/

if contents of build are listed, we’re good to go.

After you fix previously mentioned broken link, go ahead and run same rpmbuild command again to build kernel module:

rpmbuild -bb --without check -D "kversion 3.10.0-514.el7.x86_64" rpmbuild/SPECS/openvswitch-kmod-fedora.spec

if it’s completed succesfully then run rpmbuild again to build user space programs (ovs-*)

rpmbuild -bb --without check -D "kversion 3.10.0-514.el7.x86_64" rpmbuild/SPECS/openvswitch.spec

If both of these commands successfully completed, you can install your openvswitch using generated rpms. Rpms can installed with:

rpm -ivh rpmbuild/RPMS/x86_64/openvswitch-kmod-2.7.0-1.el7.centos.x86_64.rpm 
rpm -ivh rpmbuild/RPMS/x86_64/openvswitch-2.7.0-1.x86_64.rpm

Either reboot, or modprobe to load kernel module and make some tests to check openvswitch.

Get OVS Version
#ovs-vsctl -V
List bridge configuration
#ovs-vsctl show
Create a new bridge
#ovs-vsctl add-br ovs-br0
Add port to the bridge
#ovs-vsctl add-port ovs-br0 eth1
#ovs-vsctl show



KVM Live (Online) External Backups

Ok, even though this can be done with many other methods, I’ll explain mine. I’ll also provide youtube videos for the procedure and demonstration as well.

Unlike offline backups, online backups require minimalist suspend – save – resume actions (hopefully within small amount of time – which depends your modifications and RAM usage) while taking the snapshot. The requirement for this suspend has similar reasons to live migration –state is hold and saved then it continues to execute.

As described in our offline backups post, we could take internal or external backups. But in this post we’ll discuss external backups particularly to take backups.

Continue reading

Nested Virtualization

Nested virtualization is very important feature if you’re using virtual machines for your daily tasks. If you’ve heard but not know much about it this blog post is for you.

You’ve probably watched the movie “Inception”. In this movie you dream in an other dream. This is a nested dream. Virtualization can also be nested like this. You have virtual machine but within the virtual machine you may have another virtual machine. This is not an easy thing (just like dream) since your CPU architecture and hypervisor must support this feature.

So we need to check 2 important features first:

  • Does the CPU supports nested virtualization
  • Does the Hypervisor supports nested virtualization

Continue reading

Solution to: Getting Kernel Panic After Update of Virtual Machine

If you recently updated your Centos VM you may started getting the error below:

Kernel panic -- not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

unknown-block may change depending on your configuration, but symptoms stay same: Kernel panic after the update, and this error message.

Solution is:

yum remove kernel
yum update

That fixed my problem. Hopefully it fixes yours.