virt-clone

Par souci de performance on utilise des volumes logiques (LV) pour installer les machines virtuelle. Ce gain de performance se paye par un système de backup un peut moins habituel que dans le cas d’un fichier. Voici comment proceder.

Commencons par obtenir la description du LV utilisé par la machine virtuelle actuelle.

# lvdiplay

  --- Logical volume ---
  LV Name                /dev/vg_srv0/lv_vm2
  VG Name                vg_srv0
  LV UUID                MIzDop-R7NY-qvQP-kmN1-C9hT-jD1p-7zQFTP
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                20.00 GiB
  Current LE             640
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:4

Le LV /dev/vg_srv0/lv_vm2, qui contient la machine virtuelle vm2, fait donc exactement 20Go.

On va créer, une fois pour toute, le LV /dev/vg_srv0/lv_vm2_back, de la même taille, pour y stoker un clone de la machine existante vm2.

 lvcreate -L 20G -n lv_vm2_back vg_srv0

Ensuite il suffit de faire le clonage, en prenant soin d’arreter la machine virtuelle vm2 pendant le clonage.

 virsh shutdown vm2 
 virt-clone  -o vm2 -n vm2_back -f /dev/vg_srv0/lv_vm2_back
 virsh start vm2

-o donne le nom de la machine virtuelle Originale
-n donne le nom de la Nouvelle machine virtuelle
-f désigne la destination du clonage (le LV crée avec lvcreate)

Il faut environ 6 min pour : arrêter, cloner 20Go, redémarrer.

Notez que virt-clone a créé le fichier /etc/libvirt/qemu/vm2_back.xml en personnalisant l’adresse mac et le uuid pour éviter les conflits avec l’original mais il n’a pas changer les fichiers dans le clone. Des paramètres, comme l’adresse ip, restent donc les mêmes.

Si on veut exécuter vm2_back en parallèle de son origianl vm2, il faudra eviter les conflits et donc reconfigurer certains fichiers de vm2_back avec des commandes du type :

  guestfish -d vm2_back  -i edit xxxxx

Pour plus d'info sur l'utilisation de guestfish voir ce post.

guestfish

Les machines virtuelle c’est bien mais …
… comment extraire des fichiers d’une machine virtuelle sans avoir à la démarrer, ou, plus grave, quand elle ne veut pas démarrer ?

Le cœur de la solution s’appelle guestfish. Il s’agit d’un shell permettant de ‘dialoguer’ avec une machine virtuelle en fonctionnement mais surtout à l’arrêt. Il faut cependant que le daemon libvirtd fonctionne (/etc/init.d/libvirtd start)

Dans ce qui suit:

• --ro : indique un accès en lecture seule, ce qui permet d’accéder à une machine virtuelle en cours de fonctionnement sans risques.
• -i : a pour effet d’inspecter la machine virtuelle et de monter ses divers filesystem automatiquement.
• /path/to/file et /path/to/dir : sont des chemins absolus dans la machine virtuelle.
• local/dir et local/file : sont relatifs ou absolus sur la machine hôte.

A) Commandes de base pour extraire des fichiers d'une machine virtuelle (domaine) nommée ‘vm1’:
guestfish -d vm1  --ro  -i  cat      /path/to/file
guestfish -d vm1  --ro  -i  download /path/to/file  local/file
guestfish -d vm1  --ro  -i  tar-out  /path/to/dir   local/file
guestfish -d vm1  --ro  -i  copy-out /path/to/dir   local/dir

Note: 'copy-out' effectue une copie récursive en combinant download et tar-out.

Ces commandes sont très utiles pour ausculer les logs et fichiers de conf d'une machine virtuelle qui ne boote pas, ou pour sauvegarder des fichiers avant de reconstruire la machine virtuelle.

B) Commandes de base pour modifier des fichiers d'une machine virtuelle (domaine) nommée ‘vm1’. Cette machine virtuelle doit impérativement être à l’arrêt. (shutdown)
guestfish -d vm1  -i  edit     /path/to/file
guestfish -d vm1  -i  upload   local/file    /path/to/file
guestfish -d vm1  -i  tar-in   local/tarfile /path/to/dir
guestfish -d vm1  -i  copy-out local/dir     /path/to/dir

Note: 'edit' combine download + édition en local avec $EDITOR + upload. Si votre editeur est vi ou emacs vous pouvez remplacer la commande 'edit' par 'vi' ou 'emacs'. Pour utiliser un autre éditeur il faudra configurer la variable $EDITOR.

Ces commandes sont très utiles pour corriger les fichiers de conf comme /boot/grub/grub.conf, ou /etc/passwd, d'une machine virtuelle qui ne boote pas, ou pour personaliser des machinesvirtuelles bâties sur le même master (hostname, ip, domaine, ect...)


C) Enfin, comme avec tout shell on peut entrer en mode interactif avec guestfish et le quitter avec ^D ou exit ou quit. Pour automatiser certaines taches vous pouvez écrire des scripts guestfish, comme avec bash ou perl. Il suffit de commencer le script par :

#!/usr/bin/guestfish –f

Puis de taper les commandes.

Une autre solution est de faire un script bash en y invoquant guestfish et en lui passant les commandes via une redirection de stdin :

#!/bin/sh

guestfish <<_EOF_
domain vm1
run
write /etc/resolv.conf "nameserver 8.8.8.8"
_EOF_

Cette méthode est plus souple car on bénéficie de la puissance de bash pour, par exemple, traiter les paramètres du script et les résultats retournés par guestfish.

Plus d’info :

La référence: http://libguestfs.org/guestfish.1.html à lire absolument pour voir l'étendu des possibiltés.
Plein de petits scripts: http://libguestfs.org/guestfs-recipes.1.html
Pour les cas graves: http://libguestfs.org/virt-rescue.1.html

UTC or not UTC

Universal Time Coordinate

Pour certaines applications l’heure est un paramètre très important. Un changement d’heure été/hiver non pris en compte, ou faux, peut être grave. Comment gérer l’heure sur un système Linux (Fedora) ?

A: Choisir le temps de référence :

Le plus simple est de prendre comme référence le temps universel, c'est-à-dire UTC, et d’utiliser ce temps pour régler l’horloge matérielle de votre serveur, c'est-à-dire l’horloge maintenue à jour dans un circuit électronique CMOS et qui est réglable via le BIOS. (Mais on va s’arranger pour ne pas avoir à passer par le BIOS)

Si on utilise une autre référence la gestion du changement d’heure hiver/été devient difficile ou même impossible. Si on y ajoute la gestion de machines virtuelles et la mise à jour via NTP ça devient un cauchemar.

B: Définir le temps local :
C'est-à-dire indiquer dans quel fuseau horaire est la machine et/ou l’utilisateur.

Voici comment procéder concrètement pour configurer un serveur Linux type Fédora. Attention if faut être root pour faire tout cela.

1. Configurer le système de démarrage pour qu’il sache que l'horloge matérielle indique l’heure UTC.
2. Configurer le fuseau horaire du serveur.
3. Mettre à jour l’heure locale (heure du système linux)
4. Mettre à jour l’heure UTC (heure dans le circuit cmos)

Allons y...

a) Editer le fichier /etc/sysconfig/clock pour qu’il ressemble à ceci :
UTC=true
ZONE="Europe/Paris"

UTC=true indique que la valeur lue dans l’horloge matérielle est le temps universel (UTC)

ZONE=" … " indique le nom du répertoire/fichier, relativement à /usr/share/zoneinfo, qui contient la description du fuseau horaire du serveur.

b) Faire un lien logique de /etc/localtime vers le repertoire/fichier choisi ci-dessus pour ZONE.
Exemple :
ln –sf /usr/share/zoneinfo/Europe/Paris /etc/localtime
Ceux qui ont un volume /usr qui risque de ne pas pouvoir être monté préférerons faire une copie. Mais dans ce cas les mises à jour des fichiers de zone n’auront pas d’effet sur la copie dans /etc.

c) IMPORTANT: Ce qui vient d’être fait n’a pas d'effet immédiat sur le fuseau actuel du système. Si en faisant ce qui précède vous avez changé de fuseau horaire, il est faut rebooter afin que cela soit pris en compte.

Pour les deux étapes qui suivent il est imperatif que le fuseau horaire effectif du système soit le bon (celui definit par ZONE dans /etc/sysconfig/clock et par /etc/localtime.

d) Mettre (si nécessaire) votre heure locale à jour avec la commande « date MMDDHHmm »

Exemple, pour le 13/dec 14h15 on tapera :

date 12131415

e) Copier l’heure système (linux) dans l’heure hardware (bios) en indiquant qu’on veut y mettre l’heure UTC. Linux s’occupera de faire la conversion heure locale/heure universelle.

hwclock --systohc –-utc

Voila !

L’étape suivante est de mettre en place un client NTP afin de garder cette heure à jour.

NOTE: Si un utilisateur n'est pas satisfait par le fuseau horaire définit au niveau du serveur, il peut facilement fixer son propre fuseau horaire, pour sa session, avec la variable TZ. L'usage est le même que pour ZONE dans le fichier /etc/sysconfig/clock.

# TZ='Asia/Kolkata'
# export TZ
# date
Wed Nov 14 21:33:11 IST 2012

# TZ='France/Paris'
# date
Wed Nov 14 16:03:30 France 2012

Non, j'ai pas mis une demie heure pour taper la deuxième commande !
Il a un déclage horaire de 5h30 entre Paris et Kolkata