Snapshots KVM

Support Debian
#21

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/
#22

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.

#23

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.

#24

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.