Différences

Ci-dessous, les différences entre deux révisions de la page.

--- fr:xen [2019/05/21 07:56] – [Sources et documentation] zatalyz
+++ fr:xen [2025/10/25 08:38] (Version actuelle) – [Failed to free memory for the domain] Résolution à la noix zatalyz
@@ Ligne 40: / Ligne 40: @@
 Installer les divers outils dont on va avoir besoin :
   apt update
-  apt install xen-linux-system-amd64 xen-tools qemu-system-x86
+  apt install  xen-tools qemu-system-x86 xen-system-amd64
+  avant buster : xen-linux-system-amd64
 ==== Booter sur le bon noyau : configuration de GRUB ====
@@ Ligne 304: / Ligne 304: @@
 Si vous avez les éléments pour expliquer la théorie, complétez l'article.
- --- //[[wiki:user:zatalyz|zatalyz]] 2018/04/20 08:57//
+ --- //[[user:zatalyz|zatalyz]] 2018/04/20 08:57//
 </WRAP>
@@ Ligne 442: / Ligne 442: @@
   xl create /etc/xen/myvm.conf
+===== Pallier à une RAM trop basse =====
+Sur une machine pas très puissante, la RAM est vite un plafond limitant. Et même sur une grosse machine, on veut rapidement faire plus de VM qu'on n'a de ram.
+Xen permet de négocier avec ça.
+De base, on peut créer plus des VM avec plus de RAM cumulé que le serveur ne le permet. Par exemple si on a 4 Go de RAM physique, il est possible d'allouer 6 à 8 Go de ram //en tout// aux diverses VM, donc de lancer 8 VM à 1Go de RAM par exemple. Mais si plusieurs VM ont la ram qui s'emballe, l'usage du swap va intervenir et ça va ramer (forcément).
+<WRAP center round help 60%>
+Swap ou pas swap ?
+Ça dépend vraiment des besoins et des capacités. Sur une grosse machine, ça se discute vraiment, car le passage en swap va pourrir les disques durs et reculer le diagnostic d'une ram sur-utilisée. Sur une petite machine, cela permet de faire face à des surcharges ponctuelles.
+</WRAP>
+Xen a des mécanismes "d'overcommit" (surcharge) et de "ballooning" afin de gérer un besoin un peu plus grand de ram de façon temporaire. Cela se définit dans les fichiers de config des VM avec ''memory'' et ''maxmem''.
+Exemple
+<code>
+# Mémoire pour le démarrage (en Mo)
+memory = '512'
+# Mémoire qui peut être libéré par le Dom0 si disponible
+maxmem = '1024'
+</code>
+On peut ainsi temporairement et dynamiquement ajuster la mémoire sur une VM active, avec la commande suivante sur l'hyperviseur :
+  xl mem-set <vmname> 512
+Mais attention, cette valeur doit être au maximum celle de "maxmem".
+Pour faciliter l'installation je préfère autoriser pas mal de RAM lors de la création de la VM, quitte à la baisser ensuite en changeant les fichiers de configuration.
+<WRAP center round todo 100%>
+Je ne sais pas trop si automatiquement la VM va demander à utiliser jusque la valeur déclarée avec "maxmem" ou si c'est uniquement à faire manuellement. En théorie, si j'ai compris, c'est plutôt que ça va rester à la valeur "memory" sauf intervention humaine pour débloquer plus de ram temporairement. Ce qui permettrait d'éviter que la RAM des VM sature l'hyperviseur.
+</WRAP>
+<WRAP center round info 100%>
+Il est conseillé de toujours garder 1 Go de RAM pour l'hyperviseur. Ce qui n'est pas évident sur des petites machines... Mais en paramétrant bien "memory", ça devrait aller.
+Par ailleurs, il parait que cette option dans le GRUB peut forcer à réserver de la RAM à l'hyperviseur :
+  GRUB_CMDLINE_XEN_DEFAULT="dom0_mem=512M,max:1024M"
+Mais par défaut, la commande ''xl info'' indique qu'une partie de la RAM serait déjà réservée sur l'hyperviseur (la partie ''free_memory'') donc ce n'est sans doute pas utile de toucher ça. Sauf si vous tombez sur la bizarrerie listée plus bas...
+</WRAP>
+==== Failed to free memory for the domain ====
+J'ai découvert une erreur inattendue après une mise à jour système de l'hyperviseur. Au moment de relancer les vm, j'ai un échec avec ce message :
+  failed to free memory for the domain
+Quelques vérifications de l'état réel de la mémoire :
+<code>free -h
+xl info | grep -E "(total_memory|free_memory)"
+xl dmesg | grep -i memory
+xl list</code>
+Dans mon cas, le résultat significatiof est là :
+<code># xl info | grep -E "(total_memory|free_memory)"
+total_memory           : 4014
+free_memory            : 1029
+# xl list
+Name                                        ID   Mem VCPUs	State	Time(s)
+Domain-0                                     0  2939     4     r-----      11.6</code>
+Je confirme : y'a ce qu'il faut, mais le Domain-0 s'est soudainement mis à se réserver 3Go de RAM, ne laissant plus rien pour mes VM sur ma petite machine.
+On peut d'ailleurs en voir plus avec ''xl list -l'' où ''"domid": 0'' indique des valeurs délirantes pour ''max_memkb'' (16 Go, sur une machine qui n'en a que 4...) et ''target_memkb'' (les 3Go utilisés).
+Comme il consomme réellement 150 Mo de Ram, je peux temporairement lui forcer une utilisation moindre :
+  xl mem-set Domain-0 1024
+Là, mes VM peuvent se lancer...
+Officiellement il faudrait bidouiller ''/etc/default/grub.d/xen.cfg'' pour forcer un usage plus modéré, en ajoutant cette ligne :
+<code>GRUB_CMDLINE_XEN_DEFAULT="dom0_mem=1024"</code>
+Puis
+  update-grub
+MAIS la gestion mémoire semble bien pétée et, en faisant ça, on se retrouve surtout avec un ordi qui ne boote plus... La solution va probablement être de lancer la commande "xl mem-set" au démarrage... Utilisons systemd pour ça, c'est fait pour :
+<code bash xen-memory-fix.service>
+[Unit]
+Description=Fix Xen Dom0 memory
+After=xen.service
+[Service]
+Type=oneshot
+ExecStart=/usr/sbin/xl mem-set Domain-0 1024
+RemainAfterExit=yes
+[Install]
+WantedBy=multi-user.target
+</code>
+On active et démarre le service :
+<code>sudo systemctl enable xen-memory-fix.service
+sudo systemctl start xen-memory-fix.service</code>
+Je ne prétendrais pas que c'est l'idéal, mais je n'ai aucune idée de pourquoi les valeurs par défaut sont devenues aberrantes, où chercher dans le projet Xen (ou chez les mainteneurs Debian), bref... ça marche et ça va suffire.
 ===== Faire des snapshots, cloner une VM =====
 Il s'agit de manipulations propres à LVM((En tout cas, chez nous. Il y a d'autres systèmes qui permettent des snapshots.)), c'est donc dans la [[fr:lvm_snapshot#snapshot|documentation sur LVM, ici.]]
+===== Upgrade de Stretch à Buster =====
+Mettre à jour la distribution puis :
+  apt autoremove
+Changer dans /etc/xen/maVM.conf
+  bootloader = '/usr/lib/xen-4.11/bin/pygrub'
+Vérifier que /etc/sysctl.conf
+  net.ipv4.ip_forward = 1
+Dans /etc/xen/scripts/vif-nat (à la fin)
+  echo handle_iptable
+===== Bugs récurrents =====
+Il y en a quelques uns déjà listé sur cette page, mais consultez aussi la [[fr:lvm_snapshot|page de LVM]], car les deux logiciels sont très liés...
+Si lors du lancement d'un VM, vous avez ceci en erreur :
+<code># xl create /etc/xen/etherpad2.cfg
+Parsing config from /etc/xen/etherpad2.cfg
+libxl: error: libxl_device.c:381:libxl__device_disk_set_backend: Disk vdev=xvda2 failed to stat: /dev/nuxru/etherpad2-disk: No such file or directory
+libxl: error: libxl_create.c:946:initiate_domain_create: Unable to set disk defaults for disk 0
+libxl: error: libxl.c:1575:libxl__destroy_domid: non-existant domain 2
+libxl: error: libxl.c:1534:domain_destroy_callback: unable to destroy guest with domid 2
+libxl: error: libxl.c:1463:domain_destroy_cb: destruction of domain 2 failed</code>
+Allez voir [[fr:lvm_snapshot#lvs_liste_des_disques_qui_ont_disparus|LVS liste des disques qui ont disparus]].
+==== Horloge ====
+Les VM peuvent avoir une heure aberrante par rapport à Dom0. Ce qui est lié à la timezone mal déclarée.
+Ça se règle en exécutant en root
+  dpkg-reconfigure tzdata
+Une liste de choix permet alors de cibler le bon fuseau.
 ===== Sources et documentation =====