La virtualisation des serveurs a donné d'énormes batailles et ça continue. Les enjeux sont énormes.
Par contre, on parle moins de la virtualisation appliquée au desktop. On en parle principalement pour les développeurs et quelques niches.
Pourtant les enjeux sont tout aussi énormes (du moins si ça marche :-) et pour les entreprises). Technologiquement on peut considérer que ce n'est qu'une extension de ce qui se fait déjà pour les serveurs. Une extension, mais une grosse.
Dans ce domaine, et à ma connaissance, il y a principalement Xen (avec XenDesktop), KVM (avec Solid Ice) et Microsoft (avec je-ne-sais-pas-quoi). C'est très très schématique (probablement incomplet, voire faux) et ça utilise beaucoup de proprio. Notons, et c'est logique, ça cible actuellement principalement le desktop Windows.
Ici le logiciel libre a du retard.
L'une des solutions semblant les plus avancées a été développée par Qumranet (Solid Ice).
Démo de la partie cliente : http://www.youtube.com/watch?v=S4DZwYqnyJM
On trouvera une description de Solid Ice ici :
http://us.qumranet.com/videos/Qumranet.wmv
On trouvera plein d'autres informations sur le site de Qumranet : http://www.qumranet.com/
On le sait, Red Hat a acheté Qumranet :
L'annonce : http://www.redhat.com/about/news/prarchive/2008/qumranet.htm(...)
Coût : 107 millions de $ ! Un putain de gros chiffre dans le libre.
KVM étant déjà libre, quoi attendre de plus ?
Red Hat a toujours été vague. De l'annonce on a seulement :
And, equally important, Red Hat's commitment to open source means that our technologies can be shared, improved and enjoyed by the entire open source industry.
Encouragant mais vague.
Il n'y a qu'au travers de Fedora qu'on pouvait se faire une idée. Il est apparu claire que Red Hat abandonnait Xen pour KVM. Par contre côté discours officiels chez Red Hat, rien ou presque. S'il était demandé si RHEL 6 utiliserait KVM au-lieu de Xen, on n'avait seulement un "s'il y a changement de technologie, ça ne posera pas de problème puisqu'on utilise libvirt". Maigre.
Aujourd'hui, dans le coin "presse" de Red Hat on a eu ça :
http://www.press.redhat.com/2009/02/18/whats-on-brians-mind-qumranet-virtualization/
What’s on Brian’s Mind? Qumranet & Virtualization (traduction libre : qu'il y a-t-il actuellement dans la tête de Brian ? Qumranet & Virtualisation).
Brian Stevens est vice président et un responsable technique de Red Hat. C'est du "lourd".
Sur la forme, c'est très informel pour ne pas dire "ridicule". Aucun texte n'accompagne la vidéo. Par contre c'est dans la section "presse" et non sur http://magazine.redhat.com/ . C'est informel mais bien officiel.
Un résumé pour ceux qui ne causent pas anglais (NB: je suis mauvais en anglais) :
- L'achat de Qumranet est seulement de 4 mois et l'intégration de Qumranet à Red Hat n'a pas encore été finalisée.
- Qumranet est centré sur la gestion et exclusivement sur le desktop.
- Red Hat a travaillé ces 5 dernières années sur Xen et continuera.
- Xen est, malheureusement, seulement adapté aux serveurs.
- Il faut autre chose qui couvre un spectre plus large, plus ambitieux, et c'est KVM.
- KVM c'est grandement amélioré ces derniers mois.
- La technologie la plus remarquable chez Qumranet est SPICE.
- SPICE est la futur génération de protocole de bureau distant.
- Par rapport aux concurrents, le point fort de SPICE est la performance.
- Nous sommes presque sur le point de rendre cette technologie libre.
- SPICE sera le standard ouvert d'affichage de bureau virtualisé. Pas uniquement pour Linux, mais pour toute plateforme de virtualisation.
- Il est temps de fournir ces technologies à nos clients.
Clairement SPICE sera ouvert/libéré. J'en ai aucun doute pour la partie Linux et c'est vraiment une excellente nouvelle. Est-ce que les drivers que demandent SPICE pour Windows seront libérés ? Aucune idée. Est-ce que Solid ICE, la partie serveur/gestion qui tourne sous LInux, sera libéré ? Aucune idée encore. Mais on peut avoir de bon espoir avec Red Hat ici.
Red Hat est toujours discret sur les technologies lorsqu'il sagit de son avenir. Il semble que Red Hat a été poussé d'ouvrir un peu le coin du voile, afin que ceux qui veulent investir dans le desktop virtualisé le fasse sur SPICE au-lieu de s'égarer ailleurs (ce domaine étant chaud). Red Hat veut dès maintenant donner un signal. Misez sur SPICE, c'est plus performant que les autres, ça sera ouvert et libre.
Pourquoi maintenant et d'une certaine manière si mal ?
Peut-être car le récent accord entre Red Hat et MS sur la virtualisation ne parlait pas du tout des OS Windows desktop mais seulement des Windows serveur. Red Hat veut rappeler qu'il a des ambitions dans la virtualisation Desktop et place maintenant quelques points.
PS : désolé pour les vidéos aux formats proprios.
Journal SPICE libéré ! (bientôt)
19
fév.
2009
# Erreur de lien ?
Posté par slubman (site web personnel, Mastodon) . Évalué à 5.
[^] # Re: Erreur de lien ?
Posté par IsNotGood . Évalué à 4.
# Explications?
Posté par claudex . Évalué à 6.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Explications?
Posté par IsNotGood . Évalué à 5.
Un desktop virtualisé a les mêmes besoins qu'un serveur mais s'ajoute :
- affichage rapide (et sans bouffer trop de bande passante)
- pouvoir utiliser les périphériques USB local à la machine (et pas sur le serveur où est virtualisé le desktop)
- utiliser la carte son de la machine local
- etc
Le problème est l'utilisation à distance du desktop virtualisé.
[^] # Re: Explications?
Posté par Prosper . Évalué à 3.
- affichage rapide (et sans bouffer trop de bande passante)
- pouvoir utiliser les périphériques USB local à la machine (et pas sur le serveur où est virtualisé le desktop)
- utiliser la carte son de la machine local
- etc
On appelle ça un Connection Broker ( ce qu'est en gros SolidICE ) , ça a rien de nouveau , ça existait déjà avant la virtualisation des desktops , avec MS terminal service ou citrix metaframe et les terminaux wise et compagnie.
[^] # Re: Explications?
Posté par IsNotGood . Évalué à 2.
Tu prouves mon intérêt tout récent dans le domaine :-)
> On appelle ça un Connection Broker ( ce qu'est en gros SolidICE )
Solid ICE utilise SPICE (et KVM, etc) et n'est pas qu'un Connection Broker.
SPICE est (peut-être) un Connection Broker.
[^] # Re: Explications?
Posté par claudex . Évalué à 2.
Je me demande aussi quel est l'intérêt d'une telle technologie (dans le sens, dans quel cas est-ce utilisé). Je vois ça notamment pour permettre à des employé d'avoir accès de n'importe où à leur ordinateur du bureau (données et logiciels) de façon sécurisée. Mais dans ce cas, je ne vois que peu l'intérêt de transmettre le son ou la clef usb (un répertoire partagé avec l'OS hôte suffirait à mon avis).
Cette solution ne fait-elle que rendre un accès SSH (ou un équivalent) plus convivial ou il y a-t'il d'autres utilités?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Explications?
Posté par pasBill pasGates . Évalué à 5.
Ton OS desktop tourne en version 4.
T'as une app tres importante qui ne tourne que sur la version 3.
Tu installes cette app (et tout le baratin que le systeme de virtualisation demande) sur ton serveur, le soft de virtualisation sur ton desktop, et ton app devient utilisable sur le desktop en version 4 avec le tout integre : imprimantes, cles USB, son, ...
Evidemment dans les entreprises, c'est d'habitude plus d'un soft qui est concerne, et un tas de desktops qui en ont besoin, ce qui rend la chose interessante.
[^] # Re: Explications?
Posté par plagiats . Évalué à -6.
... version 3 ...
... caractère 2 ( http://linuxfr.org/comments/1006971,1.html ) ...
Tu baisses, tu baisses...
[^] # Re: Explications?
Posté par IsNotGood . Évalué à 4.
Je ne suis pas le mieux placé pour en parler, je connais peu ce domaine.
Le gros intérêt est (le faible) coût.
Imagine une entreprise avec 200 postes clients.
Actuellement on installe un poste par utilisateur avec un disque dur de 150 Go, 2 Go de mémoire, un cpu costaud (même si l'utilisateur n'en a pas besoin car on ne sait jamais), etc.
Demain, ça sera un poste léger par utilisateur. Le poste aura une carte son, une bonne carte graphique (sans plus), pas de disque dur, peu de mémoire (256 Mo), une bonne carte réseau. Ce poste léger est vraiment léger. Il consomme peu de courant, n'a pas de ventileur, etc. Ce poste léger boot sur le réseau et lance un mini OS qui lui permet seulement de se connecter a son desktop virtualisé.
Les desktops virtualisés seront dans un data-center.
Si un disque merde, on le change dans le data-center. Comme tout est redondant, l'utilisateur ne remarque rien. Si un utilisateur a besoin de beaucoup de cpu, on change la configuration de son desktop virtualisé au lieu de lui acheter un PC tout neuf, etc. S'il faut migrer des postes de bidule x à bidule x+1, pas besoin de se déplacer, tout peut être fait dans le data-center et tout est accessible à distance.
Au moins sur le papier, ça réduit énormément les coûts. Par contre il faut réseau assez costaud.
Autre avantage, l'utilisateur n'est plus lié à un poste. Il prend n'importe quel poste léger de l'entreprise et utilise son desktop virtualisé.
On n'est pas obligé d'avoir un desktop virtualisé par utilisateur. On peut avoir un serveur (probablement virtualisé) qui sert plusieurs utilisateurs. Il n'y aura pas qu'un serveur, mais plusieurs (par exemple pour 20 utilisateurs mais pas pour tous les utilisateurs).
> Mais dans ce cas, je ne vois que peu l'intérêt de transmettre le son ou la clef usb
La clé USB car c'est un moyen d'échange courant. Le son pour youtube ou voir l'enregistrement de la conférence du boss. Le but est de remplacer les PC actuel par des postes légers. Il faut que l'utilisateur y retrouve quasiment le même confort.
[^] # Re: Explications?
Posté par Psychofox (Mastodon) . Évalué à 7.
D'ailleurs, je ne comprends pas vraiment ce que prétendent offrir de plus les solutions de virtualisation dans ce domaine la.
[^] # Re: Explications?
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 10.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Explications?
Posté par Larry Cow . Évalué à 3.
Un mélange des deux mondes?
Avec une solution à base de terminaux telle qu'on en fait sans virtualisation, ça veut dire un OS serveur "sur mesure", et commun à tous les clients. Ce qui a les inconvénients suivants :
- difficulté (voire impossibilité) de faire tourner les OS desktops de son choix. Exit WinXP (pas forcément un mal).
- homogénéité "forcée". C'est souvent souhaitable, mais parfois on aime avoir _un_ poste avec une configuration radicalement différente (le graphiste qui a absolument besoin d'un Windows alors que tout le monde est sous Solaris, par exemple).
- isolation limitée des ressources. Si un utilisateur fait planter ou encombre le serveur (avec un "vrai" OS, ça ne devrait pas arriver, cela-dit), les applications de tout le monde en pâtissent.
- pour limiter l'impact du point précédent, on est donc plus ou moins forcés de mettre en place des permissions bien restrictives à chacun. C'est parfois souhaitable, mais pas toujours.
Avec une solution à base de virtualisation, en échange d'une demande un peu plus élevée en termes de ressources (bin oui, on ne mutualise plus l'OS, dans ce cas, mais seulement le matériel), on élimine tout ou partie de ces restrictions
- chaque utilisateur a sa propre machine, fut-elle virtuelle. Donc, potentiellement, l'OS de son choix.
- il pourra installer, si l'administrateur l'autorise, ce qu'il veut sur son poste.
- sans risquer de mettre ses collègues dans l'embarras (pas plus qu'avec des postes physiques séparés, en tous cas).
Sans compter qu'on pourrait panacher les deux approches, et faire tourner un (ou plusieurs) serveur de terminaux virtualisé pour le "tout venant", et des postes virtualisés spécifiques pour les besoins spécifiques.
[^] # Re: Explications?
Posté par briaeros007 . Évalué à 2.
dis plus simplement : les terminaux et la virtualisation ne répondent pas au même besoin ;)
Dans les terminaux, le besoin est d'avoir une administration simple et homogène de tous les postes. Cela implique des besoins proches. Alors certes avec la latitude de configuration des OS actuels, les besoins ne sont plus forcément si proche, mais le principe reste le même.
Le but est de l'économie sur de l'échelle.
Dans la virtualisation, le but est au contraire que chacun puisse avoir des besoins fondamentalement différents de son voisin, et donc une administration au "cas par cas".
[^] # Re: Explications?
Posté par B16F4RV4RD1N . Évalué à 2.
xendesktop, je vois que c'est lancé par citrix, qui à ma connaissance ne fait que du propriétaires. Je vois sur wikipedia que citrix a racheté xensource. Est-ce que xendesktop a des parties libres ? Comment peuvent-ils concillier les 2 ? (xen est sous gpl)
"virtualisation appliquée au desktop", cela ne concerne pas que les serveurs d'applications, chez moi j'utilise virtualbox pour faire tourner windows, freebsd et linux, c'est aussi une utilisation possible. Il aurait fallu préciser que tu comptais uniquement parler de l'affichage déporté de bureaux, lesquels bureaux sont virtualisés sur un serveur.
Ulteo propose cela également, et semble bien avancé ?
À noter que VirtualBox supporte RDP : http://www.ubuntugeek.com/vrdp-virtualbox-remote-desktop-pro(...)
Je viens de tester, j'ai lancé OpenSolaris dans un virtualbox sur mon ordinateur, et je me suis connecté depuis un windows sur un autre ordinateur, c'était bien rapide (plus que par vnc). Une piste à creuser.
Est-ce qu'une solution comme kvm/spice/ulteo serait plus adaptée, par exemple en mutualisant les ressources utilisées ? (Si par exemple plusieurs clients utilisent le même logiciel de messagerie ?)
Quid de NX, sur un serveur linux plus classique ?
(l'avantage de vrdp, freenx etc, c'est que c'est quand même plus rapide que X ou vnc sur une connexion internet)
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Explications?
Posté par Prosper . Évalué à 3.
xendesktop, je vois que c'est lancé par citrix, qui à ma connaissance ne fait que du propriétaires. Je vois sur wikipedia que citrix a racheté xensource. Est-ce que xendesktop a des parties libres ? Comment peuvent-ils concillier les 2 ? (xen est sous gpl)
Si je me trompe pas auparavant citrix avait fait evoluer son produit de "shared desktop" vers le virtual desktop en utilisant l'hypervieur ESX de vmware; ils ont acheté xensource pour ne plus dépendre de vmware et vendre ensuite leur solution complete et maitrisé de bout en bout appellée xendesktop qui s'appuie sur l'hyperviseur xen qui lui reste libre mais les bouts au dessus ( connection broker , xencenter ... ) sont proprios.
[^] # Re: Explications?
Posté par IsNotGood . Évalué à 3.
Pour l'OS virtualisé, il ne voit pas SPICE. Il voit une carte graphique ses capacités. Si la carte graphique peut décoder du mpeg, l'OS virtualisé envoit le mpeg à la carte graphique au lieu des trames en brut. Le décodage et l'affichage est fait sur le poste client.
Pour VNC, lorsqu'on déplace une fenètre, c'est deux copie d'écran différentes. Pour SPICE c'est "déplace le rectangle en x,y vers x', y'. Le poste client fera le reste.
Enfin SPICE ne s'occupe pas que de "rediriger" l'affichage. Il "connecte" le poste distant à la machine virtuelle (carte graphique, carte son, USB, webcam, etc). La machine virtuelle voit alors une carte son, une webcam, etc.
[^] # Re: Explications?
Posté par Psychofox (Mastodon) . Évalué à 3.
- il pourra installer, si l'administrateur l'autorise, ce qu'il veut sur son poste.
- sans risquer de mettre ses collègues dans l'embarras (pas plus qu'avec des postes physiques séparés, en tous cas).
En général, les sociétés qui passent par des systèmes de terminal serveurs du genre citrix, c'est parce qu'ils en ont marre des utilisateurs qui cassent tout sur leur poste.
Donc au final on perd cet avantage. La seule chose qui reste c'est la possibilité de revenir à un état initial plus rapidement via un snapshot, mais bon, ça n'empêche pas que si l'utilisateur est un neuneu, ça fera toujours des coups de fils en plus pour rien.
En général (en tout cas ça a été le cas de toutes les entreprises ou je suis allé), les gens qui veulent une machine séparée avec des droits admins, c'est soit :
-des chieurs ou des patrons : dans ce cas la de toute manière la virtualisation ne leur plaira pas plus car ils veulent un truc palpable qui est "à eux seuls".
-des nomades : dans ce cas la ils ont un laptop.
-quelqu'un qui a une appli métier spécifiques demandant beaucoup de ressources : dans ce cas la on leur donne une workstation bien boostée. Le graphiste dont tu parles plus haut ne se satisfiera pas d'une interface avec un potentiel lag par rapport à son input sur la carte graphique et il lui faudra de toute façon un écran 30" qui ne sera pas géré par un thin client.
-quelqu'un qui a une appli proprio chiante dont la protection de la copie se fait via un dongle. Dans ce cas la, même avec la meilleure interface du monde qui gère le usb, c'est une plaie à gérer avec une solution de virtualisation (j'imagine le hub géant avec 15 dongles). Le jour où tu mets en place ton serveur, t'es content ça marche, puis 2-3 ans après vient une norme différente de usb ou autre et un éditeur se met dans la tête que sont dongle utilisera cette norme. Bam ! nouveau cas spécifique et tu ne vas pas changer ton serveur de VM pour 1 utilisateur. Tu lui fournira de toute façon un pc.
En dehors de ça, il ne reste plus beaucoup de cas pratique pour lesquels la virtualisation peut répondre.
[^] # Re: Explications?
Posté par Prosper . Évalué à 2.
-quelqu'un qui a une appli proprio chiante dont la protection de la copie se fait via un dongle. Dans ce cas la, même avec la meilleure interface du monde qui gère le usb, c'est une plaie à gérer avec une solution de virtualisation (j'imagine le hub géant avec 15 dongles). Le jour où tu mets en place ton serveur, t'es content ça marche, puis 2-3 ans après vient une norme différente de usb ou autre et un éditeur se met dans la tête que sont dongle utilisera cette norme. Bam ! nouveau cas spécifique et tu ne vas pas changer ton serveur de VM pour 1 utilisateur. Tu lui fournira de toute façon un pc.
C'est justement le but du connection broker , ca permet de déporter les ports usb , les cartes son et autres joyeuseté . donc tu peux brancher ton dongle sur ton client leger ou ton poste de travail en utilisant ton desktop virtualisé , il sera vu coté vm .
[^] # Re: Explications?
Posté par Psychofox (Mastodon) . Évalué à 0.
De plus un connection borker ça marche bien dans des cas très généraux, mais dès que quelqu'un fait un truc de bas très standard mais qui marche en local parce qu'il y'a le driver qui va bien pour brancher tel hardware, ton connection broker sera à la rue.
[^] # Re: Explications?
Posté par Larry Cow . Évalué à 2.
C'est ça. On n'a jamais dit que la virtualisation (de ce type) remplaçait les serveurs de terminaux, juste que ça permettait une centralisation similaire pour les gens qui ont des besoins hétérogènes (et donc peu éligibles aux solutions à base de terminaux "à l'ancienne").
[^] # Re: Explications?
Posté par benoar . Évalué à 2.
[^] # Re: Explications?
Posté par IsNotGood . Évalué à 2.
Merci pour cette précieuse précision...
> D'ailleurs, je ne comprends pas vraiment ce que prétendent offrir de plus les solutions de virtualisation dans ce domaine la.
Tu peux généraliser et dire que la virtualisation pour les serveurs ne sert aussi à rien. La preuve, avant on en avait pas besoin.
[^] # Re: Explications?
Posté par Gniarf . Évalué à 2.
VMWare les a beaucoup fait rire quand c'est sorti en 98 ou 99. au début.
[^] # Re: Explications?
Posté par Psychofox (Mastodon) . Évalué à 4.
Beaucoup le disent. On ne les entend pas forcément dans les médias parce que le buzz actuel est de dire que c'est bien.
Personnellement je trouve que la virtualisation c'est bien dans des cas très précis :
-pour des labs de tests
-pour pouvoir se débarasser d'une vieille machine avec un vieil os qui ne serait plus supporté par du hardware moderne parce qu'un besoin légal nous demande de garder telle application et telles données pendant x années et qu'elle nous coûte cher en énergie et qu'elle ne serait plus maintenue en cas de panne hardware
Par contre pour de la prod, bof. A côté de certaines solutions commes les chroot, Jails ou les zones, non j'en vois peu l'intérêt (mais celles-ci sont souvent englobées dans le terme vague de virtualization).
[^] # Re: Explications?
Posté par IsNotGood . Évalué à 3.
On ne va pas faire dans les raisonnement simplistes ou qui ne sont qu'une sorte de réthorique.
Qu'il y ait du buzz actuellement n'implique pas qu'il n'y a que ça qui compte aujourd'hui mais que c'est "chaud" aujourd'hui. C-à-d qu'il y a de la réflexion autour, que les "dogmes" d'hier sont remis en cause (à tord ou à raison, l'hitoire le dira), des doutes (est-ce A ou B qu'il faut choisir alors qu'aucun n'a fait leur preuve), comment tirer au mieux profit des nouvelles fonctionnalités, etc. Ça ne veut pas dire que ce qui existait avant est devenu d'un coup naze.
> Personnellement je trouve que la virtualisation c'est bien dans des cas très précis :
Et les base de données c'est pour des cas très précis, les serveurs web des cas très précis (uniquement lorsqu'on veut utiliser http), etc.
Ce n'est pas pour des cas précis (ce qui ne veut pas dire que c'est à généraliser systématiquement), c'est plus global que ça. La virtualisation ajoute une fonctionnalité générale et non spécifique. Avant il y avait une bécane, on y installait un OS puis ajoutait des applis. Maintenant avec une bécane on y a installe des OS puis des applis. Ceci est général et non pour un cas précis. On a un OS qui en crée d'autres, les supprimes, change les ressources, les déplaces d'une bécane à une autres, etc.
Si t'avais une grosse bécane, tu étais bloqué sur un OS. Aujourd'hui non. Ton OS avait des ressources définies (celle de la bécane). Aujourd'hui ça change en fonction du paramétrage de l'OS virtualisé.
> -pour pouvoir se débarasser d'une vieille machine avec un vieil os qui ne serait plus supporté par du hardware moderne
Ça c'est très rare... Si c'est pour les certifications, et bien il faut que ça soit certifié pour un environnement virtualisé. Note qu'on voit aussi un avantage à certifier pour un environnement virtualisé au-lieu de 50 bécanes différentes.
> A côté de certaines solutions commes les chroot, Jails ou les zones
Ça c'est moins général que la virtualisation. D'ailleurs un OS virtualisé peut toujours faire du chroot, etc. T'as déjà fait un chroot de Linux vers Solaris ou Windows ? Ou un jail de Linux 2.4 à 2.6 ?
Je ne dis pas qu'un chroot et autre n'a plus leur place.
[^] # Re: Explications?
Posté par Gniarf . Évalué à 2.
> Ça c'est très rare... Si c'est pour les certifications, et bien il faut que ça soit certifié pour un environnement virtualisé. Note qu'on voit aussi un avantage à certifier pour un environnement virtualisé au-lieu de 50 bécanes différentes.
oh oh oh, c'est pas rare du tout : Windows NT, 2000 et même XP ne s'installent PAS sur un disque dur IDE de plus de 120 Go. cai trop gros, ils y arrivent pas.
bon XP SP1 et au delà gèrent, et sont sortis en version CD bootable, donc on peut s'en tirer sans trop d'acrobaties. pour 2000 par contre, même si le SP 3 ou 4 permet de gérer de bien gros disques IDE (enfin, PATA), ça peut commencer à devenir drôle s'il faut installer Windows 2000 sur un gros disque puis appliquer un service pack alors que le Windows démarre pas (ou corrompt le disque, au choix). donc au choix, sorcelleries diverses, utilisation de petits disques ou donc ce dont on parle ici, virtualisation.
[^] # Re: Explications?
Posté par guppy . Évalué à 1.
Sans aucune acrobatie. SP1 est vieux, et si on a un juste un cd XP "SP0", il suffit d'utiliser nlite pour slipstreamer les SP.
[^] # Re: Explications?
Posté par Gniarf . Évalué à 2.
> Sans aucune acrobatie. SP1 est vieux
hors-sujet, on parle justement de trucs vieux ici, tu as peut-être un soft indispensable et incompatible avec le SP1, et l'éditeur est mort, bien trop gourmand dans ses tarifs de mises à jour, ou pire a salopé les versions plus récentes de son produit. c'est bien cette vieille version que tu veux, et le reste du monde a tort.
> et si on a un juste un cd XP "SP0", il suffit d'utiliser nlite pour slipstreamer les SP.
c'est ça justement, les acrobaties...
[^] # Re: Explications?
Posté par briaeros007 . Évalué à 2.
J'ai rien pigé après ça (en fait si, mais c'est tout sauf clair, et ca reste qu'un workaround pas beau et pas évident de base).
[^] # Re: Explications?
Posté par inico (site web personnel) . Évalué à 2.
Il permet de rajouter facilement des Service Pack, des patch et des drivers au Windows qui sera installé.
La procedure de slipstreaming (automatisé par nLite) est documenté par Microsoft.
Le "il suffit" est donc approprié ici vu qu'il suffit de 3 clicks pour graver un Windows XP avec le dernier Service Pack.
[^] # Re: Explications?
Posté par Psychofox (Mastodon) . Évalué à 2.
ça peut être une vieille appli sur un vieil unix, sur un os/2, que jais-je.
[^] # Re: Explications?
Posté par IsNotGood . Évalué à 2.
[^] # Re: Explications?
Posté par Gniarf . Évalué à 2.
les commandes électriques, la bonne grosse électronique bien générique, elle pouvait se débrouiller. des bidules trop petits ou trop intégrés pour savoir ce que c'est ou ce que ca fait à l'oeil nu ou même avec un bon microscope et tout le fatras, et donc impossibles à refabriquer 5 ou 15 ans après, c'est gênant. commander des stocks énormes de pièces de rechange n'est pas une solution car on ne peut pas prévoir le taux d'usure des pièces, ou si en fait il faut presque la même mais un poil différente.
si je me souviens bien, ça a abouti à la création de VHDL
[^] # Re: Explications?
Posté par briaeros007 . Évalué à 1.
Donc non, "il suffit" n'est pas suffisant amha.
[^] # Re: Explications?
Posté par pasBill pasGates . Évalué à 1.
Le temps de le faire c'est pas un probleme, c'est facile a faire et ne prend pas bcp de temps, l'idee elle ben c'est comme toute manip en informatique hein, soit tu la connais, soit non.
[^] # Re: Explications?
Posté par briaeros007 . Évalué à 4.
on a dis "XP de base (sans SP1) s'installe pas sur une machine avec des dd de plus de 120 Go".
Y'en a un qui dis "non mais pour que ça marche "il suffit d'utiliser un logiciel X".
Je luis dis c'est pas "il suffit" mais "il faut" (connaitre le logiciel etc...) , donc non , ce n'est pas si évident que ça.
Et la tu me dis "non mais plein de power user le connaissent" (je n'aurais pas l'outrecuidance de te demander d'où viens ton "extremement" parce que je suis 99.99 % sur que tu n'a aucune statistique fiable pour dire ça, mais passons).
Excuse moi, mais ça change pas le problème initial que des gens le connaisse ou pas (je dirais encore heureux que pas seul son créateur connaisse ce logiciel).
[^] # Re: Explications?
Posté par totof2000 . Évalué à 3.
C'est très utile pour faire des économies d'énergie. Un exemple :
- si tu as N frontaux webs à gérer pour X applis par exemple. Il est plus rentable électriquement d'avoir un ou deux blades qui contiennent n machines virtuelles et éventuellement les X applis sur des serveurs physiques ( parce que grosse appli) plutot que d'avoir N machines physiques sur lesquelles tu installes tes frontaux web. Tu mutualises aussi les accès réseau ( si tu te débrouilles bien et que tu choisis bien ton blade, tu n'as pas à tirer N cables multipliés par le nombre d'interfaces nécessaires par machines ). C'est bien plus qu'un buzz, c'est une réponse à un besoin réel.
[^] # Re: Explications?
Posté par briaeros007 . Évalué à 2.
Donc rajouter une couche de virtualisation (qui va diminuer les perfs) pour augmenter les perfs, j'avoue que j'ai du mal à voir l'intérêt.
Une autre utilisation d'augmenter le nombre de frontaux c'est augmenter la fiabilité. Il ne faut donc pas une blade mais au minimum deux (ou alors avoir des alims redondés etc...*). Dans tous les cas, la virtualisation ici n'apporte rien, vu que les frontaux sont tous équivalents**.
* : dans certaines machines il faut faire gaffe : lorsqu'une alim est redondé, et qu'on retire la première, la machine n'a plus de jus. Jamais compris à quoi ça servait cette "redondance".
** :Pour la fiabilité utiliser des machines virtuels qui offrent n services différents, et gérer la migration de toutes ces machines virtuels si une des machines tombent en panne est effectivement intéressant : on a plus besoin de n*2 machines (minimum), mais juste de m machine (m>=2) suffisamment dimensionner pour supporter tous les services.
[^] # Re: Explications?
Posté par IsNotGood . Évalué à 2.
L'intérêt est la souplesse.
Dans ta "philosophie", tu commencerais par 1 serveur physique. 2 semaines plus tard, tu te rend compte que ce n'est pas assez. Par sécurité, tu en achètes un second gros (on ne sait jamais). Mais au final tu te retrouve avec 2 serveurs utilisés à 52 %. Les 48 % qui reste tu ne peux rien en faire. Avec la virtualisation tu peux les utiliser (par exemple migrer des serveurs virtuels d'un serveur physique très chargé).
> virtualisation (qui va diminuer les perfs)
C'est la souplesse de la virtualisation qui au final te donne plus de performance (même si la virtualisation n'est pes gratuite). Plus de performance ou des économie puisque le matériel est mieux utilisé.
La grande majorité des serveurs sont sous-utilisée.
[^] # Re: Explications?
Posté par briaeros007 . Évalué à 2.
Dans ma philosophie je ferais des tests de charge avant de mettre en prod, et comme ça je connaitrais le bon (enfin une approximation) dimensionnement pour mon objectif ;)
J'avoue que je n'avais pas pensé à la souplesse, mais dans ce cas, le précédent exemple était un peu de mauvaise foi : totof supposait que les blades et les machines virtuelle n'était que pour les frontaux et que les machines d'appli étaient sur des machines physiques différentes ;)
C'est la souplesse de la virtualisation qui au final te donne plus de performance (même si la virtualisation n'est pes gratuite). Plus de performance ou des économie puisque le matériel est mieux utilisé.
J'avais compris l'intérêt initial de la virtualisation ;)
Je parlais du cas où on virtualise n serveurs identiques et qu'on n'essaie pas de mettre des trucs au milieu.
Ps pour le dimensionnement d'une appli complexe, je plains le gars qui dois dimensionner les machines ... surtout si il y a des migrations suivant la charge.
[^] # Re: Explications?
Posté par IsNotGood . Évalué à 3.
T'es fort.
> je plains le gars qui dois dimensionner les machines ... surtout si il y a des migrations suivant la charge.
Oui et non. Sans virtualisation c'est encore plus compliqué. On voit bien l'importance des outils d'admistrations (au-dessus de fonctionnalité de bas niveau solide). Par exemple ovirt :
http://www.ovirt.org/
C'est un domaine en pleine ébullition.
Je te laisse lire la doc. Parfois ça fout la trouille :-)
> Je parlais du cas où on virtualise n serveurs identiques et qu'on n'essaie pas de mettre des trucs au milieu.
Pourquoi pas.
Mais ici aussi la virtualisation peut être utile. NB: je ne dis pas que c'est indispensable !
L'idée n'est pas : j'ai besoin de plus de puissance, j'achete une bécane.
Le problème de la bécane, est qu'elle n'est pas générée (faut lui trouver un lieu, du courant, une prise réseau, installer un OS, etc). Avec la virtualisation, il y a des fournisseurs de "puissance de calcul", de machines virtuelles (donc installation d'OS, etc).
Il est assez courrant d'utiliser EC2 lorsqu'on a besoin de plus de puissance.
Il y avait une démonstration de RHEL MRG assez impressionnante où les tâches étaient distributées sur des serveurs EC2 fraichement crées en quelques cliques. Le calcul qui prenait 15 minutes sur la bécane de démo était fait une minute après la création de 15 machines EC2.
On ne peut pas tout mettre sur EC2. Mais l'idée globale d'EC2 (et S3) va aussi faire son chemin dans les data-center.
Au-lieu d'ajouter une bécane au cas par cas dans les data-center, toutes les bécanes seront consolidées en utilisant la virtualisation (et cluster pour l'espace de stockage).
Puisque tout est consolidé, on connait le niveau d'utilisation de l'ensemble du hardware.
Dans les services informatiques, il y aura la fonction "fournisseur de puissance de calcul, espace disque, etc". L'équpe application ne dira pas "j'ai besoin d'un nouveau serveur", mais provisionnera de la puissance de calcul avec l'espace de stockage. L'équipe qui gère l'ensemble des serveurs regardera s'il est nécessaire d'ajouter du hardware.
C'est le "cloud computing" mais au niveau d'une société. Ou du "à la demande" pour les utilisateurs (l'équipe appli a besoin de 200 Go de disque, hop, elle l'obtient de suite). NB: le "cloud computing" dont je parle n'est pas celui que RMS critique.
Ceci dit, je crois qu'on y est pas encore :-)
Mais ce n'est pas loins.
[^] # Re: Explications?
Posté par totof2000 . Évalué à 2.
Moua ha ha ha ha ha !!!!
Excuse-moi, ce n'est pas pour toi mais .... Si tu savais commment se passent les tests de perfs dans la majorité des boites .... quad ils sont faits.
[^] # Re: Explications?
Posté par briaeros007 . Évalué à 2.
Je reprendrais une phrase de mon journal :
prestation que j'estime cher r pour le travail effectué (du à la boite, ou aux produits qui sont vendus),;)
[^] # Re: Explications?
Posté par totof2000 . Évalué à 2.
s/mauvaise foi/mauvaise explication/
voir mon message plus haut.
[^] # Re: Explications?
Posté par briaeros007 . Évalué à 2.
[^] # Re: Explications?
Posté par Psychofox (Mastodon) . Évalué à 0.
Si ton serveur est utilisé à 1%, c'est surtout que tu l'as mal choisis ton hardware.
L'intérêt de la virtualisation, c'est vraiment pour des mini-applis qui sont tellement peu utilisées ou occasionnent tellement peu de charge qu'on pourrait en mettre 100 par machines. Mais la encore la virtualisation n'est pas forcément utile, nos os sont multitâches/multiutilisateurs et savent de mieux en mieux gérer et réserver leurs ressources.
Le seul avantage est effectivement de pouvoir migrer une machine virtuelle d'un hardware physique à un autre. Mais bon la même chose peut toujours se faire au niveau applicatif (tar/untar d'une machine à une autre et zou).
[^] # Re: Explications?
Posté par galactikboulay . Évalué à 2.
Le seul avantage est effectivement de pouvoir migrer une machine virtuelle d'un hardware physique à un autre. Mais bon la même chose peut toujours se faire au niveau applicatif (tar/untar d'une machine à une autre et zou).
Comme s'il suffisait de faire un tar/untar pour toutes les applis... O_o
Déjà sur de l'Unix c'est pas forcément toujours évident à réaliser, mais il y a d'autres systèmes (au hasard Windows) où ça devient vite non trivial (transférer les clés de registre ou autres joyeusetés).
On pourrait aussi parler de la config réseau, si ton appli est interrogée sur une certaine adresse IP ou un certain nom cela oblige à des reconfigurations.
Franchement, comparer des migrations à chaud de VM avec du tar/untar, faut oser.
[^] # Re: Explications?
Posté par Gniarf . Évalué à 4.
[^] # Re: Explications?
Posté par BAud (site web personnel) . Évalué à 2.
[^] # Re: Explications?
Posté par totof2000 . Évalué à 2.
Si ca existe je serais curieux de les connaitre.
[^] # Re: Explications?
Posté par IsNotGood . Évalué à 2.
Tour de force, et première mondiale, AMD et Red Hat on fait une migration à chaud d'Inter à AMD.http://www.youtube.com/watch?v=EuhU6jJjpAQ
Je crois que la migration à chaud pour KVM est presque terminée, si ce n'est pas déjà fait.
[^] # Re: Explications?
Posté par IsNotGood . Évalué à 2.
C'est déjà fait. La démo donnée le prouve...
[^] # Re: Explications?
Posté par totof2000 . Évalué à 2.
Je me suis mal exprimé, parce que je suis en ce moment dans une boite qui a non pas une application mais des tas d'applis qui marchent de cette façon.
En gros tu as 4 ou 5 blades qui peuvent héberger les frontaux web de plusieurs applis différentes, .... mais effectivement je me suis mal exprimé.
[^] # Re: Explications?
Posté par galactikboulay . Évalué à 2.
Le fait est que concrètement ça permet:
- d'effectuer des maintenances matérielles (ajout de RAM, CPU, ...) ou logicielles (upgrade) sur les serveurs de virtualisation de manière transparente: tu évacues les VMs sur les serveurs qui restent pendant que tu effectues la manip sur le serveur physique.
- de migrer de manière transparente tes machines d'un datacenter à l'autre si pour une raison X ou Y tu as un problème sur ton site principal
- d'avoir une consommation électrique réduite, au lieu d'avoir 42000 serveurs qui ne font quasi rien, tu en achètes quelques gros. Cela économise aussi de la place, du câblage, ...
- de load-balancer tes VMs sur les différents serveurs.
- de déployer extrêmement rapidement un nouveau serveur (surtout quand tu as la possibilité de cloner des VMs ou de faire des templates). L'accès à distance est également facilité: tu as tes media d'install sur une baie de disques, que tu montes virtuellement. Tu as accès à la console à distance, pas besoin d'aller en salle serveurs (pratique quand tu merdes et que la dite salle serveurs est à des km).
[^] # Re: Explications?
Posté par briaeros007 . Évalué à 2.
Je te vois mettre en avant le processus de migration des VM.
Ce processus de migration, bien que pseudo transparent pour les clients (pseudo parce qu'entre autre je peux t'assurer que le routage sur un site distant il se voit passer, et ca peut poser des problèmes de délais dans l'architecture suivant quoi est migré quand ....), ne l'est pas du tout pour les serveurs (augmentation de charge etc...).
De plus, si ton système avant était bien concu, tu devrais avoir un PRA, une redondance N+1 ou N+2 des services, un load balancing, qui n'ont certes pas la souplesse de la migration des VM, mais répondent présent sur un grand nombre de problème.
Comprend moi bien, j'ai essayé de pousser la virtualisation dans mon ex boite pour justement ce but la (on foutais tout sur une machine, une en backup, et basta, plutot que n machine de tests), mais il faut rappeler que
1°) ce n'est pas "magique"
2°) cette "transparence" à aussi un cout (en charge sur les autres serveurs, d'administration), et un risque (typiquement le risque d'exploser les délais de connexions si tu pars sur un site distant et ainsi de suite).
3°) l'info a pas attendu la virtualisation pour essayer de résoudre ces problèmes.
Bon Rien A Voir (RAV) , mais moi j'ai une question conne : je sais que sous vmware il est capable d'ouvrir des machines en read only.
Moi j'aimerais savoir si on peut faire une machine "maitre" (typiquement le système en général), et des machines esclaves (postes clients ,...).
Lorsqu'une modif est faite sur la machine maitre, elle est répliqué sur toutes les machines clientes (mise a jour du système).
Ca existe ça ?
[^] # Re: Explications?
Posté par Prosper . Évalué à 2.
Bon Rien A Voir (RAV) , mais moi j'ai une question conne : je sais que sous vmware il est capable d'ouvrir des machines en read only.
Moi j'aimerais savoir si on peut faire une machine "maitre" (typiquement le système en général), et des machines esclaves (postes clients ,...).
Lorsqu'une modif est faite sur la machine maitre, elle est répliqué sur toutes les machines clientes (mise a jour du système).
Ca existe ça ?
Il me semble que dans vmware view et en particulier wmare view composer tu peux faire ce genre de choses.
[^] # Re: Explications?
Posté par briaeros007 . Évalué à 2.
Enfin ca fait toujours une solution de replis si je veux faire ça, merci;)
[^] # Re: Explications?
Posté par Psychofox (Mastodon) . Évalué à 1.
- d'effectuer des maintenances matérielles (ajout de RAM, CPU, ...) ou logicielles (upgrade) sur les serveurs de virtualisation de manière transparente: tu évacues les VMs sur les serveurs qui restent pendant que tu effectues la manip sur le serveur physique.
En général tu prévoies de la redondance (ben oui en cas de panne) et tu dois pouvoir être capable d'arrêter une machine sans que ça se voit. Si ce n'est pas le cas, ce n'est pas normal, c'est tout ^_^
- de migrer de manière transparente tes machines d'un datacenter à l'autre si pour une raison X ou Y tu as un problème sur ton site principal
idem, normalement, ton appli, elle est déjà sur le second datacenter, juste au cas où. Et tu as une procédure de basculement. Virtuel ou physique, ça ne change rien.
- d'avoir une consommation électrique réduite, au lieu d'avoir 42000 serveurs qui ne font quasi rien, tu en achètes quelques gros. Cela économise aussi de la place, du câblage, ...
tu peux faire tourner plusieurs applis sur 1 seul serveur et tu n'es pas obligé d'acheter que des bêtes de courses.
- de load-balancer tes VMs sur les différents serveurs.
peut souvent se faire en général aussi au niveau applicatif.
- de déployer extrêmement rapidement un nouveau serveur (surtout quand tu as la possibilité de cloner des VMs ou de faire des templates).
avec des procédures de déploiements correcte, la différence est minime. La où je bosse, ce qui prend du temps ce n'est pas l'installation physique (rackage + cablage) ni celle de l'OS, c'est la configuration (même chose qu'avec des VMs). Le clonage ça marche aussi avec des machines physiques très rapidement.
L'accès à distance est également facilité: tu as tes media d'install sur une baie de disques, que tu montes virtuellement. Tu as accès à la console à distance, pas besoin d'aller en salle serveurs (pratique quand tu merdes et que la dite salle serveurs est à des km).
La virtualisation n'a rien à voir la dedans, les serveurs ont tous une console d'administration à distance.
[^] # Re: Explications?
Posté par galactikboulay . Évalué à 1.
En général tu prévoies de la redondance (ben oui en cas de panne) et tu dois pouvoir être capable d'arrêter une machine sans que ça se voit. Si ce n'est pas le cas, ce n'est pas normal, c'est tout ^_^
Ca c'est bien sympathique comme remarque, mais il existe des gens qui conçoivent des applis non redondantes... Autant sur certains services c'est facile (genre du Web/DNS/DHCP/Radius/... par exemple), autant pour d'autres choses ça l'est beaucoup moins.
Quoiqu'il en soit, je préfère migrer des VMs de manière transparente en cas de maintenance planifiée sur un hyperviseur plutôt que de compter sur le fait que la redondance applicative marche à tous les coups (parce qu'on peut avoir des surprises assez sympa à ce niveau là).
tu peux faire tourner plusieurs applis sur 1 seul serveur et tu n'es pas obligé d'acheter que des bêtes de courses.
Sauf qu'à l'heure actuelle, même si tu prends pas le haut de gamme, tu as quand même des machines très puissantes de base, donc qui consomment (et il y a toujours la question de la place).
Après, c'est sûr que tu peux faire tourner plusieurs applications sur le même serveur, c'est juste moins top en terme de sécurité ou même d'isolation (conso CPU, mémoire,... qui part en vrille pour une appli et qui perturbe les autres)
peut souvent se faire en général aussi au niveau applicatif.
Oui, *en général*. Ce n'est pas vrai tout le temps.
La virtualisation n'a rien à voir la dedans, les serveurs ont tous une console d'administration à distance.
J'ai dit que l'administration était facilitée, pas que c'était impossible avec des serveurs physiques.
Je préfère largement utiliser un VI client que d'avoir à me coltiner les différents systèmes de gestion à distance des constructeurs (genre iLO, DRAC et cie).
En plus, je peux facilement donner des droits assez fins à tel ou tel utilisateur sur la VM.
[^] # Re: Explications?
Posté par totof2000 . Évalué à 2.
T'as de la chance .... Je bosse en ce moment dans une grosse structure ou c'est la croix et la bannière pour installer des serveurs ( a juste titre : les datacenters sont full, tant au niveau consommation électrique que l'emplacement au sol).
tu peux faire tourner plusieurs applis sur 1 seul serveur et tu n'es pas obligé d'acheter que des bêtes de courses.
Tu n'a pas la même isolation, ni même la même finesse de répartition de ressources que sur des VM.
La virtualisation n'a rien à voir la dedans, les serveurs ont tous une console d'administration à distance.
Bien sur que si ....
1 serveur physique = 1 connection d'administration/serveur = 1 cable = 1 port de switch, etc ....
N serveurs virtuels = 1 ip d'administration = 1 cable, = 1 port de switch ...
# Annonce un peu hative
Posté par benoar . Évalué à 2.
Je ne suis pas contre qu'ils le libèrent, bien au contraire, mais à mon avis, ils vont continuer de développer KVM en libre, mais garder ce petit "plus" proprio.
[^] # Re: Annonce un peu hative
Posté par IsNotGood . Évalué à 4.
Ton commentaire m'a poussé a faire des recherches sur Fedora :
http://fedoraproject.org/wiki/Qumranet
This page concerns community engagement with Qumranet,
[...]
Goals
The goal of this page is to organize and serve as central point of reference for involvement of the Fedora community in Qumranet projects, revolving around virtualization and specifically KVM. In the near future there are a number of additional Qumranet-developed technologies which will become open source and this should serve as an aggregation point for information regarding those existing and newly developing technology.
[...]
SPICE/SolidICE
Both Spice and SolidICE and in the process of becoming open source. Please check back here for more information.
Cool.
De mon journal :
- "Est-ce que Solid ICE, la partie serveur/gestion qui tourne sous LInux, sera libéré ? Aucune idée encore."
Ben oui, Solid ICE sera libéré.
Merci pour ton "non-pertinent" oommentaire :-)
[^] # Re: Annonce un peu hative
Posté par IsNotGood . Évalué à 2.
Il semble que tu connais assez peu l'esprit Red Hat. Actuellement Red Hat ne fournit pratiquement rien de proprio. Il restait RHN Satelite, il a été libéré (c'est SpaceWalk maintenant).
C'est aussi un question d'image pour Red Hat et d'implication de ses partenaires. Partenaires qui ont ou non signé un accord, mais partenaires du moment qu'ils contribuent au libre.
Cette vidéo sera peut-être choquante pour certains libristes :
http://www.redhat.com/promo/summit/2008/videos/ogg/Jim_White(...)
C'est le PDG de Red Hat. Il dit entre autre :
- "Let me start at the very beginning. I want to reiterate this because this is importante :
We are the leaders in the open source. Period full stop !"
Voir l'intégriter de la vidéo avant de troller.
[^] # Re: Annonce un peu hative
Posté par benoar . Évalué à 4.
Je pensais par contre qu'ils gardaient certains outils très spécifiques proprios, comme RHN Satelite justement (c'est bien leur outils d'administration de plein de machines par un service web centralisé chez RH ? je l'ai juste vu une fois dans ma vie ...) Que tu me dises qu'il est libre aujourd'hui, je trouve ça vraiment bien.
Bref, c'est cool d'avoir toutes ces libérations, ça montre que RH garde toujours la même ligne de conduite quoi qu'il arrive. J'espère que ça continuera bien pour eux.
[^] # Re: Annonce un peu hative
Posté par BAud (site web personnel) . Évalué à 3.
Spacewalk / RHN Satellite permet surtout de faire proxy / miroir de paquets (et de saveur de distributions) pour tes serveurs (desktop éventuellement) dans ton entreprise plutôt que d'avoir une floppée de machine qui se connectent à Internet pour accéder au RHN (ce qui est aussi possible, mais bon un peu contraire à la sécurité, habituellement).
# ...
Posté par Prosper . Évalué à 4.
Faudrait quand même pas oublier Vmware View ( ex vmware VDI ) , parce qu'en terme de virtualisation de desktop c'est un peu les premiers a l'avoir fait. ( en plus d'être probablement les leaders en terme de virtualisation de desktop ) .
[^] # Re: ..."
Posté par Nico C. . Évalué à 1.
Pour info, le "truc" de virtualisation de MS c'est HyperV.
Par contre, ils sont a 10km de faire de la virtualisation du poste de travail... deja qu'HyperV n'est vraiment pas bon pour les serveurs, le desktop viendra plus tard... ou pas.
# De la diversité des noms de logiciels...
Posté par Maclag . Évalué à 10.
Et voilà, ça n'a rien à voir, tout comme mon commentaire d'ailleurs!
Pour ceux qui n'ont rien compris, SPICE est un simulateur de circuits électroniques qui date mais dont les multiples évolutions et implémentations lui permettent d'être encore très largement utilisé. Mais comme il est déjà libre, je ne comprenais pas bien le titre de l'article...
http://fr.wikipedia.org/wiki/SPICE
[^] # Re: De la diversité des noms de logiciels...
Posté par BAud (site web personnel) . Évalué à 2.
dans le doute, j'ai aussi été regardé en anglais
http://en.wikipedia.org/wiki/SPICE
ah bah non plus, c'est pareil :/ sauf qu'il y a une page d'homonymie
http://en.wikipedia.org/wiki/Spice_(disambiguation)
rho bah ça n'apparaît pas non plus, peut-être un nom qu'il est encore temps de changer ?
# Interet ?
Posté par oau . Évalué à -4.
Ok ca répond pas à 100% des besoins. Particulièrement aux applications très spécifique genre PAO ou autre. Mais pour lire ses mails et faire des présentations ça me parait très suffisant.
[^] # Re: Interet ?
Posté par claudex . Évalué à 4.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Interet ?
Posté par totof2000 . Évalué à 2.
Euh ... Comment dire sans froisser ta suceptibilité ...
1/ Tu sais que l'informatique, c'est pas seulement lire ses mails et faire des présentations ?
2/ Tu sais que pour faire tourner un navigateur ya besoin d'un poste de travail, qui est souvent sur-dimensionné par rapport aux besoisn ?
Tu n'as jamais vu par exemple dans certaines boutiques des PC chargés de gérer des tiroirs caisses ? Je pense aussi aux postes de travail dans les banques ou assurances qui pourraient tirer profit de ce genre de solution ....
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.