[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: virtualisation facile



Ce que j'ai décrit inclut aussi la nécessité de faire tourner un OS différent de celui de l'hôte. La possibilité de faire des snapshots est vraiment importante, cloisonnement ou non. 

En ce qui concerne la virtualisation pour exploiter une autre architecture, je ne sais pas si ça offre des performances potables. Je n'ai pas eu l'occasion d'essayer. De ce que j'ai lu la solution d'Apple pour virtualiser l'architecture amd64 et x86 semble impressionnante. Je ne sais pas si l'exploit est purement dans le logiciel de virtualisation ou si les processeurs M1 et M2 ont un rôle déterminant. Je vois assez peu de cas d'usage à virtualiser une architecture différente, au delà des machines d'Apple en ARM.

Enfin, pour faire tourner des services sous Linux sur un hôte linux, il faut si possible privilégier LXC. Il y a moins de gaspillage de performance. Mais Proxmox ne fait pas cela de la meilleure des façons. Il faut normalement n'avoir que le service qui intéresse l'admin (apache par exemple). Proxmox met en place la plupart des logiciels qu'on trouve sur une machine physique minimale, avec les services qui vont avec. C'est un peu dommage, d'ailleurs.


Si on revient à la question initiale : virtualisation facile et 100% en logiciel libre, il faudrait savoir si c'est pour un serveur ou pour un poste de travail. En fonction de cela je recommanderais respectivement proxmox ou gnome boxes.



Le mer. 21 déc. 2022 à 15:33, Pierre Couderc <pierre@couderc.eu> a écrit :

Le 12/21/22 à 14:03, Dethegeek a écrit :
> La virtualisation ne sert pas qu'à résoudre des problématiques réseau.
>
> Elle permet aussi de concentrer sur une seule machine physique
> plusieurs rôles qui ne sont pas compatibles entre eux (requérant des
> os totalement différents)
>
> Elle permet aussi de réduire l'impact de pannes. Si un service est
> impacté dans une VM, il a peu de chance de propager des effets de bord
> à un autre service (mais l'hôte reste un point de faiblesse).
>
> Le cloisonnement par VM peut aussi être une solution pour ralentir ou
> limiter l'impact d'un intrus. Une fois dans une VM, si le réseau est
> bien configuré, on peut ralentir ou stopper l'étendue de l'attaque.
>
> Une VM avec un seul service, en panne, peut se reconstruire plus
> facilement qu'un système avec 5 services "entremêlés dans une unique
> instance du système d'exploitation. La restauration par sauvegarde
> peur aussi aller plus vite.
>
>
> Enfin, une machine virtuelle peut être capturée dans un état
> instantané, un Snapshot, avant de faire un upgrade risqué. Si ça se
> assez mal, on revient à l'étendue limitée de panne. Une restauration
> d'un Snapshot prend quelques secondes a quelques minutes. C'est bien
> plus rapide que  restaurer un backup. Il faut compter le même ordre de
> rapidité pour créer un Snapshot. C'est un confort incomparable avec
> une sauvegarde traditionnelle de précaution.
>
> Enfin la portabilité d'une VM d'un hôte a un autre est plus facile à
> assurer car le matériel virtualisé est invariable tant que
> l'hyperviseur reste le même. Et encore, entre les différents produits,
> le matériel émulé ne change pas énormément.
>
>
Mmm, c'est exact, mais il faut séparer deux problématiques bien distinctes :

1- la virtualisation proprement dite, quand on a besoin de machines (VM
Windows, ARM...) complètement différentes pour lequel QEMU est sûrement
le plus adapté.

2- l'isolement des fonctions, les containers, pour laquelle un outil
linux m’apparaît comme bien plus efficace et génial, tant que les VMs
restent en linux  : LXD...

La description de la virtualisation de Dethegeek ci-dessus  me semble
s’appliquer plus à l'isolement des fonction qu'à la virtualisation
proprement dite. Le deux outils sont magiques mais chacun à sa place.


Reply to: