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!

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

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.