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.



Reclaim empty space from, Shrink disk of qcow2 disk file

To reclaim disk space (in other words to shrink disk space) of qcow2 disk file you need to run following steps.

1. Fill guest disk with empty file

This is required since disk does not really hold its configured size, instead it has a sparse file format in creation time. After a while disk gets writes, temporary file creations/deletions that result non zero blocks in qcow2 file which are useless in reality (i.e. temporarily created file and deleted later). So to gain this space we’ll create a file that takes all space available in backing store (here qcow2 file). This file will only contain zeros. That way qemu-img will skip copying zeros and it will only mark the meta-data of zero sequence (for example length of it).

To do this, turn on virtual machine and in virtual machine’s terminal (you can use ssh to connect):

dd if=/dev/zero of=/tempzerofile
 dd will read from /dev/zero and write to /tempzerofile until all disk space is full. Now remove the file:
 rm /tempzerofile

2. Reclaim unused disk space from qcow2 file

Now turn virtual machine off, and run below command in your host machine to reclaim unused space back. Remember this space is marked with zeros and these type of files are called “sparse file”.

qemu-img convert -O qcow2 image.qcow2 shrinked_image.qcow2

where image is the original image whose size is big and we want to shrink it. shrinked_image is the destination image we want to create.

KVM Offline Backups

I use KVM in my production servers. But there are some critical questions with KVM usage. Backup process of running virtual machines may be top most question of KVM users. Although, there are many other solutions in the literature, I will discuss more defensive method in this article. Before I move on to details of backing-up VMs, I will first mention the building blocks I used in this method.


This is the hypervisor.  It supports live snapshot which is crucial for backup process.


A Snapshot of a virtual machine holds the state-of virtual machine at the time of snapshot is taken. This state is mainly about hard drive but if live snapshot is the case, VM’s all registers, memory and kernel buffers are stored into the snapshot.

There are two types of snapshots in KVM.  Internal snapshot is stored in virtual machines disk file, for instance if VM’s disk is named centos.qcow2 then snapshot will be saved within centos.qcow2. External shapshot is not saved into VM’s disk namely centos.qcow2. So snapshot is saved to the location specified with the snapshot command.

Both internal and external snapshots supports online (live) and offline (turned-off) backups.

Continue reading

Sanallaştırma – Virtualbox


Sanallaştırma Bulut Bilişim’in can damarı, yazılımıcının dostu ve öğrenmek için büyük olanaklar veren bir teknolojidir. Sanallaştırma ile fiziksel makinemiz üzerinde değişiklik yapmadan gerçek bir fiziksel makinenin sunduğu hizmetlerin tamamına (hemen hemen) erişilebilmesi mümkündür. Günümüzde Docker gibi teknolojilerle çok daha az yükle bunları başarmak mümkün olsa da sanallaştırma gerçek bir fiziksel makine yerine geçebilen oldukça önemli bir teknolojidir.

Virtualbox, masaüstü sanallaştırması düşünüldüğünde açık kaynak olması, güncellemelerinin sıklıkla yapılması, aralarında Windows’un bulunduğu pekçok işletim sistemi için problemsiz çalışması düşünüldüğünde ilk akla gelen ürünlerdendir. Virtualbox eğer linux dağıtımı kullanıyorsanız paket yöneticisinden, eğer windows işletim sistemi sahibi iseniz sitesinden indirilip kurulabilir. Kurulum adımlarını yapabildiğinizi varsayarak, virtualbox’ın önemli olduğunu düşündüğümüz farklılıklarını ifade edelim.

Linux Dağıtımları için “dkms”

DKMS (dynamic kernel module support), virtualbox guest additons (virtualbox misafir eklentileri), paketinin işletim sistemi kernel güncellemelerinden sonra kendiliğinden derlenmesi ve kayıt ettirilmesi amacıyla kullanılmaktadır. Virtualbox kurulumunuzdan sonra “kernel” vari mesajlar alıyorsanız dkms paketini yüklemeyi deneyebilirsiniz. Bu probleminiz çözmez ise virtualb0x-dkms adlı bir paket te işinizi çözebilir. Bu paketlerin kurulumundan sonra bilgisayarınızı yeniden başlatmanız gerekebilir.

Misafir Eklentileri (Guest Additions)

Tam bir masaüstü deneyimi sunabilmek için virtualbox misafir eklentileri kurulmalıdır. Bu işlemden sonra entegre fare, kopyala-yapıştır (genellikle metin), ekran kartının çeşitli ek çözünürlükleri gibi gerçekten faydalı özellikler kullanılabilir hale gelecektir.

Birden fazla ekran

Evet virtualbox birden fazla ekranı desteklemektedir. Bu özellikten faydalanmak için misafir eklentilerinin yüklü olduğundan emin olunuz.

Birden fazla CPU

Bu özellik te virtualbox tarafından desteklenmektedir.

Nested Virtualization:

Bu kavram malesef Virtualbox tarafından desteklenmemektedir. Bu kavram ile sanal makinenin kendisi içerisinde sanal makineler oluşturulabilmesi (emulated değil) ifade edilmektedir.