Work with KVM virtual machines. Host Preparation

Introduction

As promised in the previous article , today we will talk about the basic configuration of the host machine for KVM.


')
First you need to find out if our processor has the necessary instructions to support virtualization.

$ egrep '(vmx|svm)' /proc/cpuinfo

If there is - this is great.

Preparing the operating system

I probably will not describe the installation of Debian Squeeze: if you got to KVM, then installing the system is a trifling matter.

You will need to install a 64-bit OS, since the necessary packages are only for this architecture.

In Debian Squeeze, the “freshness” of packages with KVM and related programs does not suit us at all, since a lot of all sorts of fixes and features will simply pass us by. Therefore, we will add the Debian Sid and experimental repositories:

deb http://ftp.ru.debian.org/debian sid main contrib non-free
deb-src http://ftp.ru.debian.org/debian sid main contrib non-free

deb http://ftp.ru.debian.org/debian experimental main contrib non-free
deb-src http://ftp.ru.debian.org/debian experimental main contrib non-free

We indicate that our base distribution is stable, and not what the system thought:

# echo 'APT::Default-Release "stable";' > /etc/apt/apt.conf.d/default

From there we will need packages:

# aptitude -t experimental install linux-image-2.6.39-1-amd64 qemu-kvm virtinst libvirt-bin

From the stable repository we will need:

# aptitude install uml-utilities bridge-utils

On your desktop you can put virt-manager (GUI utility) that allows you to conveniently create the necessary configurations of virtual machines.

Core

The more recent the kernel is, the better (within certain limits: for example, I would not recommend installing from git). A good option would be 2.6.39, released recently.

It should be noted that there is no module in the standard kernel to support writing to UFS2, and if you plan to run the FreeBSD guest, you will need to build a kernel with this module. And, of course, the latest versions of cgroups are missing from the Debian kernel.

What should be included in the kernel to use the maximum amount of functionality required:

CONFIG_VIRTIO_BLK=y
CONFIG_VIRTIO_NET=y
CONFIG_VIRTIO_CONSOLE=y
CONFIG_HW_RANDOM_VIRTIO=y
CONFIG_VIRTIO=y
CONFIG_VIRTIO_RING=y
CONFIG_VIRTIO_PCI=y
CONFIG_VIRTIO_BALLOON=y
CONFIG_CGROUPS=y
CONFIG_CGROUP_NS=y
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_CGROUP_MEM_RES_CTLR=y
CONFIG_CGROUP_MEM_RES_CTLR_SWAP=y
CONFIG_CGROUP_MEM_RES_CTLR_SWAP_ENABLED=y
CONFIG_CGROUP_SCHED=y
CONFIG_BLK_CGROUP=y
CONFIG_NET_CLS_CGROUP=y

Then we follow the link and install all the deb-packages from there, copy insmod.static to /sbin/insmod.static (this is necessary, because libguestfs uses a statically compiled version of insmod, but there is no such file in Debian and Ubuntu versions and febootstrap have fixed this problem, insmod.static no longer needs to be uploaded to the server). libguestfs allows us to access the VDS disk through the libguestfs API (C, Perl, Python, PHP) or the guestfish utility.

First pancake

Now we have installed everything necessary to run VDS, access them to the network and install the virtual machine itself.

Let's try to install something, for example, the same Debian. So far, without setting up the network, just by default.

Download the netinstall installer:

$ wget cdimage.debian.org/debian-cd/6.0.1a/i386/iso-cd/debian-6.0.1a-i386-netinst.iso

We edit /etc/libvirt/qemu.conf so that virtual machines work for us from an unprivileged user:

user = "username"
group = "libvirt"

Since we will use tun-devices, you need to set the capability CAP_NET_ADMIN , you can do it for a separate executable file, and for the user as a whole, or configure that libvirt does not reset the necessary permissions for qemu / kvm.

Expose for a separate file:

sudo setcap cap_net_admin=ei /usr/bin/kvm

Or expose to the user as a whole in the /etc/security/capability.conf file:

cap_net_admin username

Or set the appropriate setting in /etc/libvirt/qemu.conf :

clear_emulator_capabilities = 0

Add a user to the libvirt and kvm groups:

# adduser username libvirt
# adduser username kvm

Run the installation of the virtual machine:

$ virt-install --connect qemu:///system -n debian_guest -r 512 --arch=i686 --vcpus=1 --os-type=linux --os-variant=debiansqueeze --disk debian-6.0.1a-i386-netinst.iso,device=cdrom --disk debian_guest.img,bus=virtio,size=2,sparse=false,format=raw --network=default,model=virtio --hvm --accelerate --vnc

Let us analyze in detail the parameters that we specified:

• --connect qemu: /// system The URL by which we connect to KVM. You can connect via ssh.
• -n debian_guest The name of the guest.
• -r 512 The allocated amount of RAM in megabytes.
• --arch = i686 Guest operating system architecture.
• --vcpus = 1 The number of virtual processors available to the guest.
• --os-type = linux --os-variant = debianlenny Specific operating system parameters.
• --disk debian-6.0.1a-i386-netinst.iso, device = cdrom Boot from the disk whose image was specified.
• --disk debian_guest.img, bus = virtio, size = 2, sparse = false, format = raw Create an image of a 2GB system, which we immediately place on the disk (you can create an image of zero size, but then fragmentation is possible, which is somewhat slower) . The format is simple, you can do with the dd file. Virtio disk driver, use virtio better than ide: their performance differs, if not by an order of magnitude, then by times.
• --network = default, model = virtio Network default settings. In this case, libvirt will create a bridge, make a dhcp server and issue through it an address for the virtual machine to access.
• --hvm Full virtualization - that is, you can use your own kernels.
• --accelerate Work via / dev / kvm.
• --vnc Run VNC to connect to the text console.

Configuration and Management Utilities

For managing the installation and for cloning virtual machines, we have two great utilities — graphical and console-based: virt-manager and virsh , respectively. Of course, the console version is much richer in its capabilities, but nothing compares to the type of graphs from which the sysadmin’s heart is thrilled.

I think with virt-manager you will figure it out for yourself, let's try digging through the console internals of virsh . Here are a few commands that should be performed and see what happens:

$ virsh --connect qemu:///system list --all
$ virsh --connect qemu:///system dominfo debian_guest
$ virsh --connect qemu:///system stop debian_guest

To not write a thousand times - connect qemu: /// system , add:

export VIRSH_DEFAULT_CONNECT_URI= qemu:///system

In .bashrc or just run this command in the terminal.

Network preparation

The official documentation suggests using several network options: NAT, bridged, and direct use of network cards. And, unfortunately, in various examples that I found on the network and on the official site, only NAT and bridged networks are considered.

In my configuration, TUN / TAP devices are used to which traffic is routed to eth0. I will briefly describe why this routing method was chosen:

NAT does not suit us, since each VDS must be accessible from the network directly.
The scheme with bridges is not very reliable, since theoretically there is the possibility of “capturing” the IP address of another virtual machine.
So:

<interface type='ethernet'>
<mac address='52:54:00:ef:40:1d'/>
<ip address='10.10.10.100'/>
<target dev='debian_guest'/>
<model type='virtio'/>
</interface>


This configuration section should be specified directly in the guest configuration file located at /etc/libvirt/qemu/debian_guest.xml . Edit best through:

$ virsh edit debian_guest

Then the configuration will be updated on the fly, provided that the machine is not running. Otherwise, you will need to wait until it stops, and start it again.

Let's create the virtual device we need.

To begin with, we need to give our user the ability to call system commands without passwords. To do this, add to sudoers:

$ sudo visudo

Cmnd_Alias QEMU = /sbin/ifconfig, /sbin/modprobe, /usr/sbin/brctl, /usr/sbin/tunctl, /sbin/sysctl, /bin/ip, /usr/bin/cgcreate, /usr/bin/cgdelete, /sbin/tc
username ALL=(ALL:ALL) NOPASSWD: QEMU

We enable the possibility of forwarding and proxying arp requests:

sudo sysctl net.ipv4.conf.all.forwarding=1
sudo sysctl net.ipv4.conf.all.proxy_arp=1

You can also add these parameters to /etc/sysctl.conf and apply them:

sudo sysctl -p

Create a virtual network card and raise the device:

sudo tunctl -b -u username -t debian_guest
sudo ifconfig debian_guest 0.0.0.0 up

Let's create a route to the device we need from the desired IP address:

sudo ip route add 10.10.10.100 dev debian_guest

Now you can run VDS:

$ virsh start debian_guest

Having connected to the console, we will see that there is no network, but we have an eth1 device, instead of eth0 . This happened because the system when loading in /etc/udev/rules.d/70-persistent-net.rules prescribes the mac-address of the network card, and if the mac has changed, it creates another entry about the network card, like this:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="xx:xx:xx:xx:xx:xx", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

You need to delete this file and reboot the VDS - after that the network card will be determined correctly.

Let's write new network settings in the guest system:

# ifconfig eth0 10.10.10.100 netmask 255.255.255.0
# route add default gw 10.10.10.10

10.10.10.10 is the IP address of the host system. Now we can ping other machines.

Add DNS servers to /etc/resolv.conf, and it will be absolutely wonderful:

nameserver 8.8.8.8

By the way, I note that it turned out to be very convenient to call network devices belonging to VDS, as well as the VDS themselves - there is no need to look for who owns the tap0 or vnet0 device, or how else you can call them.

If you need to issue another IP address to the virtual machine, it will be enough just to register another route on the host machine:

# ip route add 10.10.10.101 dev debian_guest

And in the guest system create an alias for the network device:

# ifconfig eth0:1 10.10.10.101

In the next part

In the next article I will talk about how to create a VDS image, what generally changes from system to system, and how these parameters can be conveniently changed.