IOP,
humhum, t’utilise quemu en prod… avec kqemu je supose… a tu (et les autre) confronter a ce probleme forum.ubuntu-fr.org/viewtopic.php?pid=1384924 , car moi oui et je l’ai resolu commme ca).
Et il est vraiment gratuit, libre et donc utilisable gratuitement en entreprise (pas un truc comme avast, qui est gratui pour le particulier mais pas pour le pro). Et virtualbox, vmware (serveur), xen, uml… sont gratuit, libre et utilisable en entreprise?
[quote]~$ dpkg -l | grep qemu
ii kqemu 1.30-9 Module kqemu
ii qemu 20060722 Qemu emulateur machine
$ qemu -h
QEMU PC emulator version 0.8.2, Copyright © 2003-2005 Fabrice Bellard
usage: qemu [options] [disk_image]
[/quote]
Ce sont des paquets persos fait à partir des sources, à l’époque kqemu n’était pas libre. Il y avait pas mal de difficultés avec kqemu dans un environnement 64 bits… Les pquets (pour sarge) sont là:
http://boisson.homeip.net/sarge/qemu/
IOP,
tes un warrior fran.b :smt003
je test ca cet aprem 
ca passera ben avec etch…? 
[quote=“RedX42”]
ca passera ben avec etch…? [/quote]
Pbm de noyau avec kqemu, utilise les sources des paquets
http://boisson.homeip.net/source
mais ouvre un autre fil, panthere est accueillant mais qd même 
VirtualBox c’est bien pour les tests, simuler un réseau (comme le disait Matt). Par exemple moi j’ai toujours le probleme d’une etch qui tourne dans VirtualBox (la Etch est totalement en Idle) et quand je regarde le processus sur la machine Hote , il prends 100% du core sur lequel il est lancé. Toujours pas réussis à régler ce problème. Mais la prochaine fois, je testerai Quemu 
j’ai deja utilise chroot, les inconvénient c’est qu’il faut tout gere a la mano, ce qui est pénible, je veux bien mettre mon nez dans le système, mai pas pour un reconstruire un, bien que cela ne soie pas compliquer. sa prend trop de temps a mon gout.
sur un dualcore c’est normal. car vb n’est pas multitread, sa t’en fait bosser qu’un seul. d’ou l’interet des dualcores, comme sa l’autre est libre pour le reste
j’ai regarder pour quemu , il faudrai que je l’essaye pour me faire une idée avant de critiquer.
mai j’ai pas vu que Quemu gere les image dynamique ? (l’image s’agrandir aux fure et a mesure que les donne s’ajoute dans la wm) vb le fait ce qui est important pour mon portable j’ai qu’un mini dd de 120 go 
[quote]j’ai deja utilise chroot, les inconvénient c’est qu’il faut tout gere a la mano, ce qui est pénible, je veux bien mettre mon nez dans le système, mai pas pour un reconstruire un, bien que cela ne soie pas compliquer. sa prend trop de temps a mon gout.
[/quote]Je ne comprends pas, sur une machine virtuelle, c’est pire.
[quote=“panthere”]j’ai deja utilise chroot, les inconvénient c’est qu’il faut tout gere a la mano, ce qui est pénible, je veux bien mettre mon nez dans le système, mai pas pour un reconstruire un, bien que cela ne soie pas compliquer. sa prend trop de temps a mon gout.
(…)[/quote] Exactement le même temps qu’une install de machine virtuelle, avec en moins la config du materiel et du réseau, qui sont déjà faites dans l’arborescence principale.
Un petit tuto pour préparer vite ça avec debootstrap ?
debian.org/releases/stable/a … 03.html.fr
Et même avec ça tu trouves la construction de ton pseudo systeme encore trop long: [quote]roc@roc:~$ aptitude show rootstrap
Paquet : rootstrap
État: non installé
Version : 0.3.24-4
Priorité : optionnel
Section : utils
Responsable : User Mode Linux Maintainers pkg-uml-pkgs@lists.alioth.debian.org
Taille décompressée : 160k
Dépend: debootstrap (>= 0.3.0), dpkg (>= 1.9.19), python, user-mode-linux
Recommande: uml-utilities
Suggère: dhcp3-client, dhcp3-server
Description : A tool for building complete Linux filesystem images
Rootstrap was originally written to provide a facility for building filesystems for use with User-mode Linux, but can be useful in other applications as
well.
It uses a modular set of shell scripts to create the filesystem image, install a base system, and customize it for a particular application. Currently,
it only builds Debian systems, but the architecture is such that other base systems could be used instead.
Use of rootstrap does not require root access, or special privileges of any kind. This is because it builds the filesystem inside a User-mode Linux
system running under an unprivileged uid.
Filesystem creation with rootstrap is quick and painless. With a local mirror and a single command, a fresh Debian filesystem can be created in about 3
minutes on relatively modest hardware.[/quote][quote=“panthere”]
j’ai regarder pour quemu , il faudrai que je l’essaye pour me faire une idée avant de critiquer.[/quote] N’essayes pas: vu les perfs, tu vas critiquer 
[quote=“panthere”]mai j’ai pas vu que Quemu gere les image dynamique ?[/quote]Sisi: n’importe quel fichier linux ( y compris les filesystems ) peut être >à trous< ( en.wikipedia.org/wiki/Sparse_files ) et ceci presque indépendament du formatage de la partoche sous jacente. vb n’a fait que copier l’idée mise en oeuvre en premier par qemu. [quote=“panthere”] (l’image s’agrandir aux fure et a mesure que les donne s’ajoute dans la wm) vb le fait ce qui est important pour mon portable j’ai qu’un mini dd de 120 go [/quote]Tu rigoles ? 120 Go tu appelles ça mini ? Personnellement (même si c’est vrai que je ne fais pas de p2p), je viens de me faire offrir sur mon portable un 120 Go en remplacement du 80 que j’ai (qui me donne des erreurs smart depuis 3 mois) qui etait loin d’être plein avec 3 os (XP mediacenter+debian+gentoo) et mon idée est que ca me donne quelques années de tranquilité.
Tu m’expliqueras, si l’on ne compte pas /var, /tmp, et /home, comment tu fais pour avoir besoin de plus de 20 Go par OS (toujours excepté les logs, les temporaires, et les données user). Ca m’interesse.
[quote=“fran.b”][quote]j’ai deja utilise chroot, les inconvénient c’est qu’il faut tout gere a la mano, ce qui est pénible, je veux bien mettre mon nez dans le système, mai pas pour un reconstruire un, bien que cela ne soie pas compliquer. sa prend trop de temps a mon gout.
[/quote]Je ne comprends pas, sur une machine virtuelle, c’est pire.[/quote]
non c est plus simple, on s’emm* pas a enlever ou a ajouter les outils,contrairement a un chroot.
puis que c’est carrement une installation. a la différence près que: on configure la première ce qui revien aux meme que le chroot.
Ensuite on duplique l’image, sa prend moins d’une minute avec les mini changement dedant.
bon alllez un petit comparatif ?
le lien donner par :mattotop
debian.org/releases/stable/a … 03.html.fr
on install virtualbox: chose qu’on peux faire sous windows comme sous linux (donc portable genre faire une demo chez un amis autre que sur un live-cd)
On poursuis une installe standard avec un cd ,ou carrément l’image iso c’est plus rapide )
puis:http://doc.ubuntu-fr.org/virtualbox_reseau
et zou 
Bon vous me direz que c est du clikodrome, m’enfin la souris a pas été inventée pour rien 
je me ser déja vb pour emuler xp (pas le choix des appli non dispo sous linux)
il me reste plus qu’a fignoler déplacer les image sur le portables et zou
[quote=“mattotop”][quote]
Tu rigoles ? 120 Go tu appelles ça mini ? Personnellement (même si c’est vrai que je ne fais pas de p2p), je viens de me faire offrir sur mon portable un 120 Go en remplacement du 80 que j’ai (qui me donne des erreurs smart depuis 3 mois) qui etait loin d’être plein avec 3 os (XP mediacenter+debian+gentoo) et mon idée est que ca me donne quelques années de tranquilité.
Tu m’expliqueras, si l’on ne compte pas /var, /tmp, et /home, comment tu fais pour avoir besoin de plus de 20 Go par OS (toujours excepté les logs, les temporaires, et les données user). Ca m’interesse.
[/quote][/quote]
sauvegarde des données, bon déja: mp3 120 cd sur le dd sa représente 20 go ensuite j’ai et je suis encore occasionnellement admin pour un(des) serveur de jeux (lestigresblancs.fr/), 10 go de donnée ,map config serveur medal of honord , cod2. ensuite vien les donnée perso 3 go d’image, ensuite des vieux truc qui traine des année 95 , emulateur commodore 64 
le ghost de xp 10 go etc etc pis bon on rajoute un sauvegarde du 2eme pc sure le premier et inversement je peux te dire que 120 go c’est vite plein
Le tout sans p2p,des questions ?
la ou ma debian tourne c’est un dd de 320 go
[quote=“panthere”][quote=“fran.b”][quote]j’ai deja utilise chroot, les inconvénient c’est qu’il faut tout gere a la mano, ce qui est pénible, je veux bien mettre mon nez dans le système, mai pas pour un reconstruire un, bien que cela ne soie pas compliquer. sa prend trop de temps a mon gout.[/quote]Je ne comprends pas, sur une machine virtuelle, c’est pire.[/quote]non c est plus simple,[/quote] Non. C’est pire. On est deux à dire ça, et comme on dit de nos jours: tu es minoritaire, tu as tort.
Panthere,
je sais que VB n’est pas multithread, mais tu as pas du comprendre ce que je voulais dire :
ma machine virtuelle me prends 100% d’un corps alors que quand je regarde sur l’hote émulé le proc est totalement en idle (car rien ne tourne dessus). c’est donc bien un bug je penses …
Fais comme tu le sens mon gars mais là dessus, je ne te suis pas…
[quote=“themorice”]Panthere,
je sais que VB n’est pas multithread, mais tu as pas du comprendre ce que je voulais dire :
ma machine virtuelle me prends 100% d’un corps alors que quand je regarde sur l’hote émulé le proc est totalement en idle (car rien ne tourne dessus). c’est donc bien un bug je penses …[/quote]
c’est l’hote qui a la prioritaire, pas celui qui ce trouve a l’intérieur d’un vm. c’est donc normal
mai qu’elle processeur as-tu ?
fran.b oui tout a fait, et il n’y que les con qui ne change pas d’avis :smt002
un core2 duo a 1,83 GHz.
Le truc bizard : j’émule une ipcop : tout va bien , la consomation au niveau de l’hote est correct. J’émule ma etch : la consomation au niveau de l’hote est à fond alors que si je regarde sur la machine émulée quasiment rien ne tourne …
Enfin bref lol
[quote=“themorice”]
Le truc bizard : j’émule une ipcop : tout va bien , la consomation au niveau de l’hote est correct. J’émule ma etch : la consomation au niveau de l’hote est à fond alors que si je regarde sur la machine émulée quasiment rien ne tourne …[/quote]
Tu as certainement FAM ou un daemon quelconque qui regardes les modifications des répertoires en temps réel. Cela fait une activité permanente d’entrée/sortie sur ta machine qui se traduit par une activeité permanente de ton CPU sur la machine hôte (hypothèse). Tue chaque processus et regarde ce que ça donne.
mais ce deamon quelconque tournerait sur la machine émulée ?
Bien sûr, tu as une machine émulée avec une etch dessus, donc tous les daemons classiques d’une etch…
Mais alors comment tu expliques que quand je fais un top dans la Etch elle soit quasiment en idle ? (ce qui est normal)
Parce que la Etch ne fait que des entrées sorties (donc le processeur de la Etch ne fait rien), par contre le processeur hôte passe son temps à gérer les entrées/sorties de la machine virtuelle et bouffe son temps CPU.
ok ok fran.b , je regarderai ça à l’occaz 
merci beaucoup