Tag Archives: vm

Fedora 22 / CentOS 7 LXC fix systemd-journald process at 100%

Running a Fedora 21, Fedora 22 or a RHEL/CentOS 7 LXC container created by the lxc-create Fedora template can result in a 100% cpu loop for the systemd-journald process.

To fix this issue you must add lxc.kmsg = 0 to the container configuration. This can be done easily for all the Fedora templates in one shot:

echo "lxc.kmsg = 0" >> /usr/share/lxc/config/fedora.common.conf

See also:

WebVirtMgr with LXC support

This is the connections page backported from WebVirtMgr 4.8.7

https://github.com/daniviga/webvirtmgr/

WebVirtMgr (by retspen) is a simple but great libvirt frontend written in python with Django. It currently supports only KVM as hypervisor. However libvirt can be already used to manage other hypervisors (like XEN) and it also supports LXC containers.

Using the container libvirt feature I extended WebVirtMgr, creating a fork, which adds LXC support and other minor improvements (see https://github.com/daniviga/webvirtmgr/commits/master)

LXC support currently has some limitations:

  • The LXC container filesystem must be created manually (this is a libvirt limitation)
  • Even the LXC domain creation isn’t supported right now (you need to create the XML and define the domain manually, virt-install can be used)
  • Web remote console is under development and not yet ready (some work has been made using butterfly)
  • LXC domain deletion doesn’t remove its filesystem
  • Snapshotting is not supported (another libvirt limitation, it can be done manually with LVM or Btrfs)

But basic functions works well:

  • Management of remote hosts (via TCP, SSH, TLS, socket)
  • Start, stop, shutdown, pause
  • Autostart
  • CPU and RAM limits assignment
  • Network interfaces management
  • Clone (only the domain, filesystem must be copied manually)

My WebVirtMgr fork contains also some minor differences and improvements compared to the original:

  • The old connections list page (with a table instead of boxes) has been kept
  • It supports a very basic ACLs system (for both KVM and LXC). With this feature non-admin users can be created (using the django-admin interface) that can only have specific access to a pre-defined set of VMs/LXCs. This means that user “foo“, for example, can only start/stop/shutdown or access the remote console of the VM “my_vm

The installation procedure remains the same as the original project.

Screenshots

This is the connections page backported from WebVirtMgr 4.8.7

This is the connections page backported from WebVirtMgr 4.8.7

KVM instances

The KVM instances view

The LXC instances view

The LXC instances view

An example of a running LXC container

An example of a running LXC container

An LXC domain can be cloned, and a random MAC address can be generated

An LXC domain can be cloned, and a random MAC address can be generated

An example of an LXC deletion

An example of an LXC deletion

Instance admin interface: you can assign users

Instance admin interface: you can assign users

 Links

CentOS 5 on KVM: reduce host CPU load

To reduce host CPU usage with a CentOS 5 VM on KVM is important to add

divider=10

to grub.conf as kernel parameter

kernel /vmlinuz-2.6.18-348.1.1.el5 ro root=LABEL=/ console=ttyS0,115200 divider=10

This will reduce the internal kernel timer from 1000 Hz to 100 Hz.

Although additional parameters are not required, the divider=10 parameter can still be used. Guests with this parameter will produce less CPU load in the host, but will use more coarse-grained timer expiration. (http://s19n.net/articles/2011/kvm_clock.html)

On MicroServer the CPU load reduce is quite visible:

MicroServer CPU usage

MicroServer CPU usage (made with http://www.observium.org/)

For more info read http://s19n.net/articles/2011/kvm_clock.html.

 

Creare un bridge per OpenVZ

Brevemente, ecco la procedura per utilizzare OpenVZ attraverso un Bridge Ethernet al posto del NAT standard.

Per prima cosa creiamo il bridge (es. ‘br0‘). Per dettagli sulla procedura vi rimando a Google. Un esempio: su CentOS è necessario creare il file ifcfg-br0 in /etc/sysconfig/.

Successivamente creiamo il file vznet in /etc/vz/:

vim /etc/vz/vznet.conf

e inseriamo

#!/bin/bash
EXTERNAL_SCRIPT="/usr/sbin/vznetaddbr"

Infine è necessario aggiungere il container (già creato, o in fase di creazione) al bridge con il comando:

vzctl set 101 --netif_add eth0,,,,br0 --save

(101 è l’id del container, eth0 è il nome della scheda all’interno del container, br0 è il bridge dell’host)

Riferimenti:

http://wiki.openvz.org/Virtual_Ethernet_device

Comprimiamo al massimo i qcow2

Ecco un breve tutorial per comprimere al massimo le imamgini qcow2.

Le fasi principali necessarie sono:

  1. Montare il filesystem in read-only oppure attivare il device sull’host
  2. Eseguire zerofree
  3. Ricomprimere l’immagine

I requisiti sono:

  1. zerofree (http://intgat.tigress.co.uk/rmy/uml/index.html oppure yum install zerofree)
  2. qemu-img (disponibili dal pacchetto qemu)

Opzionalmente

  • qemu-nbd (disponibili dal pacchetto qemu)
  • Modulo del kernel nbd

Il principio di funzionamento di zerofree sta nel sovrascrivere con zero tutti i blocchi del filesystem non utilizzati, così che si possa sfruttare al meglio la funzionalità compress del formato qcow2. Per maggiori dettagli vi rimando al stito di zerofree (http://intgat.tigress.co.uk/rmy/uml/index.html) e qcow2 (http://people.gnome.org/~markmc/qcow-image-format.html).

Per utilizzare zerofree su un immagine qcow2 esistente si possono applicare due soluzioni:

  1. Eseguire zerofree all’interno del guest. Questo richiede che il filesystem su cui si vuole operare sia in read-only e che all’interno del guest sia disponibile il programma zerofree.
    Per rimontare un filesystem in read-only normalmente è sufficiente, avendo un accesso locale alla VM e non via SSH, entrare nel runlevel 1 (init 1) ed eseguire il comando

    mount -o remount,ro /
  2. Eseguire zerofree dall’host. Le immagini qcow2 non possono essere montate direttamente nell’host tramite un offset di mount o tramite kpartx; per questo motivo ci server il supporto al Network Block Device alias nbd. Ha come vantaggio la possibilità di eseguire tutto dall’host senza avviare le VM e che è necessario avere il comando zerofree solo sull’host.

Nello specifico utilizzeremo la soluzione numero 2.
Continue reading

Conversione VM RHEL5 da IDE a VirtIO

Recentemente ho avuto necessità di convertire una macchina virtuale KVM con Red Hat Enterprise 5.7 installata originariamente con emulazione IDE al più performante layer di I/O VirtIO.

Il kernel di RHEL5 (e derivate) per quanto vecchiotto supporta già VirtIO sia per i dischi, per la rete che genericamente per PCI e channels.

Per prima cosa, a macchina avviata ancora in modalità IDE è necessario aggiornare l’initrd inserendo il supporto ai moduli virtio desiderati. Ricordarsi di inserire virtio_blk per lo storage, altrimenti la VM modificata non sarà in grado di eseguire il boot su un disco VirtIO.

Da root eseguire il comando:

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

Una volta fermata la macchina, tramite virsh o la gui virt-install sarà sufficiente rimuovere il disco IDE e il controller e ri-aggiungere il disco selezionando come modalità virtio.

Se l’installazione di RHEL5 utilizza, come è di default, le LABEL (oppure un UUID) per identificare le partizioni dei dischi la macchina è pronta per essere utilizzata, basta semplicemente avviarla.
Se grub o l’fstab utilizzassero i nomi de devices (es. hda2) essi andranno modificati secondo lo standard vd (es. hda[n] -> vda[n], hdb -> vdb ecc…)

Creare un volume LVM

Supponendo di voler creare un volume LVM nel disco sdd per prima cosa inizializziamo lo spazio

pvcreate /dev/sdd
pvcreate initializes PhysicalVolume for later use by the  Logi‐
cal  Volume  Manager  (LVM).  Each PhysicalVolume can be a disk
partition, whole disk, meta device, or loopback file.

Successivamente creiamo il gruppo di volumi. Come estenzione fisica del volume (non quella virtuale che poi sarà quella realemente disponibile) è suggerito un valore di 32MB

vgcreate -s 32M backup /dev/sdd
vgcreate creates a  new  volume  group  called  VolumeGroupName
using the block special device PhysicalDevicePath.

Infine creiamo il volume logico vero e proprio assegnadogli una dimensione e un nome. Tale dimensione potrà venire estesa successivamente con lvextend.

lvcreate -L200G -nhomebk backup
lvcreate creates a new logical volume in a volume group  (  see
vgcreate(8),  vgchange(8)  ) by allocating logical extents from
the free physical extent pool of that volume group.

A questo punto il nuovo volume sarà disponibile come device attraverso il path /dev/gruppo/nomevolume pronto per poter essere formattato.

Ricordo che LVM può essere creato anche all’interno di una partizione o di un’immagine disco.

Riferimenti

  • man pvcreate
  • man vgcreate
  • man lvcreate

Montare immagini raw partizionate

Per montare un immagine RAW oppure una partizione e/o LV contenente una VM o un insieme di partizioni è sufficiente avere installato kpartx

yum -y install kpart

A questo punto è possibile sfruttare /dev/mapper per mappare le partizioni del volume

kpartx -av /path/to/file_or_lv

le partizioni compariranno sotto forma di devices

ls /dev/mapper/
file_or_lv1
file_or_lv2
file_or_lvN

a questo punto è possibile montare ogni singola partizione come consueto

mount /dev/mapper/file_or_lv1 /mnt/ext

per rimuovere la mappatura è sufficiente eseguire

kpartx -d /path/to/file_or_lv