Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
===== Installation =====
==== Installation sources ====
=== Ubuntu ===
On Ubuntu libvirt-daemon packages are provided by the Ubuntu package sources. Current Ubuntu versions provide the following libvirt-daemon versions:
^ Ubuntu \\ version ^ Release \\ date ^ Version of \\ libvirt-daemon  ^
| 18.04 LTS (Bionic Beaver) | 27. 04. 2018 | 4.0.0 |
| 20.04 LTS (Focal Fossa) | 23. 04. 2020 | 6.0.0 |
| 22.04 LTS (Jammy Jellyfish) | 21. 04. 2022 | 8.0.0 | 
=== Debian ===
On Debian the libvirt-bin packages are also provided by the Debian package sources. Current Debian provides the following libvirt-daemon versions:
^ Debian \\ version ^ Release \\ date ^ Version of \\ libvirt-daemon  ^
| 10 (Buster) | 06. 07. 2019 | 5.0.0 |
| 11 (Bullseye) | 14. 08. 2021 | 7.0.0 |
| 12 (Bookworm) | 10. 06. 2023 | 9.0.0 | 
We are currently using v9.0.0 of libvirt-daemon on Debian 12.
==== Debian 9 and LVM ====
Some defaults for configuring LVM were changed on Debian 9. The default lvm configuration file /etc/lvm/lvm.conf reads as follows:
  global {
    ...
    # Configuration option global/use_lvmetad.
    # Use lvmetad to cache metadata and reduce disk scanning.
    # When enabled (and running), lvmetad provides LVM commands with VG
    # metadata and PV state. LVM commands then avoid reading this
    # information from disks which can be slow. When disabled (or not
    # running), LVM commands fall back to scanning disks to obtain VG
    # metadata. lvmetad is kept updated via udev rules which must be set
    # up for LVM to work correctly. (The udev rules should be installed
    # by default.) Without a proper udev setup, changes in the system's
    # block device configuration will be unknown to LVM, and ignored
    # until a manual 'pvscan --cache' is run. 
    ...
    use_lvmetad = 1
As a result, the service 'lvm2-lvmetad' has been running by default since Debian 9. This can cause severe problems when using LVM with iSCSI: When changing LVM partitions on one iSCSI client, other iSCSI clients don't 'see' the changes, use old meta-data and possibly harm existing LVM content.\\ 
When using KVM with iSCSI or other distributed file systems set the option ''use_lvmetad = 0'' in the LVM configuration file and make sure, the service 'lvm2-lvmetad' is not running __before__ changing any LVM devices.\\ 
While 'lvm2-lvmetad' is still running, update the LVM meta-data on any iSCSI client after any changes to LVM devices:
  pvscan --cache ; vgscan --cache ; lvscan --cache

==== Partitioning ====
For most of the installed KVM hosts the following partitioning was used:
^ No. ^ Partition ^ Type ^ Size ^ File system ^ Mount point ^
| 1. | /dev/sda1 | primary | 250 MB | ext2 | /boot |
| 2. | /dev/sda2 | primary | 16/32 GB | none | swap |
| 3. | /dev/sda3 | primary | 15 GB | ext4 | / |
| 4. | /dev/sda4 | primary | remainder | LVM | see below |
=== Explanation of the partitioning: ===
== 1. Boot-Partition ==
A boot partition is used for two reasons:
  * it is a precondition for encrypting the host later and
  * the file system 'ext2' is easier to be repaired by external tools.
== 2. Swap-Partition ==
According to the guidelines of [[wp>Red_Hat|RedHat]]((RedHat is the company behind the further development of KVM)) the swap partition of a KVM host should have a size of 0.5 x RAM when overcommitment((Distribute more main memory to virtual hosts than physically is available)) of main memory is not used. Thus without overcommitment and provided that a KVM host is equipped with 32 or 64 GB of main memory the swap partition should have a size of 16 or 32 GB, respectively. During the last years of practical work this swap size proved to be sufficient. \\ 
== 3. System partition ==
For a normal installation of Linux Ubuntu a partition size of 15 GB should be OK. Bigger data structures such as e.g. vhost images should rather be stored on separate partitions than on the system partition.\\ 
== 4. LVM-Partiton ==
The remainder of the disk space is managed by [[wp>Logical_Volume_Manager_(Linux)|LVM]]. An LVM partition can be used to store vhost images locally and/or temporarily. The administration of images will be simplified when the partition is mounted on the path /var/lib/libvirt/images - the path of the KVM default storage device 'default'.\\
The partition should contain enough unused disk space for creating snapshots (e.g. 20 – 50 GB).
==== Add a serial console ====
Administration of virtual hosts is much easier when there is a simple way to access the console of a virtual host. One of the simplest ways of access is the access to a serial console:
  root@kvm55:~# virsh console <vhostname>
Such serial access is possible when a serial console was properly added to the vhost with the following two steps:
  * Add the serial console to the definition of the vhost
  * Add the serial console inside the vhost
=== Add the serial console to the vhost definition ===
A serial console can be added to the vhost definition from the command line of the host running kvm:
  root@kvm55:~# sed -i "s/<\/interface>/<\/interface>\n    <serial type='pty'>\n \
  <target port='0'\/>\n \
  <\/serial>\n    <console type='pty'>\n      <target type='serial' port='0'\/>\n \
  <\/console>/g" <XMLFILE>
=== Add the serial console inside the vhost ===
In order to enable the vhost to use a serial console for output the serial console has to be defined as device inside the vhost:   
  root@vhost:~# cp /etc/init/tty1.conf /etc/init/ttys0.conf
  root@vhost:~# sed -i 's/tty1/ttyS0/g' /etc/init/ttys0.conf
  root@vhost:~# sed -i 's/38400 ttyS0/115200 ttyS0 xterm/g' /etc/init/ttys0.conf
When boot messages and messages from the boot manager 'grub' should also be visible on the serial console the console has to be added also to the grub configuration. The easiest way to achieve this is to update the grub default configuration file '/etc/default/grub':
  root@vhost:~# sed -i "s/GRUB_CMDLINE_LINUX_DEFAULT=\".*\"/\
  GRUB_CMDLINE_LINUX_DEFAULT=\"console=ttyS0 console=tty1\"/g" \
  /etc/default/grub
  root@vhost:~# sed -i "s/GRUB_CMDLINE_LINUX=\".*\"/\
  GRUB_CMDLINE_LINUX=\"ipv6.disable=1\"/g" \
  /etc/default/grub
  root@vhost:~# sed -i "s/#GRUB_TERMINAL=console/GRUB_TERMINAL=\“ console \
  serial\“\nGRUB_SERIAL_COMMAND=serial --unit=0 --speed=115200 --word=8 \
  --parity=no --stop=1\"/g" /etc/default/grub
  root@vhost:~# update-grub

==== Adapt the keyboard layout ====
In order to use a German keyboard for Ubuntu when accessing the vhost virtual console via [[wp>Virtual_Network_Computing|VNC]] the keyboard layout has to be properly defined during vhost generation. Keyboard settings are not defined by default and thus an English keyboard is used.\\ 
The German keyboard settings can be added to the xml vhost definition file like so:
  root@kvm55:~# sed -i "s/listen='127.0.0.1'/listen='127.0.0.1' keymap='de'/g" \
  <XMLFILE>
For Debian vhosts the VNC settings don't need to be changed. Debian uses the client's keyboard setting by default.
==== Install ntp on a virtual host? ====
In times of increasing use of [[wp>Kerberos_(protocol)|Kerberos]] the time synchronization of all hosts becomes more and more important. This includes all virtual hosts. The best choice for time synchronization still is the execution of the service '[[wp>Ntpd|ntpd]]'.\\ 
There has been controversial discussions and contradicting statements about the use of 'ntpd' inside virtual hosts based on KVM in the past. Practical experience has proven that there are configurations where the time synchronization between physical and virtual host does not work reliably. The problem could always be solved by using 'ntpd' inside the virtual host.\\ 
Newer statements admit, that the use of a ntpd service inside the affected vhosts is advised. Compare e.g. the [[https://help.ubuntu.com/community/KVM/FAQ#Should_NTP_be_used_for_time_synchronisation.3F|Ubuntu Wiki]].\\ 
As a conclusion the ntpd configuraton of physical and virtual host does not necessarily need to differ when using KVM as virtualization technology.\\ 
\\ 
[[public:kvm|previous chapter]] | [[public:start|contents]] | [[public:kvm:access|next chapter]]