Snapshots KVM

[Clochette]

De souvenir la palme d’or de la seule solution bâtarde d’utilisation d’image instantanée revient reviens à Hyperv, qui lors d’une prise d’image instanatnée mets de côté le VHD et utilise l’AVHD, jusqu’a fusion de celui-ci avec le VHD et bascule (imperciptible).

Que ce soit XEN, KVM ou Vmware, les snap)shots sont mis de côté.

Maintenant tous les format ne supporte pas en pratique les prise d’image instantanée tel que RAW, mieux vaux donc s’orienter soit sur du VHD (le plus portable probablement) ou du Qcow2.
Le gros avantages de ce dernier et de permettre le ‘copy on write’ sur un disque séparé de celui du serveur, permettant ainsi de conserver la machine intact.

Idem de souvenir sous Openstack je n’ai jamais démarré une instance à l’aide d’une instantanée, je me suis toujours appuyez sur la construction d’un template en utilisant l’instantanée.

Quels est le format de ton disque virtuel, et quel est la commande utilisé pour faire l’instantanée ?

Dans le pire des cas fait un snapshot de ta machine post-installation comme référentiel, puis fais tes modifs et fais un snapshots, tu pourra ainsi utilisé la fonction de virsh pour ‘revert’ sur celui de ton choix.

A savoir que sur Xenserver il existe plusieurs type d’instantanée seule le deuxième permet de pouvoir recréer à la volé le serveur, l’autre ne pourra servir qu’a être monté pour de la récupération de donnée :

• snapshot de volume (only disk)
• snapshot d’instance (complete server)

Je ne saurai que trop de prendre le temps de bien pesé le pour et le contre des différents format exploitable sous KVM selon tes besoins et de mettre ne place une certaines automatisations (surtout si tu as pas mal de machines) pour les sauvegardes/snapshots de celle-ci.

De ce côté longue vie à Docker ou LXC en s’appuyant sur KVM la simplicité pour ce type d’opération courante dans la vie d’un sysadmin/devops

[Lien_Rag]

Là je suis en qcow2.
J’ai fait les snapshots avec l’outil graphique virt-manager.

Dans le pire des cas fait un snapshot de ta machine post-installation comme référentiel, puis fais tes modifs et fais un snapshots, tu pourra ainsi utilisé la fonction de virsh pour ‘revert’ sur celui de ton choix.

OK, c’est quoi les commandes virsh pour ça?

[Clochette]

J’ai la fainéantise de tout taper voici un lien

How to create snapshot in Linux KVM VM/Domain - nixCraft

Mais il y en a pléthore sur le web.

[Lien_Rag]

OK merci, ça marche pour l’instant (et puis ça m’a forcé à me mettre à la ligne de commande pour KVM, et c’est bien de voir qu’elle ne mord pas).

Aurais-tu une idée sur un autre souci:
Pour ne pas saturer la partition / j’ai fait (sans comprendre tout)
virsh pool-create-as srv-kvm dir --target /home/lienrag/kvm/
mais malgré tout les VMs ont été créées dans /var/lib/libvirt/images/

J’ai créé en graphique un nouveau pool (SPool1LR) pointant sur /home/lienrag/kvm mais ça n’empêche pas que les VM que je créé ensuite avec Virt-Manager sont toujours dans /var/lib/libvirt/images/

Il se passe quoi?

[Clochette]

a première vue je dirais que le pool n’est pas pris en compte lors du déploiement de l’instance, reste à voir ce qu’il y a dans le xml de configuration utilisé à moins que virtmanager gère ça autrement.

Peux-tu tenter cette commande et voir si dedans justement tu ne spécifie pas l’endroit ou sera stocké la configuration et les disques.

N’étant pas un utilisateur de virtmanager je ne pourrait pas t’infirmer ou te confirmer mais je pense malgré tout qu’il gère lui même la configuration et donc le lieu de déploiement.

[MicP]

Bonjour Lien_Rag

Il te faudrait détruire le pool nommé default qui est utilisé par virt-manager
puis ensuite en créer un nouveau nommé aussi default en choisissant
le répertoire que tu veux utiliser : /home/lienrag/kvm/
pour que les fichiers image disque y soient stockés par défaut quand tu créera des nouvelles machines virtuelles avec l’interface virt-manager.

Et comme tu avais créé le pool srv-kvm en utilisant déjà le répertoire /home/lienrag/kvm/
Il te faudra d’abord détruire ce pool.

---

Ça peut se faire depuis l’interface graphique de virt-manager :
Gestionnaire de machines virtuelles -> Édition -> Détails de la connexion -> Onglet Stockage

Ou alors, en ligne de commandes :

NOTE :
Dans ce qui suit, les commandes virsh pool-destroy … et pool-undefine …
ne modifieront pas le contenu des répertoires utilisés par les pools default et srv-kvm

Autrement dit : les fichiers contenus dans les répertoires /home/lienrag/kvm/ et /var/lib/libvirt/images/ ne seront pas supprimés.

---

virsh pool-destroy default
virsh pool-undefine default
virsh pool-destroy srv-kvm
virsh pool-undefine srv-kvm

virsh pool-define-as --name default --type dir --target /home/lienrag/kvm/
virsh pool-autostart default
virsh pool-build default
virsh pool-start default

---

@Clochette J’ai rajouté un v à virsh dans la ligne de commande de ton message.

(saleté de cacahuette fourbe ! )

[Clochette]

@Clochette J’ai rajouté un v à virsh dans la ligne de commande de ton message.

(saleté de cacahuette fourbe ! )

je l’avais pas vue celle-la

[Lien_Rag]

virsh pool-define-as --name default --type dir --target /home/lienrag/kvm/
virsh pool-autostart default
virsh pool-build default
virsh pool-start default

OK merci.
Résultat:
root@debian:/home/lienrag# virsh pool-undefine default
Pool default has been undefined
Normal si j’ai bien compris ce que ton code veut faire.

root@debian:/home/lienrag# virsh pool-destroy srv-kvm
error: failed to get pool 'srv-kvm'
error: Storage pool not found: no storage pool with matching name 'srv-kvm'

Pourtant j’ai bien virsh pool-create-as srv-kvm dir --target /home/lienrag/kvm/
dans mon historique et je ne vois pas quand je l’aurais supprimé…

root@debian:/home/lienrag# virsh pool-undefine srv-kvm
error: failed to get pool 'srv-kvm'
error: Storage pool not found: no storage pool with matching name 'srv-kvm'

Logique vue la première erreur rencontrée

root@debian:/home/lienrag# 
root@debian:/home/lienrag# virsh pool-define-as --name default --type dir --target /home/lienrag/kvm/
error: Failed to define pool default
error: operation failed: Storage source conflict with pool: 'SPool1LR'

Erreur qui a une certaine logique, mais comment je fais?
Je change la destination du répertoire? C’est le plus simple mais mes machines seront créées dans le nouveau default ou dans SPool1LR?
Ou je détruis SPool1LR?

root@debian:/home/lienrag# virsh pool-build default
error: failed to get pool 'default'
error: Storage pool not found: no storage pool with matching name 'default'

root@debian:/home/lienrag# virsh pool-autostart default
error: failed to get pool 'default'
error: Storage pool not found: no storage pool with matching name 'default'

Là encore logique vue l’erreur principale…

root@debian:/home/lienrag# virsh pool-start default
error: failed to get pool 'default’
error: Storage pool not found: no storage pool with matching name ‘default’

[MicP]

Bonjour Lien_Rag

Pour savoir où tu en es avec tes pools,
utilises les commandes :

virsh pool-list

et :

virsh pool-info nomDuPollQuiTintéresse

ou bien :

virsh pool-dumpxml nomDuPollQuiTintéresse

---

Le but est d’abord de “libérer” (s’il existe) le pool nommé default
car c’est celui qui est utilisé par virt-manager par défaut pour y créer les fichiers images disques.

Mais apparemment, il n’existe pas :

error: Storage pool not found: no storage pool with matching name ‘default’

---

Je pensais que tu voulais que les fichiers images soient créés dans le répertoire /home/lienrag/kvm/
mais on dirait que ce répertoire est déjà associé au poll nommé SPool1LR

root@debian:/home/lienrag#
root@debian:/home/lienrag# virsh pool-define-as --name default --type dir --target /home/lienrag/kvm/
error: Failed to define pool default
error: operation failed: Storage source conflict with pool: ‘SPool1LR’

---

Il faudrait donc désassocier le répertoire /home/lienrag/kvm/ du pool SPool1LR

virsh pool-destroy SPool1LR
virsh pool-undefine SPool1LR

pour pouvoir ensuite associer le répertoire /home/lienrag/kvm/ au pool default

virsh pool-define-as --name default --type dir --target /home/lienrag/kvm/

[Lien_Rag]

root@debian:/home/lienrag# virsh pool-list
 Name                 State      Autostart 
-------------------------------------------
 lienrag              active     yes       
 SPool1LR             active     yes       
 Téléchargements    active     yes   

root@debian:/home/lienrag# virsh pool-destroy SPool1LR
Pool SPool1LR destroyed

root@debian:/home/lienrag# virsh pool-undefine SPool1LR
Pool SPool1LR has been undefined

root@Idebian:/home/lienrag# virsh pool-define-as --name default --type dir --target /home/lienrag/kvm/
Pool default defined

Jusque-là tout va bien…

[MicP]

Jusque-là tout va bien…

Donc maintenant, si tu utilises l’interface graphique de virt-manager pour créer une nouvelle machine virtuelle, le fichier image disque de cette nouvelle machine virtuelle devrait être créé dans le répertoire :
/home/lienrag/kvm/

[Lien_Rag]

OK ça marche (il a juste fallu faire un virsh pool-start default, il faudra le refaire à chaque fois?), merci.

[MicP]

Effectivement, je n’avais pas recopié de mon premier message
les trois lignes manquantes après le “define”

virsh pool-define-as --name default --type dir --target /home/lienrag/kvm/
virsh pool-autostart default
virsh pool-build default
virsh pool-start default

donc il faudra lancer une la ligne “autostart” pour que le pool soit automatiquement démarré à chaque boot suivant du système debian

---

Pour chaque commande de virsh, tu peux afficher l’aide la concernant
en ajoutant –help à la suite de la commande

virsh pool-autostart --help

virsh pool-build --help

virsh pool-start --help

virsh --help

[Lien_Rag]

OK ça ça marche.

Par contre pour revenir à la question de départ: grâce à l’aide de Clochette et de son lien magique vers cyberciti, j’ai pu faire des instantanés en ligne de commande avec virsh, et ils fonctionnent comme des snapshots bien élevés doivent le faire.

Mais pourquoi quand je regarde la liste des snapshots dans virt-manager ils n’apparaissent pas? Et pourquoi dans la liste des snapshots de virt-manager, j’en ai trois sur cinq qui disent qu’ils sont “en cours d’exécution” (alors que une seule VM, normalement le snapshot maître, est lancée)?

[MicP]

Peut-être en fermant virt-manager ce qui ne stoppe pas les machines virtuelles qui seraient en cours de fonctionnement,
puis en démarrant à nouveau l’interface virt-manager

[Lien_Rag]

Eteindre et redémarrer n’a pas fait apparaître le snapshot créé avec virsh dans la liste des snaphots affichés par virt-manager, non.
Le snapshot créé avec virsh et ceux créés avec virt-manager apparaissent bien avec virsh snapshot-list --domain debian9 par contre.

Pour déplacer les anciennes VM de leur place actuelle vers le nouveau pool en /home/lienrag/kvm il y a une solution?
Je fais un cp à la main du fichier qcow2?

Ce que je trouve sur le net à ce sujet concerne apparemment la migration d’un serveur à un autre (c’est un cas qui se produira quand mes VMs seront entièrement fonctionnelles, mais pas tout de suite).
Le plus simple à comprendre est là:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/virtualization_administration_guide/sect-virtualization-kvm_live_migration-live_kvm_migration_with_virsh

Mais je ne comprends pas malgré tout si virsh migrate debian9 localhost/home/lienrag/kvm devrait marcher (j’obtiens error: no connection driver available for localhost/home/lienrag/kvm et pareil quand je fais virsh migrate debian9 /home/lienrag/kvm) ou non (et dans ce cas quoi utiliser).

debian9 étant bien sûr le nom de ma machine.
Le nom de fichier est lui /var/lib/libvirt/images/debian9.qcow2

[MicP]

Les snapshots sont intégrés dans chaque fichier image disque qcow2 utilisé par chacune de tes machines virtuelles.

Si par exemple, le fichier image disque utilisé par la machine virtuelle debian9 est le fichier nommé /le/répertoire/contenant/debian9.qcow2
la ligne de commande suivante te permettra de voir quels sont les snapshots qui ont été créés
dans ce fichier image disque.

qemu-img info /le/répertoire/contenant/debian9.qcow2

---

Tu peux déplacer les fichiers images disques utilisé par tes machines virtuelles
du répertoire dans lequel ils sont vers un autre répertoire,
comme par exemple celui utilisé par le pool nommé defaut qui est associé au répertoire /home/lienrag/kvm/

Il te faudra ensuite modifier le nom du répertoire contenant le fichier image disque utilisé par chaque machine virtuelle
dans le fichier correspondant à chacune de ces machines virtuelles, avec, par exemple,
pour la machine virtuelle nommée debian9

virsh edit debian9

dans ce fichier xml de la machine virtuelle debian9
tu devrais trouver un extrait ressemblant à :

    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/le/répertoire/contenant/debian9.qcow2'/>
      <target dev='vda' bus='virtio'/>
      <boot order='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </disk>

et il te faudra remlacer :

/le/répertoire/contenant/

par :

/home/lienrag/kvm/

[Lien_Rag]

OK merci.

Tout a marché pendant un certain temps puis j’ai passé ma première machine en bridge, en éditant le XML directement avec Vim:

   <interface type='bridge'>
          <mac address='52:54:00:9a:f5:c3'/>
          <source bridge='br0'/>
          <model type='virtio'/>
          <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
        </interface>

et ensuite je l’ai passée en IP statique:

iface ens3 inet static
address 192.168.x.214
netmask 255.255.255.0
network 192.168.x.0
broadcast 192.168.x.255
gateway 192.168.x.1

Et là elle garde son IP NATée…
En lui allouant la même adresse fixe au niveau du serveur DHCP (sans modifier /etc/network/interfaces !) et en redémarrant la machine physique ça a marché. Faut pas me demander pourquoi (mais si quelqu’un a compris je veux bien une explication)…

Une semaine plus tard, deuxième VM qui marche bien, je la passe en bridge de la même façon, après redémarrage tout marche encore et elle récupère bien une IP du serveur DHCP du réseau principal.
Je la passe en statique de la même façon (sans toucher au DHCP) et là elle a bien la bonne IP, mais plus d’internet du tout, elle ne ping même pas le bridge (en 192.168.x.213)…

Je démarre la deuxième machine et (j’ai pas vu à quel moment exactement) elle aussi se retrouve sans internet.

En cherchant des solutions diverses et variées j’ai éteint toutes les VM pour les redémarrer, et là j’ai:
Unable to open /dev/net/tun, is tun module loaded
D’après
https://docs-old.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/Virtualization_Deployment_and_Administration_Guide/App_Generic_Ethernet.html cela arrive quand on a <interface type='ethernet'> mais ce n’est pas mon cas (en tous cas pas dans le xml des deux machines).

J’avoue que là je ne comprends plus rien, et sans pouvoir démarrer les machines je ne sais pas trop dans quelle direction aller.

[Lien_Rag]

Bon ben tout bêtement le problème du /dev/net/tun venait du fait que j’avais pas redémarré la machine hôte après avoir mis à jour le noyau…

Et je sais pas pourquoi mais le problème d’accès réseau (qui s’était posé avant que je fasse la mise à jour) a disparu aussi.

[MicP]

Merci pour le retour d’information.

Peut-être un module du noyau qui ne s’était pas bien réinitialisé,
à moins qu’un protocole réseau n’ait pas pu (ou n’ait pas voulu) rétablir la connexion après l’insertion du nouveau module.