Comme chaqun peut le constater, W7 consome moitié moins de RAM pour des
performances supérieurs
Ce miracle est dû à MinWin, le nouveau kernel en chantier depuis Vista,
qui équipe déjà Windows 2008
MinWin a permis de défaire les imbrications créées au fil des ans par
les développeurs de MS, permettant maintenant de supprimer
selectivement les composants fondamentaux du système
Selon OSNEWS, ce qui est intéressant, c'est que les entrées / sorties
de MinWin ont été concues selon un model UNIX qui semblerait fortement
identique à BSD, et le site va même plus loin, en pensant qu'il s'agit
probablement d'une reprise complète du noyau BSD, ce qui expliquerait
la rapidité de sortie de W7, à peine 2 ans après Vista
Surprise surprise: Il s'agit donc bien d'un moteur de type Linux qui
équipe les entrailles de Windows 7
> Dernière chose, tu peux essayer d'avoir le mot de la fin en continuant à raconter n'importe quoi. Je te rappelle que tu ne m'as toujours pas donné un seul argument sérieux en faveur de la virtualisation. Lorsque tu en auras un (juste un seul, mais un sérieux, un truc qu'on ne pourrait pas faire simplement sans virtualisation), on pourra recommencer. Pour l'instant, j'ai d'autres choses à faire.
JKB
Ben mon employeur EXIGE que j'utilise un logiciel qui tourne sur un OS (très rarement mais c'est impératif) et moi pour tout le reste j'utilise un autre OS... Je fais comment?
> Dernière chose, tu peux essayer d'avoir le mot de la fin en
continuant à raconter n'importe quoi. Je te rappelle que tu ne m'as
toujours pas donné un seul argument sérieux en faveur de la
virtualisation. Lorsque tu en auras un (juste un seul, mais un sérieux,
un truc qu'on ne pourrait pas faire simplement sans virtualisation), on pourra
recommencer. Pour l'instant, j'ai d'autres choses à faire.
JKB
Ben mon employeur EXIGE que j'utilise un logiciel qui tourne
sur un OS (très rarement mais c'est impératif) et moi pour tout le reste
j'utilise un autre OS...
Je fais comment?
> Dernière chose, tu peux essayer d'avoir le mot de la fin en continuant à raconter n'importe quoi. Je te rappelle que tu ne m'as toujours pas donné un seul argument sérieux en faveur de la virtualisation. Lorsque tu en auras un (juste un seul, mais un sérieux, un truc qu'on ne pourrait pas faire simplement sans virtualisation), on pourra recommencer. Pour l'instant, j'ai d'autres choses à faire.
JKB
Ben mon employeur EXIGE que j'utilise un logiciel qui tourne sur un OS (très rarement mais c'est impératif) et moi pour tout le reste j'utilise un autre OS... Je fais comment?
JKB
Le 12-03-2009, ? propos de Re: La surprise de W7 que l'on attendit pas..., Tanguy Briancon ?crivait dans fr.comp.os.linux.debats :
Dernière chose, tu peux essayer d'avoir le mot de la fin en continuant à raconter n'importe quoi. Je te rappelle que tu ne m'as toujours pas donné un seul argument sérieux en faveur de la virtualisation. Lorsque tu en auras un (juste un seul, mais un sérieux, un truc qu'on ne pourrait pas faire simplement sans virtualisation), on pourra recommencer. Pour l'instant, j'ai d'autres choses à faire.
JKB
Ben mon employeur EXIGE que j'utilise un logiciel qui tourne sur un OS (très rarement mais c'est impératif) et moi pour tout le reste j'utilise un autre OS... Je fais comment?
On n'est plus dans le domaine du technique. Effectivement, si tu as un bout de code écrit en Macro32, tu vas soit émuler un VAX soit trouver un vrai VAX, mais c'est quelque chose qui touche très peu de monde.* Maintenant, si ton employeur exige quelque chose, je suppose aussi que les postes informatiques sont équipés par défaut de l'OS en question.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 12-03-2009, ? propos de
Re: La surprise de W7 que l'on attendit pas...,
Tanguy Briancon ?crivait dans fr.comp.os.linux.debats :
Dernière chose, tu peux essayer d'avoir le mot de la fin en
continuant à raconter n'importe quoi. Je te rappelle que tu ne m'as
toujours pas donné un seul argument sérieux en faveur de la
virtualisation. Lorsque tu en auras un (juste un seul, mais un sérieux,
un truc qu'on ne pourrait pas faire simplement sans virtualisation), on pourra
recommencer. Pour l'instant, j'ai d'autres choses à faire.
JKB
Ben mon employeur EXIGE que j'utilise un logiciel qui tourne
sur un OS (très rarement mais c'est impératif) et moi pour tout le reste
j'utilise un autre OS...
Je fais comment?
On n'est plus dans le domaine du technique. Effectivement, si tu as
un bout de code écrit en Macro32, tu vas soit émuler un VAX soit trouver
un vrai VAX, mais c'est quelque chose qui touche très peu de monde.*
Maintenant, si ton employeur exige quelque chose, je
suppose aussi que les postes informatiques sont équipés par défaut de
l'OS en question.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 12-03-2009, ? propos de Re: La surprise de W7 que l'on attendit pas..., Tanguy Briancon ?crivait dans fr.comp.os.linux.debats :
Dernière chose, tu peux essayer d'avoir le mot de la fin en continuant à raconter n'importe quoi. Je te rappelle que tu ne m'as toujours pas donné un seul argument sérieux en faveur de la virtualisation. Lorsque tu en auras un (juste un seul, mais un sérieux, un truc qu'on ne pourrait pas faire simplement sans virtualisation), on pourra recommencer. Pour l'instant, j'ai d'autres choses à faire.
JKB
Ben mon employeur EXIGE que j'utilise un logiciel qui tourne sur un OS (très rarement mais c'est impératif) et moi pour tout le reste j'utilise un autre OS... Je fais comment?
On n'est plus dans le domaine du technique. Effectivement, si tu as un bout de code écrit en Macro32, tu vas soit émuler un VAX soit trouver un vrai VAX, mais c'est quelque chose qui touche très peu de monde.* Maintenant, si ton employeur exige quelque chose, je suppose aussi que les postes informatiques sont équipés par défaut de l'OS en question.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Professeur M
Le Wed, 11 Mar 2009 03:45:45 -0700, totof2000 a écrit :
je ne pouvais taper un texte sans oublier au moins un caractère par phrase ...
C'st pnible es clavers ui s blo
Le Wed, 11 Mar 2009 03:45:45 -0700, totof2000 a écrit :
je ne pouvais taper un texte sans oublier au moins un caractère
par phrase ...
Le Wed, 11 Mar 2009 03:45:45 -0700, totof2000 a écrit :
je ne pouvais taper un texte sans oublier au moins un caractère par phrase ...
C'st pnible es clavers ui s blo
Kevin Denis
Le 12-03-2009, Thierry Herbelot a écrit :
J'avoue avoir du mal en quoi ça permet de se passer avec avantage de la virtualisation; ca me semble complètement orthogonal comme principe: 'n' machines, '1' système, Versus '1' machine, 'n' systèmes.
un avantage de la virtualisation pour le SSI est de banaliser la ressource "machine" : le cluster est construit avec N ressources machine, qui sont implantées sur N+P bécanes
J'ai du mal à comprendre. Ton cluster SSI est bati sur des machines virtuelles?
(donc intérêt pour la maintenance : il suffit de migrer une tâche d'une bécane à une autre pour permettre un changement de noyau, sans arrêter le cluster complet ; idem éventuellement pour contourner une panne de bécane, ou pour upgrader le hard)
Tout à fait. Note bien que c'est tout à fait possible de migrer à chaud des machines virtualisées[1]. Mais encore une fois, pour moi le SSI et la virtualisation n'ont tout simplement rien à voir. A problèmes différents, réponses différentes. Dans mon cas, le SSI est tout
[1]En véritable à chaud, ou un "à chaud" mais à froid (on fige la machine virtuelle, on la déplace de machine physique, on la relance; les processus n'ont jamais été stoppés). -- Kevin
Le 12-03-2009, Thierry Herbelot <thierry.herbelot@free.fr> a écrit :
J'avoue avoir du mal en quoi ça permet de se passer avec avantage
de la virtualisation; ca me semble complètement orthogonal comme
principe: 'n' machines, '1' système, Versus '1' machine, 'n' systèmes.
un avantage de la virtualisation pour le SSI est de banaliser la
ressource "machine" : le cluster est construit avec N ressources machine,
qui sont implantées sur N+P bécanes
J'ai du mal à comprendre. Ton cluster SSI est bati sur des machines
virtuelles?
(donc intérêt pour la maintenance : il suffit de migrer une tâche d'une
bécane à une autre pour permettre un changement de noyau, sans arrêter le
cluster complet ; idem éventuellement pour contourner une panne de bécane,
ou pour upgrader le hard)
Tout à fait. Note bien que c'est tout à fait possible de migrer à chaud
des machines virtualisées[1]. Mais encore une fois, pour moi le SSI et
la virtualisation n'ont tout simplement rien à voir. A problèmes
différents, réponses différentes. Dans mon cas, le SSI est tout
[1]En véritable à chaud, ou un "à chaud" mais à froid (on fige la machine
virtuelle, on la déplace de machine physique, on la relance; les
processus n'ont jamais été stoppés).
--
Kevin
J'avoue avoir du mal en quoi ça permet de se passer avec avantage de la virtualisation; ca me semble complètement orthogonal comme principe: 'n' machines, '1' système, Versus '1' machine, 'n' systèmes.
un avantage de la virtualisation pour le SSI est de banaliser la ressource "machine" : le cluster est construit avec N ressources machine, qui sont implantées sur N+P bécanes
J'ai du mal à comprendre. Ton cluster SSI est bati sur des machines virtuelles?
(donc intérêt pour la maintenance : il suffit de migrer une tâche d'une bécane à une autre pour permettre un changement de noyau, sans arrêter le cluster complet ; idem éventuellement pour contourner une panne de bécane, ou pour upgrader le hard)
Tout à fait. Note bien que c'est tout à fait possible de migrer à chaud des machines virtualisées[1]. Mais encore une fois, pour moi le SSI et la virtualisation n'ont tout simplement rien à voir. A problèmes différents, réponses différentes. Dans mon cas, le SSI est tout
[1]En véritable à chaud, ou un "à chaud" mais à froid (on fige la machine virtuelle, on la déplace de machine physique, on la relance; les processus n'ont jamais été stoppés). -- Kevin
Thierry Herbelot
Kevin Denis wrote:
Le 12-03-2009, Thierry Herbelot a écrit :
J'avoue avoir du mal en quoi ça permet de se passer avec avantage de la virtualisation; ca me semble complètement orthogonal comme principe: 'n' machines, '1' système, Versus '1' machine, 'n' systèmes.
un avantage de la virtualisation pour le SSI est de banaliser la ressource "machine" : le cluster est construit avec N ressources machine, qui sont implantées sur N+P bécanes
J'ai du mal à comprendre. Ton cluster SSI est bati sur des machines virtuelles?
(donc intérêt pour la maintenance : il suffit de migrer une tâche d'une bécane à une autre pour permettre un changement de noyau, sans arrêter le cluster complet ; idem éventuellement pour contourner une panne de bécane, ou pour upgrader le hard)
Tout à fait. Note bien que c'est tout à fait possible de migrer à chaud des machines virtualisées[1]. Mais encore une fois, pour moi le SSI et la virtualisation n'ont tout simplement rien à voir. A problèmes
on peut aussi voir clustering et virtualisation comme deux faces de l'abstraction de la ressource "machine" (mettre à disposition une certaine quantité de puissance de calcul, sans que l'utilisateur ait à se préoccuper de la réalité physique : est-ce que j'ai un gros serveur avec 4 sockets qui contiennent des CPU 4-coeurs ou bien est-ce une grappe de 16 PC qui communiquent par un Ethernet ?)
*si* les jobs de calcul sont suffisamment bien écrits (pas de couplage par des variables partagées, par exemple), les deux architectures doivent être comparables.
TfH
PS : dans un domaine connexe, ZFS est un bon exmple d'abstraction des ressources physiques (combinaison de disques durs, pour constituer un zpool unique, que l'utilisateur ensuite découpe à la demande - avec en plus des propriétés de correction de pannes)
différents, réponses différentes. Dans mon cas, le SSI est tout
[1]En véritable à chaud, ou un "à chaud" mais à froid (on fige la machine virtuelle, on la déplace de machine physique, on la relance; les processus n'ont jamais été stoppés).
Kevin Denis wrote:
Le 12-03-2009, Thierry Herbelot <thierry.herbelot@free.fr> a écrit :
J'avoue avoir du mal en quoi ça permet de se passer avec avantage
de la virtualisation; ca me semble complètement orthogonal comme
principe: 'n' machines, '1' système, Versus '1' machine, 'n' systèmes.
un avantage de la virtualisation pour le SSI est de banaliser la
ressource "machine" : le cluster est construit avec N ressources machine,
qui sont implantées sur N+P bécanes
J'ai du mal à comprendre. Ton cluster SSI est bati sur des machines
virtuelles?
(donc intérêt pour la maintenance : il suffit de migrer une tâche d'une
bécane à une autre pour permettre un changement de noyau, sans arrêter le
cluster complet ; idem éventuellement pour contourner une panne de
bécane, ou pour upgrader le hard)
Tout à fait. Note bien que c'est tout à fait possible de migrer à chaud
des machines virtualisées[1]. Mais encore une fois, pour moi le SSI et
la virtualisation n'ont tout simplement rien à voir. A problèmes
on peut aussi voir clustering et virtualisation comme deux faces de
l'abstraction de la ressource "machine" (mettre à disposition une certaine
quantité de puissance de calcul, sans que l'utilisateur ait à se préoccuper
de la réalité physique : est-ce que j'ai un gros serveur avec 4 sockets qui
contiennent des CPU 4-coeurs ou bien est-ce une grappe de 16 PC qui
communiquent par un Ethernet ?)
*si* les jobs de calcul sont suffisamment bien écrits (pas de couplage par
des variables partagées, par exemple), les deux architectures doivent être
comparables.
TfH
PS : dans un domaine connexe, ZFS est un bon exmple d'abstraction des
ressources physiques (combinaison de disques durs, pour constituer un zpool
unique, que l'utilisateur ensuite découpe à la demande - avec en plus des
propriétés de correction de pannes)
différents, réponses différentes. Dans mon cas, le SSI est tout
[1]En véritable à chaud, ou un "à chaud" mais à froid (on fige la machine
virtuelle, on la déplace de machine physique, on la relance; les
processus n'ont jamais été stoppés).
J'avoue avoir du mal en quoi ça permet de se passer avec avantage de la virtualisation; ca me semble complètement orthogonal comme principe: 'n' machines, '1' système, Versus '1' machine, 'n' systèmes.
un avantage de la virtualisation pour le SSI est de banaliser la ressource "machine" : le cluster est construit avec N ressources machine, qui sont implantées sur N+P bécanes
J'ai du mal à comprendre. Ton cluster SSI est bati sur des machines virtuelles?
(donc intérêt pour la maintenance : il suffit de migrer une tâche d'une bécane à une autre pour permettre un changement de noyau, sans arrêter le cluster complet ; idem éventuellement pour contourner une panne de bécane, ou pour upgrader le hard)
Tout à fait. Note bien que c'est tout à fait possible de migrer à chaud des machines virtualisées[1]. Mais encore une fois, pour moi le SSI et la virtualisation n'ont tout simplement rien à voir. A problèmes
on peut aussi voir clustering et virtualisation comme deux faces de l'abstraction de la ressource "machine" (mettre à disposition une certaine quantité de puissance de calcul, sans que l'utilisateur ait à se préoccuper de la réalité physique : est-ce que j'ai un gros serveur avec 4 sockets qui contiennent des CPU 4-coeurs ou bien est-ce une grappe de 16 PC qui communiquent par un Ethernet ?)
*si* les jobs de calcul sont suffisamment bien écrits (pas de couplage par des variables partagées, par exemple), les deux architectures doivent être comparables.
TfH
PS : dans un domaine connexe, ZFS est un bon exmple d'abstraction des ressources physiques (combinaison de disques durs, pour constituer un zpool unique, que l'utilisateur ensuite découpe à la demande - avec en plus des propriétés de correction de pannes)
différents, réponses différentes. Dans mon cas, le SSI est tout
[1]En véritable à chaud, ou un "à chaud" mais à froid (on fige la machine virtuelle, on la déplace de machine physique, on la relance; les processus n'ont jamais été stoppés).
Professeur M
Le Wed, 11 Mar 2009 14:23:35 +0100, Cumbalero a écrit :
Historiquement, rien n'a jamais obligé une bactérie à se transformer en être pluricellulaire. On a pourtant vu le résultat.
Et il n'est pas joli...
Méph' pessimiste aujourd'hui...
Le Wed, 11 Mar 2009 14:23:35 +0100, Cumbalero a écrit :
Historiquement, rien n'a jamais obligé une bactérie à se transformer en
être pluricellulaire. On a pourtant vu le résultat.
Le Wed, 11 Mar 2009 14:23:35 +0100, Cumbalero a écrit :
Historiquement, rien n'a jamais obligé une bactérie à se transformer en être pluricellulaire. On a pourtant vu le résultat.
Et il n'est pas joli...
Méph' pessimiste aujourd'hui...
talon
Cumbalero wrote:
Michel Talon a écrit :
> Il y a surtout que tu fais preuve d'une mauvaise foi énorme, car je n'ai > jamais parlé de la "production", mais de ce qui est vrai en théorie, et > pour tout te dire, la "production" je m'en fous comme de ma première > chemise.
Tu noteras que dans une autre partie du thread, je donne un exemple de ce que m'apporte la virtualisation, étant moi-même dans une équipe de production.
La prod, c'est ce qu'il y a d'essentiel pour une entreprise, les développeurs, architectes et autres oublient souvent cette donnée. Mais bon, grâce à leur mauvais travail, j'ai du boulot....
Je comprends bien, je ne nie pas que cette solution soit utile dans ce milieu, je ne le connais pas. Je dis simplement que, en théorie, la virtualisation consomme inutilement des ressources, ce qui est une évidence. Si tu avais un site web très chargé, tu te préoccuperais de mettre en pool plusieurs machines pour le servir et non pas de faire tourner 5 machines virtuelles sur un PC totalement sous occupé. Plus la virtualisation est légère moins elle consomme de ressources, c'est pourquoi je disais que les jails de FreeBSD sont à mon avis plus sympathiques, pour préparer des choses sans toucher au système de bases, pour isoler ds services, etc. Evidemment ça ne résout pas le problème de la base Oracle qui ne tourne que sur telle version de RedHat. Celà étant, se payer une fortune pour avoir Oracle, et le faire tourner dans une machine virtuelle, il faut être un peu bizarre ...
A+ JF
--
Michel TALON
Cumbalero <cumbalero@nospam.yahoo.fr> wrote:
Michel Talon a écrit :
> Il y a surtout que tu fais preuve d'une mauvaise foi énorme, car je n'ai
> jamais parlé de la "production", mais de ce qui est vrai en théorie, et
> pour tout te dire, la "production" je m'en fous comme de ma première
> chemise.
Tu noteras que dans une autre partie du thread, je donne un exemple de
ce que m'apporte la virtualisation, étant moi-même dans une équipe de
production.
La prod, c'est ce qu'il y a d'essentiel pour une entreprise, les
développeurs, architectes et autres oublient souvent cette donnée. Mais
bon, grâce à leur mauvais travail, j'ai du boulot....
Je comprends bien, je ne nie pas que cette solution soit utile dans ce
milieu, je ne le connais pas. Je dis simplement que, en théorie, la
virtualisation consomme inutilement des ressources, ce qui est une
évidence. Si tu avais un site web très chargé, tu te préoccuperais de
mettre en pool plusieurs machines pour le servir et non pas de faire
tourner 5 machines virtuelles sur un PC totalement sous occupé.
Plus la virtualisation est légère moins elle consomme de ressources,
c'est pourquoi je disais que les jails de FreeBSD sont à mon avis plus
sympathiques, pour préparer des choses sans toucher au système de bases,
pour isoler ds services, etc. Evidemment ça ne résout pas le problème de
la base Oracle qui ne tourne que sur telle version de RedHat. Celà
étant, se payer une fortune pour avoir Oracle, et le faire tourner dans
une machine virtuelle, il faut être un peu bizarre ...
> Il y a surtout que tu fais preuve d'une mauvaise foi énorme, car je n'ai > jamais parlé de la "production", mais de ce qui est vrai en théorie, et > pour tout te dire, la "production" je m'en fous comme de ma première > chemise.
Tu noteras que dans une autre partie du thread, je donne un exemple de ce que m'apporte la virtualisation, étant moi-même dans une équipe de production.
La prod, c'est ce qu'il y a d'essentiel pour une entreprise, les développeurs, architectes et autres oublient souvent cette donnée. Mais bon, grâce à leur mauvais travail, j'ai du boulot....
Je comprends bien, je ne nie pas que cette solution soit utile dans ce milieu, je ne le connais pas. Je dis simplement que, en théorie, la virtualisation consomme inutilement des ressources, ce qui est une évidence. Si tu avais un site web très chargé, tu te préoccuperais de mettre en pool plusieurs machines pour le servir et non pas de faire tourner 5 machines virtuelles sur un PC totalement sous occupé. Plus la virtualisation est légère moins elle consomme de ressources, c'est pourquoi je disais que les jails de FreeBSD sont à mon avis plus sympathiques, pour préparer des choses sans toucher au système de bases, pour isoler ds services, etc. Evidemment ça ne résout pas le problème de la base Oracle qui ne tourne que sur telle version de RedHat. Celà étant, se payer une fortune pour avoir Oracle, et le faire tourner dans une machine virtuelle, il faut être un peu bizarre ...
A+ JF
--
Michel TALON
totof2000
> se payer une fortune pour avoir Oracle, et le faire tourner dans une machine virtuelle, il faut être un peu bizarre ...
Si tu savais le nombre de choses bizarre que l'on trouve dans des environnements de production ...... Ca c'est rien à côté.
> se payer une fortune pour avoir Oracle, et le faire tourner dans
une machine virtuelle, il faut être un peu bizarre ...
Si tu savais le nombre de choses bizarre que l'on trouve dans des
environnements de production ...... Ca c'est rien à côté.
> Je comprends bien, je ne nie pas que cette solution soit utile dans ce milieu, je ne le connais pas. Je dis simplement que, en théorie, la virtualisation consomme inutilement des ressources, ce qui est une évidence.
Oui .... Cependant si l'appli n'utilise que 20% des ressources disponibles sur le serveur, et qu'il reste 80% de ressources disponibles, les ressources en question ne sont pas consommées mais elles restent gachées. Par contre si tu as trois ou quatre applis consommant 20% de tes ressources serveur, et nécessitant 3 versions d'OS différentes, tu as tout intérêt à virtualiser, plutôt que d'acheter 3 serveurs dédi és, et il te reste de la marge pour gérer le surcout de la virtualisation .... Tu peux envisager ce genre de scénario également sur deux applis qui utiliserainet les ressources à des heures différentes : une appli A qui est essentiellement utilisée la journée , et une appli B qui est utilisé la nuit pour des traitements batch par exemple. En virtualisant et en gérant l'allocation des ressources ça peut permettre d'économiser un serveur.
> Je comprends bien, je ne nie pas que cette solution soit utile dans ce
milieu, je ne le connais pas. Je dis simplement que, en théorie, la
virtualisation consomme inutilement des ressources, ce qui est une
évidence.
Oui .... Cependant si l'appli n'utilise que 20% des ressources
disponibles sur le serveur, et qu'il reste 80% de ressources
disponibles, les ressources en question ne sont pas consommées mais
elles restent gachées.
Par contre si tu as trois ou quatre applis consommant 20% de tes
ressources serveur, et nécessitant 3 versions d'OS différentes, tu as
tout intérêt à virtualiser, plutôt que d'acheter 3 serveurs dédi és, et
il te reste de la marge pour gérer le surcout de la
virtualisation .... Tu peux envisager ce genre de scénario également
sur deux applis qui utiliserainet les ressources à des heures
différentes : une appli A qui est essentiellement utilisée la journée ,
et une appli B qui est utilisé la nuit pour des traitements batch par
exemple. En virtualisant et en gérant l'allocation des ressources ça
peut permettre d'économiser un serveur.
> Je comprends bien, je ne nie pas que cette solution soit utile dans ce milieu, je ne le connais pas. Je dis simplement que, en théorie, la virtualisation consomme inutilement des ressources, ce qui est une évidence.
Oui .... Cependant si l'appli n'utilise que 20% des ressources disponibles sur le serveur, et qu'il reste 80% de ressources disponibles, les ressources en question ne sont pas consommées mais elles restent gachées. Par contre si tu as trois ou quatre applis consommant 20% de tes ressources serveur, et nécessitant 3 versions d'OS différentes, tu as tout intérêt à virtualiser, plutôt que d'acheter 3 serveurs dédi és, et il te reste de la marge pour gérer le surcout de la virtualisation .... Tu peux envisager ce genre de scénario également sur deux applis qui utiliserainet les ressources à des heures différentes : une appli A qui est essentiellement utilisée la journée , et une appli B qui est utilisé la nuit pour des traitements batch par exemple. En virtualisant et en gérant l'allocation des ressources ça peut permettre d'économiser un serveur.
