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 series. So I recommend you to do same. It can be found at (at the moment, if link becomes absolute look for a newer one, if newer one fails, look for this one)

http://openvswitch.org/releases/openvswitch-2.7.0.tar.gz

wget can be used to download it:

wget http://openvswitch.org/releases/openvswitch-2.7.0.tar.gz

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
3.10.0-514.el7.x86_64

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, and 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 is listed, we’re good to go.

After you fix 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 complete, 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.