Les seuls cas où j'ai besoin d'un processeur avec extension ce sont les systèmes propriétaires et les systèmes expérimentaux/confidentiels. Dans le premier cas parce que l'on n'en a pas le contrôle, dans le second cas parce que les petites ressources font qu'il y a d'autres priorité que de gérer Xen (par exemple).
Si je voulais virtualiser un Windows (par exemple), si j'ai des doutes à propos des droits que me laisse le CLUF pour virtualiser, je n'ai pas de doute quant à la non-modification.
Pour tester un Haiku ou un ReactOS, je ne vais pas attendre le support de Xen, je comprends que ce n'est pas une priorité.
Quoique... je crois avoir lu dans un journal ou une news Debian que pour Hurd le support de Xen avait beaucoup aidé le développement (au moins de la distrib), car cela permettait de faire des machines de tests/build/toussa plus facilement.
Pour ce qui est de la vraie/fausse virtualisation, ce qui compte c'est de rendre un vrai service. Si le cahier des charges stipule qu'il faut une indépendance au matériel et pouvoir déplacer les systèmes sur différentes machines, et que ces systèmes sont des systèmes libres, que la solution soit vserver, xen ou kvm/qemu, le service est rendu. Après c'est de l'idéologie ou du troll, avec le risque de choisir le moyen pour le moyen.
Récemment sur Linuxfr quelqu'un avait leaké (via GCU) http://www.nbs-system.com/blog/xen-facts/ , j'étais moi-même arrivé aux mêmes conclusions. Au final même un serveurs qui a vocation d'être seul sur une machine physique est virtualisé. Si besoin est je peux maquetter une machine virtuelle à coté en lui vampirisant quelques ressources. Dans l'urgence je pourrais le déplacer plus tard très facilement, même sur la première machine venue. Il suffit de booter sur une clé usb avec Xen dessus, et d'avoir accès à une quelconque copie du serveur. Un tel confort mérite bien quelques cycles CPU en moins. Le cahier des charges est rempli et après Xen, KVM ou Vserver, c'est affectif.
Il y aura toujours des vserverophobes, des kvmophobes ou des xenophobes !
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: drôle de formulation
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse à la dépêche Petites brèves : Phonon 4.5 et Xen 4.1. Évalué à 8.
oui :) et il y a les jails chez BSD je crois.
Les seuls cas où j'ai besoin d'un processeur avec extension ce sont les systèmes propriétaires et les systèmes expérimentaux/confidentiels. Dans le premier cas parce que l'on n'en a pas le contrôle, dans le second cas parce que les petites ressources font qu'il y a d'autres priorité que de gérer Xen (par exemple).
Si je voulais virtualiser un Windows (par exemple), si j'ai des doutes à propos des droits que me laisse le CLUF pour virtualiser, je n'ai pas de doute quant à la non-modification.
Pour tester un Haiku ou un ReactOS, je ne vais pas attendre le support de Xen, je comprends que ce n'est pas une priorité.
Quoique... je crois avoir lu dans un journal ou une news Debian que pour Hurd le support de Xen avait beaucoup aidé le développement (au moins de la distrib), car cela permettait de faire des machines de tests/build/toussa plus facilement.
Pour ce qui est de la vraie/fausse virtualisation, ce qui compte c'est de rendre un vrai service. Si le cahier des charges stipule qu'il faut une indépendance au matériel et pouvoir déplacer les systèmes sur différentes machines, et que ces systèmes sont des systèmes libres, que la solution soit vserver, xen ou kvm/qemu, le service est rendu. Après c'est de l'idéologie ou du troll, avec le risque de choisir le moyen pour le moyen.
Récemment sur Linuxfr quelqu'un avait leaké (via GCU) http://www.nbs-system.com/blog/xen-facts/ , j'étais moi-même arrivé aux mêmes conclusions. Au final même un serveurs qui a vocation d'être seul sur une machine physique est virtualisé. Si besoin est je peux maquetter une machine virtuelle à coté en lui vampirisant quelques ressources. Dans l'urgence je pourrais le déplacer plus tard très facilement, même sur la première machine venue. Il suffit de booter sur une clé usb avec Xen dessus, et d'avoir accès à une quelconque copie du serveur. Un tel confort mérite bien quelques cycles CPU en moins. Le cahier des charges est rempli et après Xen, KVM ou Vserver, c'est affectif.
Il y aura toujours des vserverophobes, des kvmophobes ou des xenophobes !
ce commentaire est sous licence cc by 4 et précédentes