Moving to KVM
By Roman Pertl
Since our beloved OpenVZ virutalisation technology is not moving in a direction we are comfortable with, we are currently evaluation several virtualisation technologies. One the the possible options is KVM. This is not a full tutorial about KVM, there are many good tutorials already, e.g. ((https://www.lisenet.com/2016/getting-started-with-kvm-on-debian-jessie/)) or ((http://linuxnewbieguide.org/?p=1993)) or ((http://xmodulo.com/use-kvm-command-line-debian-ubuntu.html)) or ((http://wiki.libvirt.org/page/UbuntuKVMWalkthrough)) or ((http://www.cyberciti.biz/faq/how-to-install-kvm-on-ubuntu-linux-14-04/)), this is just a collection of some notes which I collected during the evaluation.
General Documentation
RedHat has some good KVM virtualisation documentation available at: https://access.redhat.com/documentation/en/red-hat-enterprise-linux/?version=7/
Debian also has some nice documentation: https://wiki.debian.org/KVM
Creating reproducable VMs for KVM
The easierst way is to use grml-debootstrap to create a new virtual maschine. We already have working netboot environment so we already have added some tuning to grml-debootstrap which makes it even easier.
sudo grml-debootstrap --hostname myfirstvm --vm --target /dev/mapper/vg0-myfirstvm<br />
sudo virt-install --virt-type kvm --name=myfirstmv --vcpu=4 --ram=8192 \<br />
--disk path=/dev/vg0/myfirstvm \<br />
--os-variant=debianwheezy --cpuset=auto --network bridge=br0 --boot hd --vnc<br />
virt-install has many more options(( http://www.techotopia.com/index.php/Installing_a_KVM_Guest_OS_from_the_Command-line_(virt-install) ))
You still need to setup the /etc/network/interfaces file inside your VM!
Examine VM configuration
virsh dumpxml client1
Serial Console for VM
You can use ‘virsh console clientvm’ to connect to the serial console of the virtual machine. In order to make use of it it, you need to activate the serial console in the VM((http://www.cyberciti.biz/faq/howto-setup-serial-console-on-debian-linux/)):
in order to see startup/shtudwon messages:
#/etc/default/grub<br />
GRUB_CMDLINE_LINUX='console=tty0 console=ttyS0,19200n8'<br />
GRUB_TERMINAL=serial<br />
GRUB_SERIAL_COMMAND="serial --speed=19200 --unit=0 --word=8 --parity=no --stop=1"<br />
in order to be able to login: (for Debian Jessie with systemd)
systemctl start serial-getty@ttyS0.service<br />
systemctl enable serial-getty@ttyS0.service<br />
Mounting the virutal maschine disk
There are two options available: either with guestfish (install libguestfs-tools (( https://www.async.fi/2016/02/building-virtual-machines-with-vmbuilder/
)) or with virsh virt-edit (install libguestfs-tools ((https://fedoraproject.org/wiki/How_to_debug_Virtualization_problems#Accessing_data_on_guest_disk_images))
guestfish --rw --add /dev/vg0/myfistvm<br />
virt-edit NameOfGuest /boot/grub/grub.conf<br />
VM Remote Access with VNC
You need to specify a password in order to make it work with MacOSX buildin VNC client, otherwise the client won’t connect! You can add the password by editing the configuration (see cybercitti faq).
<graphics type='vnc' port='-1' autoport='yes' passwd='mysuperduperpassword'/>`
Support VM Shutdown
In order to support restart/shutdown from outside the KVM client, you need to install the following packages((http://serverfault.com/questions/549766/kvm-guest-with-acpi-installed-will-not-shutdown)):
acpid
acpi-support-base
Change VM parameters
Most parameters (e.g. RAM, CPU) cannot be changed during runtime. You can configure a maximal amount and a (lower) current amount. During runtime of a VM you can only allocate until the defined maximal amount. To increase the maximal value you need to shutdown the VM and change the configuration (( http://serverfault.com/questions/403561/change-amount-of-ram-and-cpu-cores-in-kvm#403671 )).
Lessions learned: CPU Placement
We have one VM which requires a lot of CPU usage (more cores than on one physical CPU). By default KVM seems to to limit one VM to one physical CPU, we need to adjust the settings directly in the XML to use all cpus(( https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Virtualization_Deployment_and_Administration_Guide/sect-Manipulating_the_domain_xml-CPU_allocation.html )) (( https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Virtualization_Deployment_and_Administration_Guide/sect-Manipulating_the_domain_xml-CPU_tuning.html )) (( https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Virtualization_Deployment_and_Administration_Guide/sect-Managing_guest_virtual_machines_with_virsh-NUMA_node_management.html )) (( https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Virtualization_Deployment_and_Administration_Guide/sect-Overcommitting_with_KVM-Overcommitting_virtualized_CPUs.html )) (( https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Virtualization/ch33s08.html )):
before:
<vcpu placement='static' cpuset='0-7'>16</vcpu>
after:
<vcpu placement='static' cpuset='0-15'>16</vcpu>
Summary
There are still many things to discover, rethink and consider for moving from OpenVZ to KVM, e.g. better resources planing as resources cannot be changed as easily as in OpenVZ. So there might be some updates to this post in the future. Stay tuned!