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.

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

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.

KVM

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

Snapshots

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 – KVM

Kernel Virtual Machine (KVM)

Sanallaştırmayı bu yazımızda biraz daha açalım. Sanallaştırmayı full-virtualization, para-virtualization ve donanım destekli sanallaştırma olarak üç şeklinde değerlendirebiliriz.

1. Full-virtualization

VMWare bu sınıftadır. Temel olarak x86 mimarisi donanım kaynaklarına erişim için ring-0, ring-1, ring-2 ve ring-3 şekinde 4 seviye belirlemiştir. İşletim sistemleri ring-0’da çalışmayı beklemektedirler. ring-0 en yetkili ve bütün kaynaklara erişilebilen bir seviyedir. Kullanıcı programları ise ring-3’te çalışmaktadırlar. Sanallaştırmadaki zorluk ta tam olarak burada çıkmaktadır. İşletim sistemleri ring-0’da çalışacak şekilde tasarlanmışlardır. Halbuki sanallaştırma yazılımı (hipervizör) ring-0 da çalışmaktadır, yani işletim sistemi ring-0 da çalışmamaktadır. Bu durumun üstesinden gelmek için VMWare binary translation kavramını ortaya koymuştur. Bu kavram ile kullanıcı programları doğrudan ilgili olduğu seviye olan ring-3’te çalıştırılırken, işletim sistemi ring-1’de çalıştırılmakta ancak işletim sistemi ring-0’ı gerektiren bir komut icra edeceği zaman aynı etkiye sahip komu dizisi hipervizör tarafından çalıştırılmaktadır. Yani bu kısım emule olarak ifa edilmektedir. VMWare’in bulduğu ve standart olarak kullanılan bu metod full-virtualization olarak değerlendirilmektedir.

Full virtualization ile işletim sistemi hiçbir şekilde sanal bir sunucu olduğunu bilmez. Hipervizör sanal makine için sanal bios, sanal ses kartı ve diğer gerekli donanım kaynaklarını sanal olarak vermektedir. Bu tekniğin en önemli yanı da zaten işletim sisteminde bir değişiklik gerektirmemesidir.

2. Para-virtualization

Bu sanallaştırmada misafir işletim sistemi değiştirilmek durumundadır. Full virtualization’dan farklı olarak misafir işletim sistemi para-virtualized olduğunu bilir ve bu değişikliğe uğratılmıştır. Bütün işletim sistemleri bu şekilde sanallaştırılamaz.

3. Donanım destekli sanallaştırma (Hardware assisted virtualization)

İşletim sistemlerinin ring-0’da çalışması ihtiyacı nedeniyle CPU üreticileri ring-0’ın altında, hipervizörler için bir seviye daha oluşturdular ve bu seviyeye root mode dediler. Böylelikle para-virtualization veya binary translation’daki yavaşlatmanın önüne geçildi. Sanal işletim sistemi ring-0 da yapılması gereken bir komut çalıştırdığında basitçe hipervizör bu çağrıyı yakalayacak ve CPU’ya aktaracaktır.

KVM

KVM daha çok sunucu sanallaştırması için tercih edilmektedir. Her ne kadar masaüstü sanallaştırması için çeşitli çözümler bulunsa da Virtualbox kadar olgun bir masaüstü çözümü sunmamaktadır. Ancak KVM oldukça hızlı, kararlı, pekçok sanal disk formatını destekleyen (virtualbox ve vmware’inkiler dahil), ağ tarafı oldukça güçlü bir hipervizördür. Kurulumu oldukça kolaydır. Ancak sadece linux dağıtımları için kullanılabilmektedir. qemu sistem komutlarıyla diskler üzerinde snapshot’lar alma, klonlama gibi işlemleri yapmamıza olanak veren araçları barındırmaktadır. Basit bir gui’si vardır. Bu gui ile sanal makineler oluşturabilir, disk kalıpları için havuzlar tanımlayabilir, oluşturulan sanal makinelerin özelliklerini ayarlayabilirsiniz.

Sonuç

Windows masaüstü sanallaştırması genellikle MS Office bağımlılığı nedeniyle (malesef bazen şirketin şablonları vb. sebeplerle bu bağımlılık oluşabiliyor) tercih edilmektedir. Ancak, playonlinux gibi linux çözümleri bu bağımlılığı kaldırmıştır. Eğer masaüstü sanallaştırmasına windows için gerçekten ihtiyaç duymuyorsanız KVM’yi kesinlikle kullanmalısınız.