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. 1)https://www.lisenet.com/2016/getting-started-with-kvm-on-debian-jessie/ or 2)http://linuxnewbieguide.org/?p=1993 or 3)http://xmodulo.com/use-kvm-command-line-debian-ubuntu.html or 4)http://wiki.libvirt.org/page/UbuntuKVMWalkthrough or 5)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.
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
sudo virt-install --virt-type kvm --name=myfirstmv --vcpu=4 --ram=8192 \
--disk path=/dev/vg0/myfirstvm \
--os-variant=debianwheezy --cpuset=auto --network bridge=br0 --boot hd --vnc
virt-install has many more options6) 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 VM7)http://www.cyberciti.biz/faq/howto-setup-serial-console-on-debian-linux/:
in order to see startup/shtudwon messages:
GRUB_SERIAL_COMMAND="serial --speed=19200 --unit=0 --word=8 --parity=no --stop=1"
in order to be able to login: (for Debian Jessie with systemd)
systemctl start serial-getty@ttyS0.service
systemctl enable serial-getty@ttyS0.service
Mounting the virutal maschine disk
There are two options available: either with guestfish (install libguestfs-tools 8) https://www.async.fi/2016/02/building-virtual-machines-with-vmbuilder/
or with virsh virt-edit (install libguestfs-tools 9)https://fedoraproject.org/wiki/How_to_debug_Virtualization_problems#Accessing_data_on_guest_disk_images
guestfish --rw --add /dev/vg0/myfistvm
virt-edit NameOfGuest /boot/grub/grub.conf
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 10) http://www.cyberciti.biz/faq/linux-kvm-vnc-for-guest-machine/
<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 packages11)http://serverfault.com/questions/549766/kvm-guest-with-acpi-installed-will-not-shutdown:
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 12) 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 cpus13) 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 14) 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 15) 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 16) 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 17) https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Virtualization/ch33s08.html :
<vcpu placement='static' cpuset='0-7'>16</vcpu>
<vcpu placement='static' cpuset='0-15'>16</vcpu>
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!
References [ + ]