KVM Virtualization 102

 

Background

In my original post KVM Virtualization 101 I explained some basic commands that are necessary to get on using KVM. In this article I move on to some slightly more obscure topics in using KVM.

 

Routine Operations

CPU Type

When you are operating in a KVM virtual machine the processor will report it’s self to be a QEMU Virtual CPU. If you have a mix of QEMU and KVM host machines, you will need to use the version number to determine the difference.

cat /proc/cpu

 

You will see some thing similar to this

model name : QEMU Virtual CPU version 0.9.1

 

Monitoring & Data Acquisition

Generally, I suggest capturing performance, fault, and log data through the network from central harvesters. For small to medium sized operations, I suggest Cacti/syslog/net-snmpd. Nagios can also perform fault monitoring and data acquisition in one solution.

If, instead, you are looking to capture guest virtual machine data through the hypervisor, this project can help.

http://people.redhat.com/~rjones/nagios-virt/

 

Advanced Operations

Conversion to a VirtIO Net Device

First upgrade to a kernel that is new enough to support Virtio. Then make a new initrd image. Use the following as a guideline from RHEL 5.4: [VirtIO FAQ]. There is a significant performance upgrade when using virtio

Upgrade to RHEL5.4 by adding the following file

/etc/yum.repos.d/eyemg-rh5.4.repo

Upgrade

yum update

Edit the virtual machine definition file

virsh edit server1

Add the following line to the interface section

Example:

Write the config back to the XML file

virsh dumpxml abel /srv/vmdata/abel/abel.xml

Reboot the machine and check to make sure virtio is active. Make sure byte count is different

cat /sys/devices/virtio-pci/virtio0/net\:eth0/statistics/rx_bytes
ping -c 3 10.0.8.1
cat /sys/devices/virtio-pci/virtio0/net\:eth0/statistics/rx_bytes

 

Conversion to a VirtIO Block Device

As with network drivers, your kernel must be new enough to support Virtio. Then make a new initrd image. Used the following as a guideline: [VirtIO FAQ]

Upgrade to RHEL5.4 by adding the following file

/etc/yum.repos.d/eyemg-rh5.4.repo

Upgrade

yum update

Rebuild initrd image

mkinitrd --with virtio_pci --with virtio_blk -f /boot/initrd-$(uname -r).img $(uname -r)

Double check grub is using the latest initrd image

vim /boot/grub/grub.conf

Check to make sure the correct parameter was passed to the kernel at boot

cat /proc/cmdline

 

Elevator=noop

The elevetor is the IO scheduler in the Linux kernel and is useful when tuning a physical machine, but in a virtual machine it should be turned off. This will permit the underlying operating system to do this work

Change the elevator to no operations so that it isn’t in contention with the underlying operating system

kernel /boot/vmlinuz-2.6.18-164.el5PAE ro root=LABEL=/ quiet elevator=noop

 

 

5 comments on “KVM Virtualization 102

  1. ‘virt-manager’ has a tool for modifying the virtual devices on a per-VM basis, so one can just select the virtualized net and block device, but the GUI has changed over time. Also recent Fedora’s will select the virtio net & block drivers at boot time. Even the initramfs on very recent fedora’s selects drivers and boot time and uses udevd !!

  2. I was wondering if you could help me with this question. I currently have a /boot partition (sda1) with grub installed on it. It loads my Fedora install on sdb2. If I make a linux from scratch system and copy the kernel and other necessary files to the /boot directory can I simply manually config the grub.conf file in sda1 to enable it to boot?

    Thank you for your reply

    1. If I understand correctly, yeah, you should be able to do that as long as you have enough space on the /boot partition. You would just make another enty in /boot/grub/grub.conf make sure to specify the the sda1 device.

Leave a Reply

Your email address will not be published. Required fields are marked *