Effectivement, ce mode de fonctionnement devrait tendre à disparaître et
tout au plus pourrions nous envisager de gérer ce cas comme : une
machine virtuelle(pour le/les boot les moins utilisés) rattaché à son
hôte(système lancé en premier par défaut) et rajouter juste pour info
une case à cocher(Multi Boot) dans la création/gestion des machines
virtuelles sous GLPI!?

Du coup on peut avoir un inventaire d'OCS pour chaque multi-boot. En
revanche il faudra gérer les rapport "doublons" d'adresses MAC/IP ,
d'ailleurs tout comme pour les VM suivant que le réseau est fourni par
le NAT, Bridge, etc.

C'est peut-être plus simple au final?

Serge

Le 16/09/2011 23:32, Benoit a écrit :
> Bonjour,
>  
> A part a la maison pour jouer , et on a pas forcement besoin d'OCS,
> j'ai jamais vu au taf de PC multi boot, surtout depuis l'apparition
> des solutions de virtualisation (postes de dev/recette). Je n'ai pas
> la prétention d'avoir vu toute les facons de travailler au monde, mais
> est ce réellement fréquent ?
> Bref est ce que ca a un interet ?
>  
> Le 16 septembre 2011 07:53, Damien Touraine <damien.toura...@limsi.fr
> <mailto:damien.toura...@limsi.fr>> a écrit :
>
>     Bonjour,
>
>     Par curiosité, je voulais savoir comment se déroulait l'import de
>     machines multi-boot. Si je comprends bien la structure de
>     Computer, il y a autant d'OS que d'agent OCS installés sur les
>     différents OS. C'est bien cela ? J'ai l'impression que cela est
>     lié à l'import OCS qui fait la même chose. Est-ce bien le cas ?
>
>     Peut-être devrions-nous proposer, pour un ordinateur donné, la
>     faculté d'avoir plusieurs OS différents. Il y a beaucoup
>     d'implications à cela (identification d'un ordinateur, éléments
>     propres à l'OS, ...).
>     Y-a-t'il déjà eu des réflexions à ce sujet ? Si oui, existe-t-il
>     une page sur le wiki ?
>
>     Je ne penses pas que cela soit urgent (d'ailleurs, est-ce bien
>     utile ?). Donc, nous pourrions commencer à jeter quelques idées
>     sur le sujet et intégrer cela dans une version future de GLPI
>     (peut-être après la version 1.0).
>
>
>     Damien
>
>     -- 
>     --------------------------------------------------------------------
>     Damien TOURAINE - Ingénieur de Recherche CNRS, LIMSI-CNRS
>     Groupe de RV&A "VENISE", (http://www.limsi.fr/venise/)
>     Bat. 508, Universite Paris-Sud 91403 Orsay cedex - +33 1 69 85 81
>     64 <tel:%2B33%201%2069%2085%2081%2064>
>     --------------------------------------------------------------------
>
>
>     _______________________________________________
>     Glpi-dev mailing list
>     Glpi-dev@gna.org <mailto:Glpi-dev@gna.org>
>     https://mail.gna.org/listinfo/glpi-dev
>
>
>
> _______________________________________________
> Glpi-dev mailing list
> Glpi-dev@gna.org
> https://mail.gna.org/listinfo/glpi-dev


-- 
" I sense much Windows in you, Windows leads to Blue Screen.
Blue Screen leads to downtime, downtime leads to suffering.
Windows is the path to the darkside. "
- Unknown Unix Jedi

<<attachment: serge_facchin.vcf>>

_______________________________________________
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Reply via email to