Xen et la 3d ?

Support Debian
#1

bonjours et bonne année pour ceux qui m’on pas encore vu :smiley:

je me demande si xen installer sur une testing.

Question : Supporte 1 Os émuler (client) debian qui contiendrai une autre distribution disons une autre debian (sid) , avec le support opengl (pas de windows de prévu) ?

But :dans le but de tester ,les nouveauté des jeux sous linux , 0ad, spring,hedgeware,codeblock, 3d donc) qui très souvent demande a être compilé car ceux des dépot même expérimental son pas a jours.

Pourquoi: et j’en marre de me prendre la tête avec des paquet qui colle pas avec la version que je veux utiliser du coup sa pollue ma ditrib.
L’ installation avec de make install (fait un check installl…) sa va ce mettre partout (pas pour tout les soft compiler) c’est casse pieds.

tout idée , même alternative son les bienvenues :slightly_smiling:
j’ai quand même chercher un peux:http://wiki.xen.org/wiki/XenVGAPassthrough
mai 2 carte semble indispensable… au-temps acheter un 2eme pc :snooty:

#2

[quote=“panthere”]bonjours et bonne année pour ceux qui m’on pas encore vu :smiley:

je me demande si xen installer sur une testing.

Question : Supporte 1 Os émuler (client) debian qui contiendrai une autre distribution disons une autre debian (sid) , avec le support opengl (pas de windows de prévu) ?

But :dans le but de tester ,les nouveauté des jeux sous linux , 0ad, spring,hedgeware,codeblock, 3d donc) qui très souvent demande a être compilé car ceux des dépot même expérimental son pas a jours.

Pourquoi: et j’en marre de me prendre la tête avec des paquet qui colle pas avec la version que je veux utiliser du coup sa pollue ma ditrib.
L’ installation avec de make install (fait un check installl…) sa va ce mettre partout (pas pour tout les soft compiler) c’est casse pieds.

tout idée , même alternative son les bienvenues :slightly_smiling:
j’ai quand même chercher un peux:http://wiki.xen.org/wiki/XenVGAPassthrough
mai 2 carte semble indispensable… au-temps acheter un 2eme pc :snooty:[/quote]

J’ai pas été plus loin ( au point de vue de mes besoins ) que l’installation d’un kernel HVM maison pour l’accès à du hardware de stockage, une piste à creuser concernant le système invité.

#3

Dans ce cas, tu peux utiliser des conteneurs (LXC, OpenVZ) ou même une simple chroot. Tu devrais pouvoir lancer l’interface graphique de l’OS client dans un autre tty.
Il sera sur le même kernel que le dom0 donc bénéficiera de ses drivers pour la 3D.

#4

Merci pour les réponse,
Kna un chroot suffit.?? en fait vu que c est partager si sa plante la machine aux complet risque de planter avec , mai bon sa me dérange deja moins.
mai comment une application peux faire l’appelle depuis le système invité , a des paquet qui ne son pas présent sur la machine hote ?
je ferai des essais ,c’est curieux que j’ai rien vu de tel sur le net tout de même.

#5

[quote=“panthere”]Merci pour les réponse,
Kna un chroot suffit.?? en fait vu que c est partager si sa plante la machine aux complet risque de planter avec , mai bon sa me dérange deja moins.
mai comment une application peux faire l’appelle depuis le système invité , a des paquet qui ne son pas présent sur la machine hote ?
je ferai des essais ,c’est curieux que j’ai rien vu de tel sur le net tout de même.[/quote]

Soit tu pioche sur du compliquer avec très peu de documentation (d’où mon abandon sur le sujet de la 3D qui m’avais titillé à l’époque) en cherchant du côté du kernel invité de type HVM qui ira puiser sur le hardware au prix d’une baisse de performance minime.

Soit tu regarde du côté des ‘containers’ LXC en tête pour te faciliter le déploiement au prix d’une baisse de performance plus net il me semble (reste à confirmer car je n’ai jamais creusé plus loin) comme l’a proposé kna :wink:.

#6

Je n’ai pas testé pour ce type d’application, mais en théorie un simple chroot me parait concevable.
Si ton appli plante seule, ça ne posera pas de problème. Si l’appli arrive à faire planter le noyau tout sera planté effectivement, mais ce cas doit tout de même être rare…
Les conteneurs type LXC ont peut-être des protections à ce niveau, je l’ignore…

En fait avant de chrooter, tu montes /proc et /dev à partir du système hôte. Ce qui permet au système invité de communiquer avec le kernel et le matériel comme l’hôte. Pour le reste, tu es dans le système invité et n’a accès qu’à ses propres paquets.

Une virtualisation de type conteneur ne devrait pas avoir des meilleures perfs au contraire, du fait qu’il n’y a pas émulation d’une machine complète (mais ne peut pas faire tourner des OS différents comme un hyperviseur type Xen/WMWare/qemu) ?

#7

Merci pour ces précision. bon je cherche encore un peux de documentation histoire dêtre sure que sa devrai du moins tourner :slightly_smiling: :006

#8

Une virtualisation de type conteneur ne devrait pas avoir des meilleures perfs au contraire, du fait qu’il n’y a pas émulation d’une machine complète (mais ne peut pas faire tourner des OS différents comme un hyperviseur type Xen/WMWare/qemu) ?[/quote]

Dans le cas de LXC la gestion des quota est possible au prix d’une compilation fastidieuse mais largement accessible.
Pour ce qui est de Qemu tout seul c’est mort archi mort, vmware j’en sais fichtre rien je n’y mets pas les pieds.

Plusieurs tutoriels m’ont servi à préparer un kernel je ferai un ajout dans la soirée lorsque je serai au taff (je ne l’ai pas sous la main pour l’instant).

#9

je suis le sujet parce que je m’apprête a me monter un serveur xen et je vais vouloir la 3d aussi.
mon retour d’expérience c’est que :

  • qemu très déçu, vraiment trop lent,
  • kvm lent aussi mais bien utilisable, les performances sont acceptables mais pas digne d’un esx
  • vmware workstation (version d’essai), hallucinant, le truc est super simple d’installation et plus performant que qemu ou kvm en plus l’utilisation est vraiment souple (surtout comparé au autre solution).
  • virtualbox, testé ya plus longtemps je me souviens plus par rapport a qemu et kvm, mais simple a mettre en place et a utiliser. Il est moins bien que workstation, mais c’est une bonne alternative. je crois qu’il est plus rapide que qemu.
  • esx très performant, mais c’est le plus contraignant, pour le matériel et puis trop fermé pour un serveur dédié
    en espérant que ça puisse un peu aidé :slightly_smiling: