Re: [FRsAG] Quel orchestrateur KVM choisir ?
Bonjour, Le 20/11/2020 à 12:27, Daniel Caillibaud a écrit : Bonjour, Merci à ceux qui se sont penchés sur le pb, résultat des courses pour ceux que ça intéresse. Le 13/11/20 à 19h15, Daniel Caillibaud a écrit : Sur un host debian devant héberger des vms debian, je cherche un orchestrateur kvm en cli me permettant : 1) chaque vm dans son lv, avec ce lv montable sur le host Ça c'est visiblement pas possible en kvm, on file pas un filesystem à la vm mais un disque, et elle a son bootloader et sa table de partitions. Y'a des moyens de contournement (libguestfs), mais c'est pas simple. Ce serait possible avec xen. 2) conf réseau permettant de définir une (ou deux) interface dans la vm sur le (ou les) bridges du host (un public et un privé, la plupart des vms n'ont pas d'ip publique) Ça c'est possible mais toujours assez compliqué, faut définir ça dans la VM (pas moyen de fixer nic/ip depuis le host dans les specs de la vm), c'est probablement pour ça que tout le monde passe par du dhcp. Ça devrait être faisable avec terraform... Cordialement, 3) si possible pas de grub dans la vm, on la démarre avec noyau/initrd du host Cf 1) 4) pas de nat (sauf snat pour que les vm privées puissent sortir sur internet), ni dhcp, ni dnsmask, ni autre fioriture. Pas besoin de HA (ni drbd ni ceph) Cf 2) Donc kvm n'est pas adapté à ce que je voulais faire. xen pourrait faire le job, mais j'ai pas assez creusé car en testant proxmox6 + kvm, j'ai testé aussi proxmox6 + lxc, et ça marche mieux que ce que je faisais manuellement auparavant. Ça me permet aussi de garder une infra plus homogène (encore des hosts en stretch + lxc2), et de conserver ma batterie de scripts (pour le backup surtout, avec gestion de la rotation des snapshots, où on peut accéder à n'importe quel fichier de n'importe quel snapshot directement sur le filesystem). Je vais donc pouvoir rester encore un peu avec lxc ;-) Pour info, les pbs que j'ai eu avec systemd dans les conteneurs (avec ma gestion manuelle des conteneurs lxc) pour - host stretch/lxc2 + conteneur buster - host buster/lxc3 + conteneur buster concernaient tous des pbs de sytetmd avec les cgroup, qu'il faut régler au cas par cas en faisant sauter des restrictions systemd, pour notamment ces services (à chaque fois faut un /etc/systemd/system/xxx.service.d/override.conf) Il y a pas mal de monde a avoir des pbs, sur pleins de services, du genre https://forum.proxmox.com/threads/upgrade-lxc-16-04-to-18-04-problems-cgroup.51222/ et la réponse est souvent de passer les conteneurs en mode privilégiés avec du nested = 1 (ce qui revient +/- à rompre l'isolation) 1) logrotate # logrotate.service: Failed to set up mount namespacing: Permission denied # logrotate.service: Failed at step NAMESPACE spawning /usr/sbin/logrotate: Permission denied # cf https://forum.proxmox.com/threads/logrotate-issue-in-buster-lxc.56726/ [Service] PrivateDevices=false PrivateTmp=false ProtectControlGroups=false ProtectKernelModules=false # lui ne devrait pas coincer (ça passe en ro /usr /boot /efi /etc), mais # sans ça il veut pas… ProtectSystem=false 2) munin-node # Cf https://github.com/munin-monitoring/munin/issues/1278 [Service] PrivateTmp=false ProtectHome=false ProtectSystem=false 3) varnishncsa [Service] # vu qu'on tourne dans lxc sans les CAP_SYS_ADMIN, si on veut éviter de mettre dans la conf du conteneur du # lxc.apparmor.profile = unconfined # faut ajouter ça # pour ProtectSystem, yes passe /usr et /boot en read-only, full ajoute /etc et strict ajoute /dev /proc et /sys # pourquoi faut du no ? (en tout cas même avec yes ça démarre pas pour un pb de namespace) ProtectSystem=no ProtectHome=false PrivateTmp=false PrivateDevices=false # ça limite la sécurité dans la VM mais l'augmente vis-à-vis du host # (si varnish est troué il pourrait mettre plus de bazar dans la vm mais ne pourra pas accéder au host) # ça marchait sans cette option, mais y'avait régulièrement des alertes systemd (le notify ci-dessus) avec du # Failed to set up mount namespacing # on essaie ça pour voir si ça va mieux NoNewPrivileges=yes J'ai d'abord eu l'impression qu'avec proxmox6 j'avais moins de pbs, mais ça semble pas tellement le cas, je vais faire un autre thread pour ça. -- Dernat Rémy Chef de projet SI, CNRS Infrastructure des Systèmes d'Information ISI ISEM Montpellier smime.p7s Description: Signature cryptographique S/MIME ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Quel orchestrateur KVM choisir ?
Hello, Dans le même genre, en facile, il y a aussi "kpartx", après sur le concept : à ne pas faire vm démarrée, un FS non clusterisé monté 2x c'est la cata assurée ;) A+ Nicolas > De: "Landry Minoza" > À: "Daniel Caillibaud" > Cc: "frsag" > Envoyé: Mardi 5 Janvier 2021 14:51:22 > Objet: Re: [FRsAG] Quel orchestrateur KVM choisir ? > Bonjour, > Pour info, avec losetup -P, il est possible de créer les entrées /dev/loopXpY > correspondant aux différentes partitions d’un volume Proxmox KVM de type > RAW/LV(-thin). > ⚠ Si le guest utilise lvm, les pv vont être activés automatiquement (à > désactiver avec vhchange -a n vg_guest) avant de losetup -d /dev/loopX > Cdlt, > Le ven. 20 nov. 2020 à 12:28, Daniel Caillibaud < [ > mailto:m...@lairdutemps.org | > m...@lairdutemps.org ] > a écrit : >> Bonjour, >> Merci à ceux qui se sont penchés sur le pb, résultat des courses pour ceux >> que ça intéresse. >> Le 13/11/20 à 19h15, Daniel Caillibaud < [ mailto:m...@lairdutemps.org | >> m...@lairdutemps.org ] > a écrit : >> > Sur un host debian devant héberger des vms debian, je cherche un >> > orchestrateur kvm en cli me permettant : >> > 1) chaque vm dans son lv, avec ce lv montable sur le host >> Ça c'est visiblement pas possible en kvm, on file pas un filesystem à la vm >> mais un disque, et elle a son bootloader et sa table de partitions. Y'a des >> moyens de contournement (libguestfs), mais c'est pas simple. >> Ce serait possible avec xen. >> > 2) conf réseau permettant de définir une (ou deux) interface dans la vm >> > sur le (ou les) bridges du host (un public et un privé, la plupart >> > des vms n'ont pas d'ip publique) >> Ça c'est possible mais toujours assez compliqué, faut définir ça dans la VM >> (pas moyen de fixer nic/ip depuis le host dans les specs de la vm), c'est >> probablement pour ça que tout le monde passe par du dhcp. >> > 3) si possible pas de grub dans la vm, on la démarre avec noyau/initrd du >> > host >> Cf 1) >> > 4) pas de nat (sauf snat pour que les vm privées puissent sortir sur >> > internet), ni dhcp, ni dnsmask, ni autre fioriture. Pas besoin de HA >> > (ni drbd ni ceph) >> Cf 2) >> Donc kvm n'est pas adapté à ce que je voulais faire. xen pourrait faire le >> job, mais j'ai pas assez creusé car en testant proxmox6 + kvm, j'ai testé >> aussi proxmox6 + lxc, et ça marche mieux que ce que je faisais manuellement >> auparavant. >> Ça me permet aussi de garder une infra plus homogène (encore des hosts >> en stretch + lxc2), et de conserver ma batterie de scripts (pour le backup >> surtout, avec gestion de la rotation des snapshots, où on peut accéder à >> n'importe quel fichier de n'importe quel snapshot directement sur le >> filesystem). >> Je vais donc pouvoir rester encore un peu avec lxc ;-) >> Pour info, les pbs que j'ai eu avec systemd dans les conteneurs (avec ma >> gestion manuelle des conteneurs lxc) pour >> - host stretch/lxc2 + conteneur buster >> - host buster/lxc3 + conteneur buster >> concernaient tous des pbs de sytetmd avec les cgroup, qu'il faut régler au >> cas par cas en faisant sauter des restrictions systemd, pour notamment ces >> services (à chaque fois faut un >> /etc/systemd/system/xxx.service.d/override.conf) >> Il y a pas mal de monde a avoir des pbs, sur pleins de services, du genre >> [ >> https://forum.proxmox.com/threads/upgrade-lxc-16-04-to-18-04-problems-cgroup.51222/ >> | >> https://forum.proxmox.com/threads/upgrade-lxc-16-04-to-18-04-problems-cgroup.51222/ >> ] >> et la réponse est souvent de passer les conteneurs en mode privilégiés avec >> du nested = 1 (ce qui revient +/- à rompre l'isolation) >> 1) logrotate >> # logrotate.service: Failed to set up mount namespacing: Permission denied >> # logrotate.service: Failed at step NAMESPACE spawning /usr/sbin/logrotate: >> Permission denied >> # cf [ >> https://forum.proxmox.com/threads/logrotate-issue-in-buster-lxc.56726/ | >> https://forum.proxmox.com/threads/logrotate-issue-in-buster-lxc.56726/ ] >> [Service] >> PrivateDevices=false >> PrivateTmp=false >> ProtectControlGroups=false >> ProtectKernelModules=false >> # lui ne devrait pas coincer (ça passe en ro /usr /boot /efi /etc), mais >> # sans ça il veut pas… >> ProtectSystem=false >> 2) munin-node >> # Cf [ https://github.com/munin-monitoring/munin/issues/1278 | >> https://github.com/munin-monitoring/munin/issues/1278 ] >> [Service] >> PrivateTmp=false >> ProtectHome=
Re: [FRsAG] Quel orchestrateur KVM choisir ?
Bonjour, Pour info, avec losetup -P, il est possible de créer les entrées /dev/loopXpY correspondant aux différentes partitions d’un volume Proxmox KVM de type RAW/LV(-thin). ⚠ Si le guest utilise lvm, les pv vont être activés automatiquement (à désactiver avec vhchange -a n vg_guest) avant de losetup -d /dev/loopX Cdlt, Le ven. 20 nov. 2020 à 12:28, Daniel Caillibaud a écrit : > Bonjour, > > Merci à ceux qui se sont penchés sur le pb, résultat des courses pour ceux > que ça intéresse. > > Le 13/11/20 à 19h15, Daniel Caillibaud a écrit : > > Sur un host debian devant héberger des vms debian, je cherche un > > orchestrateur kvm en cli me permettant : > > 1) chaque vm dans son lv, avec ce lv montable sur le host > > Ça c'est visiblement pas possible en kvm, on file pas un filesystem à la vm > mais un disque, et elle a son bootloader et sa table de partitions. Y'a des > moyens de contournement (libguestfs), mais c'est pas simple. > > Ce serait possible avec xen. > > > 2) conf réseau permettant de définir une (ou deux) interface dans la vm > >sur le (ou les) bridges du host (un public et un privé, la plupart > >des vms n'ont pas d'ip publique) > > Ça c'est possible mais toujours assez compliqué, faut définir ça dans la VM > (pas moyen de fixer nic/ip depuis le host dans les specs de la vm), c'est > probablement pour ça que tout le monde passe par du dhcp. > > > 3) si possible pas de grub dans la vm, on la démarre avec noyau/initrd du > >host > > Cf 1) > > > 4) pas de nat (sauf snat pour que les vm privées puissent sortir sur > >internet), ni dhcp, ni dnsmask, ni autre fioriture. Pas besoin de HA > > (ni drbd ni ceph) > > Cf 2) > > Donc kvm n'est pas adapté à ce que je voulais faire. xen pourrait faire le > job, mais j'ai pas assez creusé car en testant proxmox6 + kvm, j'ai testé > aussi proxmox6 + lxc, et ça marche mieux que ce que je faisais manuellement > auparavant. > > Ça me permet aussi de garder une infra plus homogène (encore des hosts > en stretch + lxc2), et de conserver ma batterie de scripts (pour le backup > surtout, avec gestion de la rotation des snapshots, où on peut accéder à > n'importe quel fichier de n'importe quel snapshot directement sur le > filesystem). > > Je vais donc pouvoir rester encore un peu avec lxc ;-) > > > > Pour info, les pbs que j'ai eu avec systemd dans les conteneurs (avec ma > gestion manuelle des conteneurs lxc) pour > - host stretch/lxc2 + conteneur buster > - host buster/lxc3 + conteneur buster > concernaient tous des pbs de sytetmd avec les cgroup, qu'il faut régler au > cas par cas en faisant sauter des restrictions systemd, pour notamment ces > services (à chaque fois faut un > /etc/systemd/system/xxx.service.d/override.conf) > > Il y a pas mal de monde a avoir des pbs, sur pleins de services, du genre > > https://forum.proxmox.com/threads/upgrade-lxc-16-04-to-18-04-problems-cgroup.51222/ > et la réponse est souvent de passer les conteneurs en mode privilégiés > avec > du nested = 1 (ce qui revient +/- à rompre l'isolation) > > 1) logrotate > # logrotate.service: Failed to set up mount namespacing: Permission denied > # logrotate.service: Failed at step NAMESPACE spawning /usr/sbin/logrotate: > Permission denied > # cf > https://forum.proxmox.com/threads/logrotate-issue-in-buster-lxc.56726/ > [Service] > PrivateDevices=false > PrivateTmp=false > ProtectControlGroups=false > ProtectKernelModules=false > # lui ne devrait pas coincer (ça passe en ro /usr /boot /efi /etc), mais > # sans ça il veut pas… > ProtectSystem=false > > 2) munin-node > # Cf https://github.com/munin-monitoring/munin/issues/1278 > [Service] > PrivateTmp=false > ProtectHome=false > ProtectSystem=false > > 3) varnishncsa > [Service] > # vu qu'on tourne dans lxc sans les CAP_SYS_ADMIN, si on veut éviter de > mettre dans la conf du conteneur du > # lxc.apparmor.profile = unconfined > # faut ajouter ça > # pour ProtectSystem, yes passe /usr et /boot en read-only, full ajoute > /etc et strict ajoute /dev /proc et /sys > # pourquoi faut du no ? (en tout cas même avec yes ça démarre pas pour un > pb de namespace) > ProtectSystem=no > ProtectHome=false > PrivateTmp=false > PrivateDevices=false > # ça limite la sécurité dans la VM mais l'augmente vis-à-vis du host > # (si varnish est troué il pourrait mettre plus de bazar dans la vm mais > ne pourra pas accéder au host) > > # ça marchait sans cette option, mais y'avait régulièrement des alertes > systemd (le notify ci-dessus) avec du > # Failed to set up mount namespacing > # on essaie ça pour voir si ça va mieux > NoNewPrivileges=yes > > > J'ai d'abord eu l'impression qu'avec proxmox6 j'avais moins de pbs, mais > ça semble pas tellement le cas, > je vais faire un autre thread pour ça. > > -- > Daniel > > Ce qui manque aux orateurs en profondeur, ils vous le donnent en > longueur. > Montesquieu > ___ > Liste de diffusion du FRsAG > http://www.frsag.org/ >
Re: [FRsAG] Quel orchestrateur KVM choisir ?
Bonjour, Merci à ceux qui se sont penchés sur le pb, résultat des courses pour ceux que ça intéresse. Le 13/11/20 à 19h15, Daniel Caillibaud a écrit : > Sur un host debian devant héberger des vms debian, je cherche un > orchestrateur kvm en cli me permettant : > 1) chaque vm dans son lv, avec ce lv montable sur le host Ça c'est visiblement pas possible en kvm, on file pas un filesystem à la vm mais un disque, et elle a son bootloader et sa table de partitions. Y'a des moyens de contournement (libguestfs), mais c'est pas simple. Ce serait possible avec xen. > 2) conf réseau permettant de définir une (ou deux) interface dans la vm >sur le (ou les) bridges du host (un public et un privé, la plupart >des vms n'ont pas d'ip publique) Ça c'est possible mais toujours assez compliqué, faut définir ça dans la VM (pas moyen de fixer nic/ip depuis le host dans les specs de la vm), c'est probablement pour ça que tout le monde passe par du dhcp. > 3) si possible pas de grub dans la vm, on la démarre avec noyau/initrd du >host Cf 1) > 4) pas de nat (sauf snat pour que les vm privées puissent sortir sur >internet), ni dhcp, ni dnsmask, ni autre fioriture. Pas besoin de HA > (ni drbd ni ceph) Cf 2) Donc kvm n'est pas adapté à ce que je voulais faire. xen pourrait faire le job, mais j'ai pas assez creusé car en testant proxmox6 + kvm, j'ai testé aussi proxmox6 + lxc, et ça marche mieux que ce que je faisais manuellement auparavant. Ça me permet aussi de garder une infra plus homogène (encore des hosts en stretch + lxc2), et de conserver ma batterie de scripts (pour le backup surtout, avec gestion de la rotation des snapshots, où on peut accéder à n'importe quel fichier de n'importe quel snapshot directement sur le filesystem). Je vais donc pouvoir rester encore un peu avec lxc ;-) Pour info, les pbs que j'ai eu avec systemd dans les conteneurs (avec ma gestion manuelle des conteneurs lxc) pour - host stretch/lxc2 + conteneur buster - host buster/lxc3 + conteneur buster concernaient tous des pbs de sytetmd avec les cgroup, qu'il faut régler au cas par cas en faisant sauter des restrictions systemd, pour notamment ces services (à chaque fois faut un /etc/systemd/system/xxx.service.d/override.conf) Il y a pas mal de monde a avoir des pbs, sur pleins de services, du genre https://forum.proxmox.com/threads/upgrade-lxc-16-04-to-18-04-problems-cgroup.51222/ et la réponse est souvent de passer les conteneurs en mode privilégiés avec du nested = 1 (ce qui revient +/- à rompre l'isolation) 1) logrotate # logrotate.service: Failed to set up mount namespacing: Permission denied # logrotate.service: Failed at step NAMESPACE spawning /usr/sbin/logrotate: Permission denied # cf https://forum.proxmox.com/threads/logrotate-issue-in-buster-lxc.56726/ [Service] PrivateDevices=false PrivateTmp=false ProtectControlGroups=false ProtectKernelModules=false # lui ne devrait pas coincer (ça passe en ro /usr /boot /efi /etc), mais # sans ça il veut pas… ProtectSystem=false 2) munin-node # Cf https://github.com/munin-monitoring/munin/issues/1278 [Service] PrivateTmp=false ProtectHome=false ProtectSystem=false 3) varnishncsa [Service] # vu qu'on tourne dans lxc sans les CAP_SYS_ADMIN, si on veut éviter de mettre dans la conf du conteneur du # lxc.apparmor.profile = unconfined # faut ajouter ça # pour ProtectSystem, yes passe /usr et /boot en read-only, full ajoute /etc et strict ajoute /dev /proc et /sys # pourquoi faut du no ? (en tout cas même avec yes ça démarre pas pour un pb de namespace) ProtectSystem=no ProtectHome=false PrivateTmp=false PrivateDevices=false # ça limite la sécurité dans la VM mais l'augmente vis-à-vis du host # (si varnish est troué il pourrait mettre plus de bazar dans la vm mais ne pourra pas accéder au host) # ça marchait sans cette option, mais y'avait régulièrement des alertes systemd (le notify ci-dessus) avec du # Failed to set up mount namespacing # on essaie ça pour voir si ça va mieux NoNewPrivileges=yes J'ai d'abord eu l'impression qu'avec proxmox6 j'avais moins de pbs, mais ça semble pas tellement le cas, je vais faire un autre thread pour ça. -- Daniel Ce qui manque aux orateurs en profondeur, ils vous le donnent en longueur. Montesquieu ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Quel orchestrateur KVM choisir ?
Le 19/11/20 à 16h55, alexandre derumier a écrit : > proxmox vient de sortir une nouvelle solution de backup (proxmox backup > server = pbs) > > https://pbs.proxmox.com/wiki/index.php/Main_Page > > nouveauté, les incrementales pour qemu (sans snapshots disques, ca track > un bitmap dans le process qemu directement, donc ca marche avec > n'importe quel stockage), et lxc également. > > c'est vraiment bien foutu, un seul backup full, et des incrementales à > vies. (ensuite, dans pbs, il a un systeme de tracking de block, de > purge automatique, checkum des backups, etc...) Merci pour l'info, je jetterai un œil quand j'aurai du proxmox partout. Ça permet de monter le filesystem d'une vm à une date donnée ? J'avais mis en place mon système de backup y'a pas mal d'années, d'abord avec des hard link (inspiré de rsnapshot), puis avec btrfs (qui permet bcp plus de snapshots pour un volume de block/inodes donné), pour justement pouvoir accéder facilement à un snapshot donné, et pouvoir le restaurer partiellement (ou aller fouiller dans un vieux log ou une ancienne config). -- Daniel Il faut pleurer les hommes à leur naissance et non pas à leur mort. Montesquieu ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Quel orchestrateur KVM choisir ?
On 13/11/2020 19:15, Daniel Caillibaud wrote: - proxmox : la doc est pas mal, commandes cli claires, j'ai une vm qui boot mais je réalise qu'avec un storage lvm-thin je peux pas monter son filesystem sur le host, je me suis arrêté là. Le montage du lvm sur le host, c'est ce qui me permet du backup incrémental avec plein de snapshots sur le serveur de backup (j-1, j-2, …, month-12, merci btrfs), ne pas avoir ça serait une vraie galère (doubler toute la procédure de backup/snapshots, car j'ai encore des hosts en stretch/lxc2). proxmox vient de sortir une nouvelle solution de backup (proxmox backup server = pbs) https://pbs.proxmox.com/wiki/index.php/Main_Page nouveauté, les incrementales pour qemu (sans snapshots disques, ca track un bitmap dans le process qemu directement, donc ca marche avec n'importe quel stockage), et lxc également. c'est vraiment bien foutu, un seul backup full, et des incrementales à vies. (ensuite, dans pbs, il a un systeme de tracking de block, de purge automatique, checkum des backups, etc...) ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Quel orchestrateur KVM choisir ?
Alors la distribution XCP-NG sans hésiter pour Xen et bien évidemment, le storage local est disponible On Mon, Nov 16, 2020, 02:54 Daniel Caillibaud wrote: > Le 14/11/20 à 13h46, Florent CARRÉ a écrit : > > > Hello, oVirt fonctionne bien sinon pour du Xen, il y a XCP-NG qui > > fonctionne à merveille. > > > > Y a-t-il un réel blocage sur la technologie de virtualisation pour > vouloir > > à tout prix du KVM? > > Non, le plus important pour moi est plutôt de pouvoir conserver un lv par > VM et pouvoir le monter sur le host. > > -- > Daniel > > Un enfant prodige ? > c'est un enfant dont les parents ont beaucoup d'imagination. > Jean Cocteau > ___ > Liste de diffusion du FRsAG > http://www.frsag.org/ > ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Quel orchestrateur KVM choisir ?
Le 14/11/20 à 13h46, Florent CARRÉ a écrit : > Hello, oVirt fonctionne bien sinon pour du Xen, il y a XCP-NG qui > fonctionne à merveille. > > Y a-t-il un réel blocage sur la technologie de virtualisation pour vouloir > à tout prix du KVM? Non, le plus important pour moi est plutôt de pouvoir conserver un lv par VM et pouvoir le monter sur le host. -- Daniel Un enfant prodige ? c'est un enfant dont les parents ont beaucoup d'imagination. Jean Cocteau ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Quel orchestrateur KVM choisir ?
Le 14/11/2020 à 15:02, Daniel Caillibaud a écrit :
> Bonjour,
>
> Le 13/11/20 à 23h44, Marmotte a écrit :
>
>> Bonsoir,
>>
>> Ce n'est pas du KVM ni du Xen, mais as-tu regardé systemd-nspawn ?
> Je connaissais pas, je vais regarder, mais tu n'as pas les même pbs qu'avec
> lxc3 :
> - devoir mettre du nested = 1 dans la conf du conteneur sur le host
> - devoir rester en legacy cgroup hierarchy
> - devoir définir pleins d'overrides systemd dans les conteneurs pour que
> les services tournent normalement (en gros faire sauter toutes les
> limitations systemd, du genre mettre à false PrivateDevices / PrivateTmp /
> ProtectControlGroups / ProtectKernelModules / ProtectSystem / …)
> - devoir revoir les conf apparmor
>
> Tout ça est pénible mais va surtout à l'encontre des principes d'isolation
> recherchés. C'est ça qui me pousse à passer à kvm.
Pour nested = 1, ça ne me dit rien, je n'ai jamais vu de paramètre
semblable.
Pour les cgroups, j'ai tout laissé par défaut (Debian fait un mix v1 et
v2 selon ce qui est dispo ou pas en v2).
Aucun override pour les services dans mes conteneurs, tout fonctionne
parfaitement (Apache, PHP, MySQL, PostgreSQL, LDAP, Samba, telegraf,
influxdb, grafana, ...).
Je n'ai pas Apparmor, donc je ne peux pas donner de détail à ce niveau.
>
>> Ça me semble correspondre à ton besoin. Il a remplacé LXC depuis
>> quelques temps sur mes serveurs perso, et c'est pareil en plus simple à
>> l'usage.
> Plus simple ?
> J'avoue avoir un doute, car ce que j'avais avec lxc2 était vraiment
> simplissime, mais je vais regarder ;-)
Pour un conteneur basique, le setup minimum, c'est debootstrap dans un
répertoire puis "machinectl start containername", et le container
fonctionne. Pas besoin de configurer un bridge, ni de créer de fichier
de configuration.
Après, pour les configurations, je trouve aussi ça plus simple, mais
c'est probablement une histoire de goût et/ou d'habitude.
>
>> Par rapport à tes contraintes :
>>
>> 1. Tu peux utiliser un LV par conteneur, ou un subvolume btrfs (cloner
>> un conteneur devient juste faire un snapshot rw du subvolume et
>> copier un fichier de conf).
> J'utilise btrfs seulement sur le serveur de backup, pas en prod car j'ai eu
> trop de misères (ça freeze de manière imprédictible et pour une durée
> indéterminée après certaines manip sur les subvolumes, surtout les delete,
> c'est tolérable sur le backup mais pas sur la prod).
>
> Mais dupliquer un lv reste assez simple.
>
>> 2. La gestion du réseau est automatique. Tu peux définir une zone dans
>> la section "[Network]" du fichier de configuration ("Zone=public"
>> par exemple créera un bridge nommé "vz-public" sur le host).
>> 3. C'est du conteneur, donc tout tourne sur le noyau de l'hôte, comme
>> avec LXC.
>> 4. Il gère la règle snat pour sortir tout seul, les interfaces sont en
>> DHCP est par défaut (mais tu peux configurer des IP fixes si tu
>> préfères t'embêter).
> C'est plutôt de devoir gérer du dhcp qui m'embête ;-)
>
> J'ai déjà un resolver unbound par host sur le lan, ils gèrent ma zone
> statique (toutes les ip du lan) à partir d'une simple liste
> nom ip
> (avec un script qui déploie les modifs et reload les resolvers après
> chaque modif de la liste).
> Du coup pour créer un fichier de conf lxc j'avais juste un script qui
> récupère l'ip d'après le nom dans le dns et la met dans le fichier de conf.
Justement, je ne gère pas de DHCP, systemd-networkd s'occupe de tout
tout seul :)
Les IP des containers (et même les subnets des bridges) changent
dynamiquement à chaque reboot, mais comme je n'utilise que les noms
(avec libnss-mymachines pour la résolution automatique via
systemd-resolved), ça ne pose pas de problème (et ça force à ne pas
mettre d'IP en dur quelque part, à chacun de considérer ça comme un
avantage ou pas).
>
>> Autres éléments :
>>
>> * libnss-mymachines permet la résolution DNS des noms des conteneurs
>> depuis l'hôte et les conteneurs.
>> * On peut aussi utiliser libnss-mymachines pour résoudre les noms des
>> UID/GID des conteneurs depuis l'hôte (il lance les conteneurs en
>> "private" par défaut, donc avec un range de UID/GID différent par
>> conteneur).
>> * Pour créer un conteneur, mon process est en gros "btrfs subvolume
>> create /var/lib/machines/container-name; debootstrap; vi
>> /etc/systemd/nspawn/container-name.nspawn; machinectl start
>> container-name" + la conf dans le conteneur (activation de
>> systemd-networkd, etc.).
> systemd-networkd, j'avoue que c'est le premier truc que je vire, passé pas
> mal d'heures à essayer d'y répliquer ce qui marchait avec
> /etc/network/interfaces sans succès, je suis revenu au legacy.
Pour des besoins basiques, il est largement suffisant. Pour des besoins
plus avancés, il n'a peut-être pas encore tout, effectivement.
Mais c'est tellement bien intégré avec systemd-nspawn et
systemd-resolved que je trouve qu'il serait dommage de s'en passer au
moins pour
Re: [FRsAG] Quel orchestrateur KVM choisir ?
Hello, oVirt fonctionne bien sinon pour du Xen, il y a XCP-NG qui fonctionne à merveille. Y a-t-il un réel blocage sur la technologie de virtualisation pour vouloir à tout prix du KVM? Cordialement On Sat, Nov 14, 2020, 13:31 professor geek wrote: > Hello, > > j’utilise oVirt (OSS de RHEV) depuis un peu plus de 3 ans. > > il y a une API utilisable avec ansible et terraform. > Possible d’utiliser un stockage local pour de la data. > > Sinon Proxmox dans le genre fait le taf aussi. > > My 2cts > > Pr > > On 14 November 2020 at 15:22:28, Daniel Caillibaud (m...@lairdutemps.org) > wrote: > > Le 13/11/20 à 21h33, "s.caps via FRsAG" a écrit : > > > Hello,Xen pourquoi pas oui il permettrait de répondre a votre besoin > > d'éviter pygrub.Sinon est-ce que o-virt répondrait au besoin de la > partie > > d'orchestration? (J'ai pas encore eu le temps d'essayer) Mais j'imagine > > qu'il n'apportera rien en plus que kvm/libvirtd pour la partie grub.En > > kvm/libvirtd lors de l'installation avec virt-install il télécharge le > > kernel et initrd dans /var/libvirt/images (de mémoire) et le définit > dans > > le fichier de définition xml. Je dois pouvoir retrouver la syntaxe > exacte > > si vous voulez.Mvg,Seb > > J'avais écarté oVirt car dans la liste > https://www.linux-kvm.org/page/Management_Tools il ne propose qu'une UI > web, pas vraiment ma tasse de thé (qu'il en propose une ne gène pas, mais > je > voudrais au moins un moyen de pouvoir tout faire en cli). > > Par ailleurs il ne semble pas gérer de storage sur un bête lvm local, ça > semble conçu pour de la HA "by design", et je n'ai pas besoin de HA. > > -- > Daniel > > Ceux qui écrivent clairement ont des lecteurs ; ceux qui écrivent > obscurément ont des commentateurs. > Albert Camus > > ___ > Liste de diffusion du FRsAG > http://www.frsag.org/ > > ___ > Liste de diffusion du FRsAG > http://www.frsag.org/ > ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Quel orchestrateur KVM choisir ?
Hello, j’utilise oVirt (OSS de RHEV) depuis un peu plus de 3 ans. il y a une API utilisable avec ansible et terraform. Possible d’utiliser un stockage local pour de la data. Sinon Proxmox dans le genre fait le taf aussi. My 2cts Pr On 14 November 2020 at 15:22:28, Daniel Caillibaud (m...@lairdutemps.org) wrote: Le 13/11/20 à 21h33, "s.caps via FRsAG" a écrit : > Hello,Xen pourquoi pas oui il permettrait de répondre a votre besoin > d'éviter pygrub.Sinon est-ce que o-virt répondrait au besoin de la partie > d'orchestration? (J'ai pas encore eu le temps d'essayer) Mais j'imagine > qu'il n'apportera rien en plus que kvm/libvirtd pour la partie grub.En > kvm/libvirtd lors de l'installation avec virt-install il télécharge le > kernel et initrd dans /var/libvirt/images (de mémoire) et le définit dans > le fichier de définition xml. Je dois pouvoir retrouver la syntaxe exacte > si vous voulez.Mvg,Seb J'avais écarté oVirt car dans la liste https://www.linux-kvm.org/page/Management_Tools il ne propose qu'une UI web, pas vraiment ma tasse de thé (qu'il en propose une ne gène pas, mais je voudrais au moins un moyen de pouvoir tout faire en cli). Par ailleurs il ne semble pas gérer de storage sur un bête lvm local, ça semble conçu pour de la HA "by design", et je n'ai pas besoin de HA. -- Daniel Ceux qui écrivent clairement ont des lecteurs ; ceux qui écrivent obscurément ont des commentateurs. Albert Camus ___ Liste de diffusion du FRsAG http://www.frsag.org/ ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Quel orchestrateur KVM choisir ?
Le 13/11/20 à 21h33, "s.caps via FRsAG" a écrit : > Hello,Xen pourquoi pas oui il permettrait de répondre a votre besoin > d'éviter pygrub.Sinon est-ce que o-virt répondrait au besoin de la partie > d'orchestration? (J'ai pas encore eu le temps d'essayer) Mais j'imagine > qu'il n'apportera rien en plus que kvm/libvirtd pour la partie grub.En > kvm/libvirtd lors de l'installation avec virt-install il télécharge le > kernel et initrd dans /var/libvirt/images (de mémoire) et le définit dans > le fichier de définition xml. Je dois pouvoir retrouver la syntaxe exacte > si vous voulez.Mvg,Seb J'avais écarté oVirt car dans la liste https://www.linux-kvm.org/page/Management_Tools il ne propose qu'une UI web, pas vraiment ma tasse de thé (qu'il en propose une ne gène pas, mais je voudrais au moins un moyen de pouvoir tout faire en cli). Par ailleurs il ne semble pas gérer de storage sur un bête lvm local, ça semble conçu pour de la HA "by design", et je n'ai pas besoin de HA. -- Daniel Ceux qui écrivent clairement ont des lecteurs ; ceux qui écrivent obscurément ont des commentateurs. Albert Camus ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Quel orchestrateur KVM choisir ?
Bonjour,
Le 13/11/20 à 23h44, Marmotte a écrit :
> Bonsoir,
>
> Ce n'est pas du KVM ni du Xen, mais as-tu regardé systemd-nspawn ?
Je connaissais pas, je vais regarder, mais tu n'as pas les même pbs qu'avec
lxc3 :
- devoir mettre du nested = 1 dans la conf du conteneur sur le host
- devoir rester en legacy cgroup hierarchy
- devoir définir pleins d'overrides systemd dans les conteneurs pour que
les services tournent normalement (en gros faire sauter toutes les
limitations systemd, du genre mettre à false PrivateDevices / PrivateTmp /
ProtectControlGroups / ProtectKernelModules / ProtectSystem / …)
- devoir revoir les conf apparmor
Tout ça est pénible mais va surtout à l'encontre des principes d'isolation
recherchés. C'est ça qui me pousse à passer à kvm.
> Ça me semble correspondre à ton besoin. Il a remplacé LXC depuis
> quelques temps sur mes serveurs perso, et c'est pareil en plus simple à
> l'usage.
Plus simple ?
J'avoue avoir un doute, car ce que j'avais avec lxc2 était vraiment
simplissime, mais je vais regarder ;-)
> Par rapport à tes contraintes :
>
> 1. Tu peux utiliser un LV par conteneur, ou un subvolume btrfs (cloner
> un conteneur devient juste faire un snapshot rw du subvolume et
> copier un fichier de conf).
J'utilise btrfs seulement sur le serveur de backup, pas en prod car j'ai eu
trop de misères (ça freeze de manière imprédictible et pour une durée
indéterminée après certaines manip sur les subvolumes, surtout les delete,
c'est tolérable sur le backup mais pas sur la prod).
Mais dupliquer un lv reste assez simple.
> 2. La gestion du réseau est automatique. Tu peux définir une zone dans
> la section "[Network]" du fichier de configuration ("Zone=public"
> par exemple créera un bridge nommé "vz-public" sur le host).
> 3. C'est du conteneur, donc tout tourne sur le noyau de l'hôte, comme
> avec LXC.
> 4. Il gère la règle snat pour sortir tout seul, les interfaces sont en
> DHCP est par défaut (mais tu peux configurer des IP fixes si tu
> préfères t'embêter).
C'est plutôt de devoir gérer du dhcp qui m'embête ;-)
J'ai déjà un resolver unbound par host sur le lan, ils gèrent ma zone
statique (toutes les ip du lan) à partir d'une simple liste
nom ip
(avec un script qui déploie les modifs et reload les resolvers après
chaque modif de la liste).
Du coup pour créer un fichier de conf lxc j'avais juste un script qui
récupère l'ip d'après le nom dans le dns et la met dans le fichier de conf.
> Autres éléments :
>
> * libnss-mymachines permet la résolution DNS des noms des conteneurs
> depuis l'hôte et les conteneurs.
> * On peut aussi utiliser libnss-mymachines pour résoudre les noms des
> UID/GID des conteneurs depuis l'hôte (il lance les conteneurs en
> "private" par défaut, donc avec un range de UID/GID différent par
> conteneur).
> * Pour créer un conteneur, mon process est en gros "btrfs subvolume
> create /var/lib/machines/container-name; debootstrap; vi
> /etc/systemd/nspawn/container-name.nspawn; machinectl start
> container-name" + la conf dans le conteneur (activation de
> systemd-networkd, etc.).
systemd-networkd, j'avoue que c'est le premier truc que je vire, passé pas
mal d'heures à essayer d'y répliquer ce qui marchait
avec /etc/network/interfaces sans succès, je suis revenu au legacy.
> * La migration depuis LXC, c'était simplement déplacer le rootfs vers
> /var/lib/machines/container-name et créer le fichier de conf dans
> /etc/systemd/nspawn (qui contient principalement la "zone" pour le
> bridge).
> * Les containers sont gérés par des units systemd
> (systemd-nspawn@container-name.service), donc on peut définir
> l'ordonnancement (After/Before/Wants/etc.) comme pour n'importe quel
> autre service.
>
> Globalement, ça ne fait "que" gérer des cgroups pour isoler les
> ressources.
Ok, une alternative à lxc, je vais regarder ça de plus près, merci pour
cette piste.
--
Daniel
Pour avoir de l’argent devant soi, les gens mettent de
l’argent de coté. C’est idiot.
Philippe Geluck, Le chat
___
Liste de diffusion du FRsAG
http://www.frsag.org/
Re: [FRsAG] Quel orchestrateur KVM choisir ?
Bonsoir,
Ce n'est pas du KVM ni du Xen, mais as-tu regardé systemd-nspawn ?
Ça me semble correspondre à ton besoin. Il a remplacé LXC depuis
quelques temps sur mes serveurs perso, et c'est pareil en plus simple à
l'usage.
Par rapport à tes contraintes :
1. Tu peux utiliser un LV par conteneur, ou un subvolume btrfs (cloner
un conteneur devient juste faire un snapshot rw du subvolume et
copier un fichier de conf).
2. La gestion du réseau est automatique. Tu peux définir une zone dans
la section "[Network]" du fichier de configuration ("Zone=public"
par exemple créera un bridge nommé "vz-public" sur le host).
3. C'est du conteneur, donc tout tourne sur le noyau de l'hôte, comme
avec LXC.
4. Il gère la règle snat pour sortir tout seul, les interfaces sont en
DHCP est par défaut (mais tu peux configurer des IP fixes si tu
préfères t'embêter).
Autres éléments :
* libnss-mymachines permet la résolution DNS des noms des conteneurs
depuis l'hôte et les conteneurs.
* On peut aussi utiliser libnss-mymachines pour résoudre les noms des
UID/GID des conteneurs depuis l'hôte (il lance les conteneurs en
"private" par défaut, donc avec un range de UID/GID différent par
conteneur).
* Pour créer un conteneur, mon process est en gros "btrfs subvolume
create /var/lib/machines/container-name; debootstrap; vi
/etc/systemd/nspawn/container-name.nspawn; machinectl start
container-name" + la conf dans le conteneur (activation de
systemd-networkd, etc.).
* La migration depuis LXC, c'était simplement déplacer le rootfs vers
/var/lib/machines/container-name et créer le fichier de conf dans
/etc/systemd/nspawn (qui contient principalement la "zone" pour le
bridge).
* Les containers sont gérés par des units systemd
(systemd-nspawn@container-name.service), donc on peut définir
l'ordonnancement (After/Before/Wants/etc.) comme pour n'importe quel
autre service.
Globalement, ça ne fait "que" gérer des cgroups pour isoler les ressources.
Sylvain
Le 13/11/2020 à 19:15, Daniel Caillibaud a écrit :
> Bonjour,
>
> Je vous lis depuis qq temps mais c'est mon premier post ici, bonjour tout
> le monde !
>
> Sur un host debian devant héberger des vms debian, je cherche un
> orchestrateur kvm en cli me permettant :
> 1) chaque vm dans son lv, avec ce lv montable sur le host
> 2) conf réseau permettant de définir une (ou deux) interface dans la vm
>sur le (ou les) bridges du host (un public et un privé, la plupart
>des vms n'ont pas d'ip publique)
> 3) si possible pas de grub dans la vm, on la démarre avec noyau/initrd du
>host
> 4) pas de nat (sauf snat pour que les vm privées puissent sortir sur
>internet), ni dhcp, ni dnsmask, ni autre fioriture. Pas besoin de HA (ni
>drbd ni ceph)
>
> J'ai testé, plus ou moins rapidement
>
> - libvirt+virsh : man virsh fait un peu peur, galère pour arriver à booter
> une première VM et s'y connecter, pas réussi à configurer le réseau
> proprement
>
> - ganeti : leur système de hook debootstrap semble sympa, mais idem, je
> suis resté comme un idiot sur la conf réseau.
>
> - proxmox : la doc est pas mal, commandes cli claires, j'ai une vm qui boot
> mais je réalise qu'avec un storage lvm-thin je peux pas monter son
> filesystem sur le host, je me suis arrêté là.
>
> Le montage du lvm sur le host, c'est ce qui me permet du backup incrémental
> avec plein de snapshots sur le serveur de backup (j-1, j-2, …,
> month-12, merci btrfs), ne pas avoir ça serait une vraie galère (doubler
> toute la procédure de backup/snapshots, car j'ai encore des hosts en
> stretch/lxc2).
>
> Si c'est plus simple avec xen plutôt que kvm, why not, mais j'ai pas
> l'impression que j'arriverai mieux à mes fins…
>
> Je suis donc preneur de tout conseil, merci à ceux qui prendront un peu de
> temps pour en donner !
>
>
>
> PS: un peu plus d'infos sur le contexte
>
> J'utilise depuis pas mal d'années lxc en cli (vm debian sur host debian),
> tout marchait très bien
> - un lv par vm
> - création de vm simple avec
> - pour le contenu copie de lv ou debootstrap sur un lv vide
> - génération du /var/lib/lxc/lavm/config avec awk (y'a que l'ip qui
> change)
> - config réseau très simple avec un bridge sur le host et ip/nic déclarée
> dans la conf de la vm (en fait deux, br0 pour l'interface
> publique et br1 pour l'interface privée, sur vrack ovh), rien à modifier
> dans la vm (le host crée un nic veth-lavm qui s'appelle veth0 dans la vm
> et a la bonne ip)
>
> Mais depuis buster et lxc3, les choses se compliquent, y'a plein de
> services qui déconnent à cause de la nouvelle gestion des cgroup par
> systemd, et d'après mes lectures (nombreuses), pas tellement d'espoir, ma
> façon de faire avec un linux complet dans un conteneur n'est plus tellement
> dans l'esprit de lxc, le seul moyen d'y parvenir à peu près est de faire
> sauter pas mal d'isolations, lxc servirait alors plus à grand chose,
Re: [FRsAG] Quel orchestrateur KVM choisir ?
Hello,Xen pourquoi pas oui il permettrait de répondre a votre besoin d'éviter pygrub.Sinon est-ce que o-virt répondrait au besoin de la partie d'orchestration? (J'ai pas encore eu le temps d'essayer) Mais j'imagine qu'il n'apportera rien en plus que kvm/libvirtd pour la partie grub.En kvm/libvirtd lors de l'installation avec virt-install il télécharge le kernel et initrd dans /var/libvirt/images (de mémoire) et le définit dans le fichier de définition xml. Je dois pouvoir retrouver la syntaxe exacte si vous voulez.Mvg,Seb Message d'origine De : jean rave Date : 13/11/20 21:18 (GMT+01:00) À : Daniel Caillibaud Cc : French SysAdmin Group Objet : Re: [FRsAG] Quel orchestrateur KVM choisir ? Hello, KVM c'est sympas mais pas toujours facile à appréhender.J'ai beaucoup utilisé libvirt+virsh associé à des systèmes de déploiement auto.On est content quand ça finit par marcher mais plus le temps passe, et plus ça devient old school.Depuis quelque temps, je suis passé pleinement sur proxmox + lxc Une gestion facile à prendre en main, le passage en cli ou via l'interface web ne gène pas.C'est flexible et agréable, et les commandes pct permettent énormément d'action pour la gestion.La mise à disposition de template basique ou la création de ses propres images, la gestion des ressources à chaud, un mode cluster etc Pour ton besoin de montage des vm, la commande pct mount @numvm ne fonctionne pas dans ton cas ?Logiquement il ne devrait pas te manquer grand-chose pour basculer dessus.Tous les paramètres sont accessibles à base de fichiers plats pour gérer tes vm, les dupliquer ou ta gestion des sauvegardes via lvm.Proxmox6 est assez mûr maintenant, installé avec debian, ça devient une combinaison plus intéressante que vmware par exemple.En mode cluster avec un filesysteme correctement partagé, on a une redondance avec un failover performant.Dans un vrack ovh par exemple on obtient une bascule automatique des ip entre les serveurs et donc une tolérance de panne importante.En espérant que ça puisse t'aider.Bonne soiréeLe ven. 13 nov. 2020 à 19:15, Daniel Caillibaud a écrit :Bonjour, Je vous lis depuis qq temps mais c'est mon premier post ici, bonjour tout le monde ! Sur un host debian devant héberger des vms debian, je cherche un orchestrateur kvm en cli me permettant : 1) chaque vm dans son lv, avec ce lv montable sur le host 2) conf réseau permettant de définir une (ou deux) interface dans la vm sur le (ou les) bridges du host (un public et un privé, la plupart des vms n'ont pas d'ip publique) 3) si possible pas de grub dans la vm, on la démarre avec noyau/initrd du host 4) pas de nat (sauf snat pour que les vm privées puissent sortir sur internet), ni dhcp, ni dnsmask, ni autre fioriture. Pas besoin de HA (ni drbd ni ceph) J'ai testé, plus ou moins rapidement - libvirt+virsh : man virsh fait un peu peur, galère pour arriver à booter une première VM et s'y connecter, pas réussi à configurer le réseau proprement - ganeti : leur système de hook debootstrap semble sympa, mais idem, je suis resté comme un idiot sur la conf réseau. - proxmox : la doc est pas mal, commandes cli claires, j'ai une vm qui boot mais je réalise qu'avec un storage lvm-thin je peux pas monter son filesystem sur le host, je me suis arrêté là. Le montage du lvm sur le host, c'est ce qui me permet du backup incrémental avec plein de snapshots sur le serveur de backup (j-1, j-2, …, month-12, merci btrfs), ne pas avoir ça serait une vraie galère (doubler toute la procédure de backup/snapshots, car j'ai encore des hosts en stretch/lxc2). Si c'est plus simple avec xen plutôt que kvm, why not, mais j'ai pas l'impression que j'arriverai mieux à mes fins… Je suis donc preneur de tout conseil, merci à ceux qui prendront un peu de temps pour en donner ! PS: un peu plus d'infos sur le contexte J'utilise depuis pas mal d'années lxc en cli (vm debian sur host debian), tout marchait très bien - un lv par vm - création de vm simple avec - pour le contenu copie de lv ou debootstrap sur un lv vide - génération du /var/lib/lxc/lavm/config avec awk (y'a que l'ip qui change) - config réseau très simple avec un bridge sur le host et ip/nic déclarée dans la conf de la vm (en fait deux, br0 pour l'interface publique et br1 pour l'interface privée, sur vrack ovh), rien à modifier dans la vm (le host crée un nic veth-lavm qui s'appelle veth0 dans la vm et a la bonne ip) Mais depuis buster et lxc3, les choses se compliquent, y'a plein de services qui déconnent à cause de la nouvelle gestion des cgroup par systemd, et d'après mes lectures (nombreuses), pas tellement d'espoir, ma façon de faire avec un linux complet dans un conteneur n'est plus tellement dans l'esprit de lxc, le seul moyen d'y parvenir à peu près est de faire sauter pas mal d'isolations, lxc servirait alors plus à grand chose, autant tout faire tourner sur le host directement. -- Daniel Un jour Dieu
Re: [FRsAG] Quel orchestrateur KVM choisir ?
Hello, KVM c'est sympas mais pas toujours facile à appréhender. J'ai beaucoup utilisé libvirt+virsh associé à des systèmes de déploiement auto. On est content quand ça finit par marcher mais plus le temps passe, et plus ça devient old school. Depuis quelque temps, je suis passé pleinement sur proxmox + lxc Une gestion facile à prendre en main, le passage en cli ou via l'interface web ne gène pas. C'est flexible et agréable, et les commandes pct permettent énormément d'action pour la gestion. La mise à disposition de template basique ou la création de ses propres images, la gestion des ressources à chaud, un mode cluster etc Pour ton besoin de montage des vm, la commande pct mount @numvm ne fonctionne pas dans ton cas ? Logiquement il ne devrait pas te manquer grand-chose pour basculer dessus. Tous les paramètres sont accessibles à base de fichiers plats pour gérer tes vm, les dupliquer ou ta gestion des sauvegardes via lvm. Proxmox6 est assez mûr maintenant, installé avec debian, ça devient une combinaison plus intéressante que vmware par exemple. En mode cluster avec un filesysteme correctement partagé, on a une redondance avec un failover performant. Dans un vrack ovh par exemple on obtient une bascule automatique des ip entre les serveurs et donc une tolérance de panne importante. En espérant que ça puisse t'aider. Bonne soirée Le ven. 13 nov. 2020 à 19:15, Daniel Caillibaud a écrit : > Bonjour, > > Je vous lis depuis qq temps mais c'est mon premier post ici, bonjour tout > le monde ! > > Sur un host debian devant héberger des vms debian, je cherche un > orchestrateur kvm en cli me permettant : > 1) chaque vm dans son lv, avec ce lv montable sur le host > 2) conf réseau permettant de définir une (ou deux) interface dans la vm >sur le (ou les) bridges du host (un public et un privé, la plupart >des vms n'ont pas d'ip publique) > 3) si possible pas de grub dans la vm, on la démarre avec noyau/initrd du >host > 4) pas de nat (sauf snat pour que les vm privées puissent sortir sur >internet), ni dhcp, ni dnsmask, ni autre fioriture. Pas besoin de HA (ni >drbd ni ceph) > > J'ai testé, plus ou moins rapidement > > - libvirt+virsh : man virsh fait un peu peur, galère pour arriver à booter > une première VM et s'y connecter, pas réussi à configurer le réseau > proprement > > - ganeti : leur système de hook debootstrap semble sympa, mais idem, je > suis resté comme un idiot sur la conf réseau. > > - proxmox : la doc est pas mal, commandes cli claires, j'ai une vm qui boot > mais je réalise qu'avec un storage lvm-thin je peux pas monter son > filesystem sur le host, je me suis arrêté là. > > Le montage du lvm sur le host, c'est ce qui me permet du backup incrémental > avec plein de snapshots sur le serveur de backup (j-1, j-2, …, > month-12, merci btrfs), ne pas avoir ça serait une vraie galère (doubler > toute la procédure de backup/snapshots, car j'ai encore des hosts en > stretch/lxc2). > > Si c'est plus simple avec xen plutôt que kvm, why not, mais j'ai pas > l'impression que j'arriverai mieux à mes fins… > > Je suis donc preneur de tout conseil, merci à ceux qui prendront un peu de > temps pour en donner ! > > > > PS: un peu plus d'infos sur le contexte > > J'utilise depuis pas mal d'années lxc en cli (vm debian sur host debian), > tout marchait très bien > - un lv par vm > - création de vm simple avec > - pour le contenu copie de lv ou debootstrap sur un lv vide > - génération du /var/lib/lxc/lavm/config avec awk (y'a que l'ip qui > change) > - config réseau très simple avec un bridge sur le host et ip/nic déclarée > dans la conf de la vm (en fait deux, br0 pour l'interface > publique et br1 pour l'interface privée, sur vrack ovh), rien à modifier > dans la vm (le host crée un nic veth-lavm qui s'appelle veth0 dans la vm > et a la bonne ip) > > Mais depuis buster et lxc3, les choses se compliquent, y'a plein de > services qui déconnent à cause de la nouvelle gestion des cgroup par > systemd, et d'après mes lectures (nombreuses), pas tellement d'espoir, ma > façon de faire avec un linux complet dans un conteneur n'est plus tellement > dans l'esprit de lxc, le seul moyen d'y parvenir à peu près est de faire > sauter pas mal d'isolations, lxc servirait alors plus à grand chose, autant > tout faire tourner sur le host directement. > > -- > Daniel > > Un jour Dieu me dit « cette chemise va t'aller » et "oh my Gad, Elmaleh" > ___ > Liste de diffusion du FRsAG > http://www.frsag.org/ > ___ Liste de diffusion du FRsAG http://www.frsag.org/
