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/
