# [XEN/VMWARE/QEMU] Des questions avant un future déployement

## loopx

Bonsoir, 

Voilà, dans ma boite, on utilise pas Gentoo (oui, ca commence bien ^^) mais vu que vous êtes quand même plutôt bien calé, je poste ici ^^... 

Donc, re, voilà, on utilise Red Hat 5.4 et j'aimerais me lancer dans la virtualisation (parce que .. demander à google pourquoi la virtualisation c'est bien ...). Je ne sais pas trop quoi choisir ...   :Embarassed: 

J'ai le choix entre :

- VMWare (le free)

- Xen (avec orchestra?)

Bref, niveau perf, est-ce que Xen fonctionne correctement ? Ce sera pour mettre du Linux, pas de Windows  :Wink: 

Et orchestra ? Intéressant ?

Le but, c'est de virtualisé, de pouvoir tet passer l'image d'une machine à l'autre de manière simple et efficace. Essayer de ne pas avoir trop d'étape à l'installation (si c'est trop compliqué, ca pourrait être un peu lourd).

Voilà, si vous pouviez me donner vos avis, ce serait très aimable  :Wink: 

----------

## guilc

Pour des serveurs, ni l'un ni l'autre :p

KVM, pourquoi pas sur du Proxmox VE. Ca sera 10x plus simple à gérer que XEN, et en plus pas besoin d'un kernel antédiluvien patché dans tous les sens !

----------

## kwenspc

 *guilc wrote:*   

> 
> 
> KVM, pourquoi pas sur du Proxmox VE. Ca sera 10x plus simple à gérer que XEN, et en plus pas besoin d'un kernel antédiluvien patché dans tous les sens !

 

+1

D'autant que RedHat a racheté Qumranet. Désormais c'est RedHat qui maintient KVM, ce qui veut dire qu'il y a la possibilité d'avoir du service de leur part. (documentation, formations, maintenance, etc...)

----------

## Oupsman

Message supprimé

----------

## kwenspc

 *Oupsman wrote:*   

> 
> 
> Perso j'ai des linux en production qui tourne en 2.6.9 et je n'envisage même pas de les mettre à jour.

 

T'as quand même patché les failles de sécurité sur cette version du noyau non? (les exploit root local récents notamment)

À moins que tes serveurs soit pas connectés au net et/ou que tu fasses totalement confiance dans la sécurité des logiciels qui tournent dessus.

----------

## man in the hill

 *Oupsman wrote:*   

>  *guilc wrote:*   pas besoin d'un kernel antédiluvien patché dans tous les sens ! 
> 
> J'vais dire une connerie, mais en quoi est-ce un défaut ? On parle de SERVEUR là donc justement plus le kernel est vieux mieux c'est ... Qui plus est, on parle de serveur hôte pour VM, donc autant qu'il soit aussi stable et éprouvé que possible. Non ?
> 
> Perso j'ai des linux en production qui tourne en 2.6.9 et je n'envisage même pas de les mettre à jour.

 

Aussi parce que KVM suit un développement très rapide et tu ne peux pas te permettre de rester sur un vieux kernel avec des vieux modules ... Là ce n'est pas du bling bling,  le but est de tourner aussi vite que l'hôte donc il y a beaucoup d'amélioration que l'on ne peut pas laisser de côté comme les I/O, le reseau, etc ... Tu peux aussi trouver des améliorations pour ton hôte ...

----------

## PabOu

La version "commerciale" Citrix de Xen existe aussi en version gratuite (depuis la 5.0 ou 5.5), faut s'enregistrer sur leur site et on peut recevoir un fichier de licence "free" à utiliser.

En tout cas, le Xen Center (bien que sous windows) est 15 fois plus pratique et plus intuitif que l'interface web de Proxmox (ressemble beaucoup à VMWare workstation pour ceux qui connaissent). Et l'utilisation en ligne de commande pour des fonctions avancées est vraiment sympa.

----------

## guilc

Pareil que les autres Oupsman : qui c'est qui maintient les problèmes de sécurité ?

Pour moi le seul "vieux" kernel valable, c'est celui des distribs maintenues longtemps en terme de sécurité (genre le kernel debian stable, bubuntu LTS, etc...) mais du kernel mano avec des patches externes, c'est juste inmaintenable tellement assurer la veille et faire les backports prend du temps (et on a en général autre chose à faire)

Tes 2.6.9, tu es sûr qu'ils ne sont pas troués ? Parce que bon, pour ces kernel, j'ai une bonne dizaine d'exploits qui tournent dessus (locaux ou remote)...

----------

## geekounet

Pour KVM je saurais pas dire, jamais utilisé, mais apparemment ça a l'air sympa.  :Smile: 

Au boulot on a du Xen 3.2, sur des kernel 2.6.26 de la Debian Lenny, et jusqu'à récemment c'était du 2.6.18 de Etch (qui n'est plus supportée officiellement, donc on a migré). Et ça tourne nickel, pas de soucis de perfs (et on y fait tourner de gros trucs genre Plone, Drupal, ...). On a grosso-modo une cinquantaine de grosses VM réparties sur 6 grosses machines (du genre quadri/octo-core avec au 32/64/72GiB de ram), et par contre on gère à la main en CLI, pour le moment. Bref, c'est pas un mauvais choix non plus.

Et VMWare, juste non, définitivement pas un bon choix : c'est proprio, donc le jour où son éditeur décide de ne plus supporter ta version de son logiciel, t'es dans la galère pour tout migrer sur une autre version voir autre chose, t'es totalement dépendant de leur bonne volonté pour les correctifs de bugs et de sécurité, au lieu de pouvoir compter sur une communauté réactive voire sur toi même si t'en as les compétences. Dépend d'un machin propre obscur dont tu n'as pas le controle pour la base de ton infrastructure, ce n'est pas un choix intelligent.  :Wink: 

----------

## loopx

 *guilc wrote:*   

> KVM, pourquoi pas sur du Proxmox VE. Ca sera 10x plus simple à gérer que XEN, et en plus pas besoin d'un kernel antédiluvien patché dans tous les sens !

 

Me semble avoir lu dans la doc de virtualisation de red hat qu'il n'est pas nécessaire d'avoir un kernel modifié si le matos supporte la virtualisation :

 *Quote:*   

>  La Virtualisation Red Hat vous permet de démarrer un noyau invité non modifié si vous avez les processeurs Intel VT et AMD SVM. Vous n'avez pas à transférer votre système d'exploitation pour déployer cette architecture sur votre système Intel VT ou AMD SVM. La Virtualisation Red Hat supporte :
> 
>     *
> 
>       La technologie Intel VT-x ou AMD-V Pacifica et Vanderpool pour la virtualisation partielle et complète.
> ...

 

Ca se trouve ici : http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/fr-FR/Virtualization/ch-op-sys-support.html

----------

## loopx

 *kwenspc wrote:*   

>  *guilc wrote:*   
> 
> KVM, pourquoi pas sur du Proxmox VE. Ca sera 10x plus simple à gérer que XEN, et en plus pas besoin d'un kernel antédiluvien patché dans tous les sens ! 
> 
> +1
> ...

 

mais, Proxmox n'est pas un logiciel qui tourne sur red hat  :Surprised:    et je ne peux installer que red hat (car on a des licences et un support ..) :

 *Quote:*   

> Le logiciel inclut :
> 
>     * Système d'exploitation complet (Debian Lenny 64 bits)
> 
>     * Partitionnement de disque dur avec LVM2
> ...

 

 :Crying or Very sad: 

----------

## loopx

 *Oupsman wrote:*   

>  *guilc wrote:*   pas besoin d'un kernel antédiluvien patché dans tous les sens ! 
> 
> J'vais dire une connerie, mais en quoi est-ce un défaut ? On parle de SERVEUR là donc justement plus le kernel est vieux mieux c'est ... Qui plus est, on parle de serveur hôte pour VM, donc autant qu'il soit aussi stable et éprouvé que possible. Non ?
> 
> Perso j'ai des linux en production qui tourne en 2.6.9 et je n'envisage même pas de les mettre à jour.

 

+1, ici, la dernière version, c'est celle-ci :

```

[0][root@serveur ~]$ cat /etc/redhat-release

Red Hat Enterprise Linux Server release 5.4 (Tikanga)

[0][root@serveur ~]$ uname -a

Linux serveur.<domaine> 2.6.18-164.11.1.el5 #1 SMP Wed Jan 6 13:26:04 EST 2010 x86_64 x86_64 x86_64 GNU/Linux
```

----------

## kwenspc

 *loopx wrote:*   

> 
> 
> mais, Proxmox n'est pas un logiciel qui tourne sur red hat    et je ne peux installer que red hat (car on a des licences et un support ..) :
> 
>  *Quote:*   Le logiciel inclut :
> ...

 

Eh loopx réveilles toi! Depuis quand un logiciel open source, sous linux, tournerait que sur certaines distros?   :Arrow:  http://pve.proxmox.com/wiki/Where_to_get_the_sources

Bon après en effet c'est pas packagé pour Red Hat. Faut le faire quoi. Mais amha ça doit pas être trop sorcier. (d'ailleurs c'est une faute de stratégie de la part de proxmox de pas fournir les paquets pour les distros les plus connus, encore plus des distros "corporate" comme RH, Mandriva ou Suse)

----------

## loopx

 *kwenspc wrote:*   

>  *loopx wrote:*   
> 
> mais, Proxmox n'est pas un logiciel qui tourne sur red hat    et je ne peux installer que red hat (car on a des licences et un support ..) :
> 
>  *Quote:*   Le logiciel inclut :
> ...

 

Même si je le compile moi même, c'est pas bon .. faut que ce soit vraiment supporté par Red Hat.. que je puisse ouvrir un call le jour ou on a un problème critique .. et la, ca n'ira pas ...

Sinon, revenons-en à la solution KVM ... si je fais une zolie recherche, j'ai ceci :

```

[0][root@serveur ~]$ yum search kvm

======================================================================= Matched: kvm =======================================================================

qemu-system-x86.x86_64 : QEMU system emulator for x86

etherboot-roms-kvm.x86_64 : Etherboot - boot roms supported by KVM, .rom format

etherboot-zroms-kvm.x86_64 : Etherboot - boot roms supported by KVM, .zrom format

kmod-kvm.x86_64 : kvm kernel module(s)

kvm.x86_64 : Kernel-based Virtual Machine

kvm-qemu-img.x86_64 : Qemu disk image utility

kvm-tools.x86_64 : KVM debugging and diagnostics tools

python-virtinst.noarch : Python modules and utilities for installing virtual machines

revisor-cobbler.noarch : Revisor Cobbler Integration

virt-manager.x86_64 : Virtual Machine Manager

```

mais .. je sais pas du tout comment cela fonctionne, ce qui est nécessaire .. bref, la structure à mettre en place pour faire tourner une VM sur KVM ...

Une idée ? Un peu de docs ?

----------

## kwenspc

 *loopx wrote:*   

> 
> 
> Même si je le compile moi même, c'est pas bon .. faut que ce soit vraiment supporté par Red Hat.. que je puisse ouvrir un call le jour ou on a un problème critique .. et la, ca n'ira pas ...
> 
> 

 

Bah en fait, tu dois pouvoir leur demander de packager ça. soit à RH soit à proxmox. Mais via rétribution je pense.

----------

## man in the hill

 *loopx wrote:*   

> Sinon, revenons-en à la solution KVM ... si je fais une zolie recherche, j'ai ceci :
> 
> ```
> 
> [0][root@serveur ~]$ yum search kvm
> ...

 

```
qemu-system-x86.x86_64 : QEMU system emulator for x86

kmod-kvm.x86_64 : kvm kernel module(s)

kvm.x86_64 : Kernel-based Virtual Machine

kvm-qemu-img.x86_64 : Qemu disk image utility

kvm-tools.x86_64 : KVM debugging and diagnostics tools
```

Vérifie kvm ne soit pas activé ds le noyau

```
grep -i kvm  /usr/src/linux/.config
```

Faudra peut-être compiler ton noyau pour activer ou désactiver certains modules, c'est a toi de voir, moi j'ai choisi d'avoir des noyaux très récents qui ont les modules kvm kvm_intel ou kvm_amd  aussi très récents comme cela je sais que ces modules passent sans problèmes avec le noyau ...

Mon expérience, c'est que les logiciels tiers peuvent poser problèmes donc préfère la maitrise de la ligne de commande qemu(qemu-system-x86.x86_64)/kvm avec des srcipts persos car le jour ou ton logiciel tiers virt-manager ou promox ne lance pas ta VM, tu pourras surement la lancer en cli ... Une vm se controle totalement à distance via ssh et vnc ...

Topic maison ici

----------

## Oupsman

Message supprimé

----------

## loopx

oui, c'est de la PROD  :Wink:   donc oui, on fait pas ce que l'on veux, ce n'est nullement un système "maison"...

Bon sinon, je n'ai pas le fichier ".config" avec redhat .. donc, je ne peux pas voir si c'est activé ou non ...

J'ai une question ... Puis-je utiliser KVM avec Qemu ? Est-ce performant ? (avec le module KQemu) ???

Le problème que j'ai actuellement, c'est que je ne sais pas quelle hyperviseur utilisé avec KVM (pour red hat) ... ?...   :Rolling Eyes: 

----------

## kwenspc

 *loopx wrote:*   

> 
> 
> J'ai une question ... Puis-je utiliser KVM avec Qemu ? Est-ce performant ? (avec le module KQemu) ???
> 
> 

 

faut que tu lises le topic filé par man in the hill

----------

## loopx

 *kwenspc wrote:*   

>  *loopx wrote:*   
> 
> J'ai une question ... Puis-je utiliser KVM avec Qemu ? Est-ce performant ? (avec le module KQemu) ???
> 
>  
> ...

 

Suis entrain de lire .. il parle de qemu/kvm .. mais, est-ce qemu avec le module kvm => kqemu, ou est-ce autre chose ?

EDIT: mauvaise nouvelle, je n'ai po le flag "vmx"  :Sad:  :Sad:  :Sad:  :Sad:  je n'ai que le flag "vme"  :Sad:  :Sad:  :Sad:  :

```
processor       : 3

vendor_id       : GenuineIntel

cpu family      : 15

model           : 2

model name      : Intel(R) Xeon(TM) CPU 2.66GHz

stepping        : 9

cpu MHz         : 2661.243

cache size      : 512 KB

physical id     : 3

siblings        : 2

core id         : 0

cpu cores       : 1

apicid          : 7

fdiv_bug        : no

hlt_bug         : no

f00f_bug        : no

coma_bug        : no

fpu             : yes

fpu_exception   : yes

cpuid level     : 2

wp              : yes

flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr

bogomips        : 5320.96
```

----------

## loopx

Hello, je viens de télécharger l'image d'install gentoo minimal .. et je test un simple boot (juste le switch -cdrom) ...

Bon, ca démarre, mais qu'est-ce que c'est lent!!!!!!!!!!!!!! plus de 2 min, pas encore booté, c'est inutilisable, faut que je boost ca  :Surprised: 

J'ai remarqué que le réseau n'est pas correct, suis bloqué en interne, je n'ai pas accès à mon lan actuellement ...

----------

## kwenspc

Si t'as pas le VT sur ton intel laisses tomber. KVM est spécifiquement fait pour ce type de technologie.

Là pour le coup OpenVZ,ou Xen a la rigueur, ça devrait tourner pas mal, le mieux étant OpenVZ amha.

----------

## loopx

Mmm, ok, je vais quand même testé qemu ... je l'ai mis sur un autre serveur qui n'est pas utilisé pour l'instant .. c'est un xeon quad core hyper threading (donc 8 core au total) et qui a le flag "vmx" ... maintenant, j'ai l'erreur suivante :

```
Could not open '/dev/kqemu' - QEMU acceleration layer not activated: No such file or directory
```

probablement qu'il faut que je passe ce paramètre : -enable-kvm

 :Laughing: 

Pouarf :

```
[0][root@serveur test_virtualisation]$ qemu -enable-kvm -cdrom install-x86-minimal-20100216.iso

qemu: invalid option -- '-enable-kvm'

[1][root@serveur test_virtualisation]$ cat /proc/cpuinfo | grep vmx

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc nonstop_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr sse4_1 sse4_2 popcnt lahf_lm
```

 :Sad: 

EDIT: bon, trop de problème avec kvm .. visiblement, qemu n'est pas compilé avec kvm, je n'ai aucun module kvm_intel chargable ou chargé ... bref, kvm/qemu sur RHEL 5.4, c'est dead, c'est trop récent ... 

Je vais me lancer dans Xen alors.... ou qu'y a t'il d'intéressant pour les entreprises niveau virtualisation SANS support matériel ???

----------

## man in the hill

 *loopx wrote:*   

> Mmm, ok, je vais quand même testé qemu ... je l'ai mis sur un autre serveur qui n'est pas utilisé pour l'instant .. c'est un xeon quad core hyper threading (donc 8 core au total) et qui a le flag "vmx" ... maintenant, j'ai l'erreur suivante :
> 
> ```
> Could not open '/dev/kqemu' - QEMU acceleration layer not activated: No such file or directory
> ```
> ...

 

Je crois que tu te mélanges les pinces , kvm c'est l'hyperviseur donc il faut que tu l'installes (kvm.x86_64 : Kernel-based Virtual Machine sous red hat) et le charges . Il te faut aussi charger le module kvm_intel ( se trouvant ds kmod-kvm.x86_64 : kvm kernel module(s) sous red hat) dans ton cas pour utiliser la vt du proc xeon donc quand tu visualises tes modules tu dois voir ceci :

```
lsmod

...

kvm_intel                32501  0

kvm                   253668  1 kvm_intel

...
```

à ce stade tu as activé le canal de virtualisation, maintenant il faut que tu crées tes vm avec qemu-system-x86 (au vu de la description des paquets red hat car sous gentoo c'est qemu-system-x86_64) avec l'option -enable-kvm ... Tu crées tes dd avec  kvm-qemu-img , tu vas sur le site de qemu pour avoir de plus ample explication sur toutes commandes possibles ....

note: Vu que tous les paquets sont avec l'extension .x86_64, je suppose que c'est juste une info sur l'arch de ton OS et que le nom qui nous intéresse pour lancer une commande par ex est sur la gauche, sinon tu cherches ds tes binaires et modules pour avoir les infos ...

Pas de qemu ou de kqemu

----------

## loopx

Super, j'ai réussi à charger KVM sur le nouveau serveur. En fait, j'utilise 2 serveurs :

- un vieux xeon 32 bits sans support matériel

- un nouveau xeon 64 bits avec support matériel

La, j'ai réussi ceci sur le nouveau :

```

[0][root@serveur ~]$ dmesg

[...]

kvm: virtualization flags detected on this hardware: vmx tpr_shadow vnmi flexpriority ept vpid

loaded kvm module (kvm-83-105.el5)

[1][root@serveur ~]$ lsmod | grep kvm

kvm_intel              86248  0

kvm                   223264  1 kvm_intel
```

Bon, je retente le coup avec Qemu ...

EDIT: pas moyen d'activer ce put*** de kvm  :Sad: 

```
[0][root@serveur test_virtualisation]$ qemu-system-x86_64 -enable-kvm -cdrom install-x86-minimal-20100216.iso

qemu-system-x86_64: invalid option -- '-enable-kvm'
```

EDIT2: j'ai booté avec "-cdrom" et la minimal install de gentoo ... 

- avec le "-system-x86_64" :  j'obtiens maintenant un cpu "QEMU virtual CPU" de famille "AMD" ... alors que je tourne sur un INTEL

- avec "qemu" tout court : j'obtiens un Pentium II de même fréquence que le quad xeon hyperthreading ...

Alors, faut mettre des switchs encore j'imagine ?

EDIT3: est-ce que quelqu'un aurait une doc potable (anglais ou francais) car ca fait 2 jours que je m'arrache les cheveux, que je comprend pas, que les docs, c'est dla merde et que le site qemu, c'est dla merde  :Sad: 

En fait, ce qui m'énerve la, c'est que je suis incapable de savoir si le KVM est opérationnel ou pas  :Sad:    tout ce que j'ai, c'est l'erreur comme quoi /dev/kqemu est introuvable (au lancement de qemu) ... et l'option "-enable-kvm" qui ne veut pas fonctionner .. je soupçonne red hat de ne pas avoir activer cette option à la compilation ...

EDIT4: je vais ouvrir un call chez red hat, je pense que ma situation est bloquée par red hat de manière volontaire peut être (car il ont une plateforme spécial virtualisation ....) ... Donc, je vais stoper qemu/kvm et continuer avec Xen ...

----------

## RaX

Bonjour, nous au taf on est avec CentOS 5.4 donc on peux penser que ça fonctionne de façon identique sur RH.

/dev/kqemu n'est pas utilisé par kvm en revance tu doit avoir un /dev/kvm.

Pour le lancement de qemu-kvm nous ne le lançons pas manuellement tout est géré avec libvirtd, mais si je fait un "ps" voila comment est lancé une de mes vm:

/usr/libexec/qemu-kvm -S -M pc -m 512 -smp 2 -name zimb1 -uuid 69637fdf-bdff-4401-8d0a-b4c1d390c79e -no-kvm-pit-reinjection -monitor pty -pidfile /var/run/libvirt/qemu//zimb1.pid -boot c -drive file=,if=ide,media=cdrom,index=2 -drive file=/dev/vmcorp/VM_zimb1_root,if=virtio,index=0,boot=on -drive file=/dev/vmcorp/VM_zimb1_swap,if=virtio,index=1 -net nic,macaddr=00:16:3e:0c:70:3e,vlan=0,model=virtio -net tap,fd=18,script=,vlan=0,ifname=vnet0 -net nic,macaddr=00:16:3e:0c:70:3f,vlan=1,model=virtio -net tap,fd=19,script=,vlan=1,ifname=vnet11 -serial pty -parallel none -usb -vnc 127.0.0.1:0 -k fr -serial mon:unix:/var/run/libvirt/qemu/zimb1.serial,server,nowait.

En espérant que cela puisse te dépanner.

Bonne journée.

----------

## loopx

Tout à fait, j'ai bien un "/dev/kvm" :

```
[0][root@serveur ~]$ ls -l /dev/kvm

crw-rw---- 1 root root 10, 232 Mar 12 14:09 /dev/kvm
```

Les info sont intéressantes, merci  :Smile: 

Je constate que je n'ai aucun exécutable "qemu-kvm" sur ma RHEL 5.4 ...

----------

## kwenspc

 *Quote:*   

> 
> 
> qemu-system-x86_64: invalid option -- '-enable-kvm'
> 
> 

 

Alors soit la version de qemu proposée par RH est trop vieille ou pas compilé avec le support kvm... ou alors je vois pas.  :Neutral: 

----------

## man in the hill

Le site de kvm

Lance ton install avec qemu-system-x86_64 sans l'option -enable-kvm et regarde si c'est tjrs aussi lent ...

Tape cette commande pour verifier si kvm est activé ou pas:

```
alt + ctrl + 2 

info kvm
```

----------

## man in the hill

 *man in the hill wrote:*   

> Le site de kvm
> 
> Lance ton install avec qemu-system-x86_64 sans l'option -enable-kvm et regarde si c'est tjrs aussi lent ...
> 
> Tape cette commande pour verifier si kvm est activé ou pas:
> ...

 

[EDIT]Après test rapide, il n'y a plus besoin de l'option -enable-kvm , et d'ailleurs il n'y a plus de use kvm pour le paquet qemu-kvm sous gentoo (logique pour un paquet s'appelant qemu-kvm qui pointe vers qemu-system-x86_64  :Smile:  ) donc tu peux y aller loopx avec qemu-system-x86_64 sans l'option -enable-kvm [/EDIT]

Ps: Sous gentoo c'est un peu n'importe quoi avec le paquet qemu-kvm:

```
cat /usr/bin/qemu-kvm

#!/bin/sh

exec /usr/bin/qemu-system-x86_64 --enable-kvm "$@"
```

Moi, je le renomme tjrs et fais pointer qemu-kvm vers /usr/bin/qemu-system-x86_64

----------

## kwenspc

 *man in the hill wrote:*   

> 
> 
> [EDIT]Après test rapide, il n'y a plus besoin de l'option -enable-kvm , et d'ailleurs il n'y a plus de use kvm pour le paquet qemu-kvm sous gentoo (logique pour un paquet s'appelant qemu-kvm qui pointe vers qemu-system-x86_64  ) donc tu peux y aller loopx avec qemu-system-x86_64 sans l'option -enable-kvm [/EDIT]
> 
> 

 

Ahhh en effet. Ça doit être le second effet de la mise en obsolescence du module kqemu.

----------

## loopx

 *kwenspc wrote:*   

>  *Quote:*   
> 
> qemu-system-x86_64: invalid option -- '-enable-kvm'
> 
>  
> ...

 

J'ai trouvé, j'ai ouvert un call chez red hat, et il m'ont dit .. qu'il n'y avait pas de "qemu" mais bien une commande "qemu-kvm" .. qui n'était pas dans le path et qui se trouve sur /usr/libexec/qemu-kvm  :Smile: 

Conclusion, j'ai réussi à lancer "qemu-kvm" ET démarrer (via un simple switch "-cdrom") le cd Gentoo minimal  :Very Happy:       et j'ai clairement vu la différence de perf .. plusieurs minutes sans KVM, 1 minutes ou un rien plus avec ...

Je vais faire un test chrono d'ailleur  :Wink: 

----------

## loopx

 *man in the hill wrote:*   

> Le site de kvm
> 
> Lance ton install avec qemu-system-x86_64 sans l'option -enable-kvm et regarde si c'est tjrs aussi lent ...
> 
> Tape cette commande pour verifier si kvm est activé ou pas:
> ...

 

Waaaaaaaaaaaaaaa  :Surprised: 

Il me dit : "kvm support: enable"  :Smile:   :Smile:   :Smile: 

Super, merci, mais j'ai lancé avec "qemu-kvm" ...  :Smile: 

EDIT: test avec lancement de la gentoo minimal sur Xeon 2,9Ghz Quad hyperthreading (à partir du "boot:" jusqu'a l'invite de commande sans rien touché => en attendant le timeout pour la selection du clavier etc ..) ; option=-cdrom gentoo-minimal.iso :

- avec KVM : 1 minute 18 secondes

- sans KVM : 4 minutes 1 seconde

 :Shocked:   :Shocked:   :Shocked:   :Shocked:   :Shocked: 

EDIT2: est-ce normal d'avoir un processeur "Qemu" (dans KVM est activé) et un Pentium 2 à 2,93Ghz quand j'utilise juste "qemu" ? Note que j'ai aussi cette erreur lorsque je tente d'utiliser "qemu" tout court : 

```
Could not open '/dev/kqemu' - QEMU acceleration layer not activated: No such file or directory
```

ce qui pourrait dégrader encore plus les performances ...

EDIT3: quand je fait un "info kvm" avec la commande "qemu", j'ai un "kvm support: not compiled"  :Wink: 

EDIT4: je viens de tester avec le binaire "qemu-system-x86_64", et c'est encore plus lent : 4 minutes 33 secondes pour le boot du gentoo minimal ...!! et "kvm support" n'est pas complied ...  :Wink:   donc, je vais garder "qemu-kvm" pour cette machine ^^

```

[0][root@serveur test_virtualisation]$ ls -l /usr/libexec/qemu-kvm

-rwxr-xr-x 1 root root 1803648 Aug  4  2009 /usr/libexec/qemu-kvm

[0][root@serveur test_virtualisation]$ file /usr/libexec/qemu-kvm

/usr/libexec/qemu-kvm: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped

```

EDIT5: maintenant, avant installation (et avec utilisation de "virt-manager"), il me faut un réseau pour accéder et pour que l'on puisse accéder à mon host virtuelle .. Quelles sont mes possibilités ? Puis-je créé une sous interface ???

----------

## loopx

Quelqu'un aurait une idée de ce qu'il m'arrive ... dans virt-manager, je dois créer une interface physique bridgée .. Je n'avais pas compris au début et le but, c'est de créé un br0 et d'y ajouter une seule interface : l'interface qui à l'ip de la machine. Alors, avec virt-manager, il va probablement créer une interface virtuelle et la bridgé à "br0" ou à mon interface qui possède l'ip... 

Donc, pour faire le bridge, je procède ainsi :

```
brctl addbr br0

[ifconfig br0 0.0.0.0 up]

brctl addif br0 bond0
```

Si j'oublie le "ifconfig" du milieu, je perd la connexion au serveur ...

Si je fais un simple "ifconfig br0 up", cela ne fonctionne pas non plus, il faut vraiment que j'entre aussi une ip bidon (0.0.0.0) pour que cela fonctionne  :Surprised:   est-ce normal ?

Note: je n'ai pas utilisé l'interface "eth0" mais plutôt "bond0" (on utilise du nic teaming => sous bond0, il y a eth0 et eth1 => active failover  :Smile:  ).

----------

## man in the hill

 *loopx wrote:*   

> EDIT4: je viens de tester avec le binaire "qemu-system-x86_64", et c'est encore plus lent : 4 minutes 33 secondes pour le boot du gentoo minimal ...!! et "kvm support" n'est pas complied ...   donc, je vais garder "qemu-kvm" pour cette machine ^^
> 
> ```
> 
> [0][root@serveur test_virtualisation]$ ls -l /usr/libexec/qemu-kvm
> ...

 

La c'est un vrai binaire alors que gentoo, qemu-kvm est un lien qui pointe vers  qemu-system-x86_64.

Tape qemu-system-x86_64 --help pour voir les differentes options

----------

## loopx

 *man in the hill wrote:*   

>  *loopx wrote:*   EDIT4: je viens de tester avec le binaire "qemu-system-x86_64", et c'est encore plus lent : 4 minutes 33 secondes pour le boot du gentoo minimal ...!! et "kvm support" n'est pas complied ...   donc, je vais garder "qemu-kvm" pour cette machine ^^
> 
> ```
> 
> [0][root@serveur test_virtualisation]$ ls -l /usr/libexec/qemu-kvm
> ...

 

```
[1][root@serveur ~]$ qemu-system-x86_64 --help

QEMU PC emulator version 0.10.5, Copyright (c) 2003-2008 Fabrice Bellard

usage: qemu [options] [disk_image]

'disk_image' is a raw hard image image for IDE hard disk 0

Standard options:

-h or -help     display this help and exit

-M machine      select emulated machine (-M ? for list)

-cpu cpu        select CPU (-cpu ? for list)

-smp n          set the number of CPUs to 'n' [default=1]

-fda/-fdb file  use 'file' as floppy disk 0/1 image

-hda/-hdb file  use 'file' as IDE hard disk 0/1 image

-hdc/-hdd file  use 'file' as IDE hard disk 2/3 image

-cdrom file     use 'file' as IDE cdrom image (cdrom is ide1 master)

-drive [file=file][,if=type][,bus=n][,unit=m][,media=d][,index=i]

       [,cyls=c,heads=h,secs=s[,trans=t]][,snapshot=on|off]

       [,cache=writethrough|writeback|none][,format=f][,serial=s]

                use 'file' as a drive image

-mtdblock file  use 'file' as on-board Flash memory image

-sd file        use 'file' as SecureDigital card image

-pflash file    use 'file' as a parallel flash image

-boot [a|c|d|n] boot on floppy (a), hard disk (c), CD-ROM (d), or network (n)

-snapshot       write to temporary files instead of disk image files

-m megs         set virtual RAM size to megs MB [default=128]

-k language     use keyboard layout (for example "fr" for French)

-audio-help     print list of audio drivers and their options

-soundhw c1,... enable audio support

                and only specified sound cards (comma separated list)

                use -soundhw ? to get the list of supported cards

                use -soundhw all to enable all of them

-usb            enable the USB driver (will be the default soon)

-usbdevice name add the host or guest USB device 'name'

-name string    set the name of the guest

-uuid %08x-%04x-%04x-%04x-%012x

                specify machine UUID

Display options:

-nographic      disable graphical output and redirect serial I/Os to console

-no-frame       open SDL window without a frame and window decorations

-alt-grab       use Ctrl-Alt-Shift to grab mouse (instead of Ctrl-Alt)

-no-quit        disable SDL window close capability

-sdl            enable SDL

-portrait       rotate graphical output 90 deg left (only PXA LCD)

-vga [std|cirrus|vmware|none]

                select video card type

-full-screen    start in full screen

-vnc display    start a VNC server on display

Network options:

-net nic[,vlan=n][,macaddr=addr][,model=type][,name=str]

                create a new Network Interface Card and connect it to VLAN 'n'

-net user[,vlan=n][,name=str][,hostname=host]

                connect the user mode network stack to VLAN 'n' and send

                hostname 'host' to DHCP clients

-net tap[,vlan=n][,name=str][,fd=h][,ifname=name][,script=file][,downscript=dfile]

                connect the host TAP network interface to VLAN 'n' and use the

                network scripts 'file' (default=/etc/qemu-ifup)

                and 'dfile' (default=/etc/qemu-ifdown);

                use '[down]script=no' to disable script execution;

                use 'fd=h' to connect to an already opened TAP interface

-net socket[,vlan=n][,name=str][,fd=h][,listen=[host]:port][,connect=host:port]

                connect the vlan 'n' to another VLAN using a socket connection

-net socket[,vlan=n][,name=str][,fd=h][,mcast=maddr:port]

                connect the vlan 'n' to multicast maddr and port

-net none       use it alone to have zero network devices; if no -net option

                is provided, the default is '-net nic -net user'

-tftp dir       allow tftp access to files in dir [-net user]

-bootp file     advertise file in BOOTP replies

-smb dir        allow SMB access to files in 'dir' [-net user]

-redir [tcp|udp]:host-port:[guest-host]:guest-port

                redirect TCP or UDP connections from host to guest [-net user]

-bt hci,null    dumb bluetooth HCI - doesn't respond to commands

-bt hci,host[:id]

                use host's HCI with the given name

-bt hci[,vlan=n]

                emulate a standard HCI in virtual scatternet 'n'

-bt vhci[,vlan=n]

                add host computer to virtual scatternet 'n' using VHCI

-bt device:dev[,vlan=n]

                emulate a bluetooth device 'dev' in scatternet 'n'

i386 target only:

-win2k-hack     use it when installing Windows 2000 to avoid a disk full bug

-rtc-td-hack    use it to fix time drift in Windows ACPI HAL

-no-fd-bootchk  disable boot signature checking for floppy disks

-no-acpi        disable ACPI

-no-hpet        disable HPET

-acpitable [sig=str][,rev=n][,oem_id=str][,oem_table_id=str][,oem_rev=n][,asl_compiler_id=str][,asl_compiler_rev=n][,data=file1[:file2]...]

                ACPI table description

Linux boot specific:

-kernel bzImage use 'bzImage' as kernel image

-append cmdline use 'cmdline' as kernel command line

-initrd file    use 'file' as initial ram disk

Debug/Expert options:

-serial dev     redirect the serial port to char device 'dev'

-parallel dev   redirect the parallel port to char device 'dev'

-monitor dev    redirect the monitor to char device 'dev'

-pidfile file   write PID to 'file'

-S              freeze CPU at startup (use 'c' to start execution)

-s              wait gdb connection to port

-p port         set gdb connection port [default=1234]

-d item1,...    output log to /tmp/qemu.log (use -d ? for a list of log items)

-hdachs c,h,s[,t]

                force hard disk 0 physical geometry and the optional BIOS

                translation (t=none or lba) (usually qemu can guess them)

-L path         set the directory for the BIOS, VGA BIOS and keymaps

-bios file      set the filename for the BIOS

-kernel-kqemu   enable KQEMU full virtualization (default is user mode only)

-no-kqemu       disable KQEMU kernel module usage

-no-reboot      exit instead of rebooting

-no-shutdown    stop before shutdown

-loadvm [tag|id]

                start right away with a saved state (loadvm in monitor)

-daemonize      daemonize QEMU after initializing

-option-rom rom load a file, rom, into the option ROM space

-clock          force the use of the given methods for timer alarm.

                To see what timers are available use -clock ?

-localtime      set the real time clock to local time [default=utc]

-startdate      select initial date of the clock

-icount [N|auto]

                enable virtual instruction counter with 2^N clock ticks per instruction

-echr chr       set terminal escape character instead of ctrl-a

-virtioconsole c

                set virtio console

-show-cursor    show cursor

-tb-size n      set TB size

-incoming p     prepare for incoming migration, listen on port p

-chroot dir     Chroot to dir just before starting the VM.

-runas user     Change to user id user just before starting the VM.

During emulation, the following keys are useful:

ctrl-alt-f      toggle full screen

ctrl-alt-n      switch to virtual console 'n'

ctrl-alt        toggle mouse and keyboard grab

When using -nographic, press 'ctrl-a h' to get some help.
```

mais maintenant, plus besoin, vu que j'ai le "qemu-kvm"  :Smile: 

De plus, maintenant, j'utilise "virt-manager" pour créer mes machines virtuelles  :Smile:    ca roxxxxx et j'ai réussi à créer une VM qui s'est installé via PXE et tout le tralala  :Smile: 

Seul problème qu'il me reste : impossible de faire CTRL+ALT+2 (pour faire un "info kvm" par virt-manager). Et un autre problème trèèèèès embêtant, c'est le boot sur un disque SCSI .. impossible, il n'en veut pas  :Sad: 

Je vais ouvrir un call chez red hat  :Wink: 

----------

## loopx

Suite au call, j'ai appris que le type VIRTIO est meilleur que SCSI et donc, j'ai testé et j'y suis arrivé  :Smile:    même directement à installé, via PXE, sur un disque en VIRTIO  :Wink: .

Demain, je tente le coup avec le VIRTIO pour la carte réseau direct à l'install :p

----------

## kwenspc

T'aurais lu la(les) doc(s) tu aurais pas eu besoin d'un call   :Wink: 

----------

## man in the hill

 *kwenspc wrote:*   

> T'aurais lu la(les) doc(s) tu aurais pas eu besoin d'un call  

 

+1, surtout que les infos abondent (deja ds le topic gentoo) et que ce n'est pas un logiciel proprio inconnu au bataillon du www ...  :Very Happy:  mais ça fait bosser le support red hat, le client est roi ...

Je me suis emballé aussi au début pour la libvirt et virt-manager mais ait tjrs tes scripts avec qemu-kvm sous la main pour lancer et stop tes vm ...

----------

## loopx

 :Embarassed: 

J'ai un gros problème niveau réseau sur ma machine de test ... C'est un problème de bridge ... Je ne sais pas si ca provient de l'interface réseau VIRTIO que j'ai ajouté hier avant de quitter le boulot ... quand je suis arrivé le matin, la machine était up depuis 1h30, mon collègue l'avais redémarré .. plus de réseau (machine pas planté, mais bien le réseau)...

Voici la config que j'ai :

```

br0

|    \

|      \     

|        \

|          <vnet0, vnet1, ...>      

bond0

|       \

eth0   eth1

```

bond0 à l'ip de la machine physique : eth0 et eth1 n'ont pas d'ip

Le bridge br0 à une ip 0.0.0.0 ...

les vnet0 n'ont pas d'ip (mais en ont dans la machine virtuelle .. forcément)

Après un temps (peut être lié à l'utilisation d'une carte réseau VIRTIO juste avant), le bridge refuse de fonctionner .. le ping ne fonctionne plus, je dois prendre la machine en KVM et la, je m'appercois qu'elle n'est pas planté mais que le réseau ne fonctionne plus ... Je fais un remove de "bond0" pour le bridge "br0" et je la replace ... ca refonctionne .. mais tantot, ca à refonctionné 2 min ...

Je me demande si la technique de mise en place du bridge n'est pas le problème ...   car après que cela refonctionne, je peux pinger ma machine physique d'une autre machine ... mais l'inverse ne fonctionne pas   :Shocked:   bref, de l'intérieur de la machine, on ne peux plus pinger .... étrange ..

----------

## man in the hill

 *loopx wrote:*   

> 
> 
> J'ai un gros problème niveau réseau sur ma machine de test ... C'est un problème de bridge ... Je ne sais pas si ca provient de l'interface réseau VIRTIO que j'ai ajouté hier avant de quitter le boulot ... quand je suis arrivé le matin, la machine était up depuis 1h30, mon collègue l'avais redémarré .. plus de réseau (machine pas planté, mais bien le réseau)...
> 
> Voici la config que j'ai :
> ...

 

ça a l'air compliqué ton bridge ...

Moi j'aurais bridgé tous les interfaces physiques et virtuelles avec br0 .... (c'est ce que je fais ...)

Tu utilises combien d'interface physique, ta machine fait routeur ?

Un lien pour red hat ici

Le site de linux bridge

Essais de mettre ça proprement en cli, ensuite tu verras avec virt-manager ....

----------

## loopx

J'ai réussi à configurer mon bridge  :Smile: 

Ben, c'est pas compliqué, et je n'ai aussi qu'un bridge : br0 (ou se trouve l'interface qui possède l'ip de la machine ainsi que les interface virtuelle des VM qui sont en exécution).

Donc, quand je boot la machine, j'ai br0 avec "bond0" et les X interface réseau virtuelle utilisée dans les VM.

Ce qui est plus compliqué, c'est le bonding ... bond0, c'est une interface qui se positionne sur eth0 et eth1 (2 interfaces réseaux physique connecté à 2 switchs différents). Via une requête ARP chaque seconde, le module "bonding" est apte à savoir quelle interface est up ou down (requête ARP vers la gateway du serveur) et vu la config que je lui ai mis (active failover), si le lien actif tombe, l'autre carte prend la relève .. sauf si on a pas de chance et que les deux interface sont down ... (ce qui est peu probable).

Bref, je pense que c'est assez parfait ainsi : 

eth0 => bond0 => br0 <= interfaces virtuelles

eth1 /

Une dernière question avant de clôturer ce threads ... pensez-vous que Qemu/KVM est la meilleur technologie au niveau des performances/rendement de la virtualisation (pour des invités non modifié) ?

----------

## man in the hill

 *loopx wrote:*   

> J'ai réussi à configurer mon bridge 
> 
> Ben, c'est pas compliqué, et je n'ai aussi qu'un bridge : br0 (ou se trouve l'interface qui possède l'ip de la machine ainsi que les interface virtuelle des VM qui sont en exécution).
> 
> Donc, quand je boot la machine, j'ai br0 avec "bond0" et les X interface réseau virtuelle utilisée dans les VM.
> ...

 

ok

 *loopx wrote:*   

> Une dernière question avant de clôturer ce threads ... pensez-vous que Qemu/KVM est la meilleur technologie au niveau des performances/rendement de la virtualisation (pour des invités non modifié) ?

 

Pour moi c'est très bien et en plein devel, j'ai une vm 2008 server qui fait du tse et ça fonctionne très bien, j'ai aussi des xp avec des logiciels client/serveur ... Accès ssh pour l'hôte (et c'est la que la cli est interessant car tu peux manipuler facilement les vm, virt-manager a un accès distant utilisant ssh mais je n'ai pas eu de test concluant quand je l'avais testé ...) et vnc ou rdp pour la vm et ça roule ... Un truc qu'il faut bien calculer surtout quand tu utilises des vm windows,  qemu/kvm est limité à 2047M (2Go) de mémoire ...

Je connais xen, virtualbox,vmware gratuit (pas vmware payant) et qemu/kvm est très simple à mettre en place avec un cout de revient nul, une devel intense open source donc je pense que c'est un très bon choix pour une entreprise. Après faut faire tes tests pour voir si cela te convient ... Je te signale qu'il existe des pilotes virtio pour windows, si tu ne le savais pas encore ...

----------

## loopx

2Go de mémoire max par VM   :Shocked:    c'est un peu foireux ca :/

Sinon, j'ai testé la migration avec virt-manager, mais ca ne fonctionne pas.

Donc, je test la sauvegarde de la VM ... mais je ne comprend pas pourquoi, dans virt-manager, la machine doit être allumée pour faire un backup ... et lorsqu'il fait le backup, il éteind la machine et ne la rallume pas  :Very Happy:    vraiment bizare ...

----------

## kwenspc

 *loopx wrote:*   

> 2Go de mémoire max par VM     c'est un peu foireux ca :/

 

Sur x86 32bits seulement! Sur 64 bits c'est plus. 

Et ça m'étonnerait que tu ais besoin de cinquante douze giga pour une vm... Qui plus est, si tu utilises des vm sous nux, tu devrais utiliser virtio-balloon qui permet d'augmenter/diminuer la ram de la vm selon ses besoins.

[edit] tiens apparemment ça marche aussi pour win. http://www.linux-kvm.com/content/balloon-driver-code-added-windows-guest-driver-gpl-repository [/edit]Last edited by kwenspc on Tue Mar 16, 2010 4:53 pm; edited 1 time in total

----------

## loopx

 *kwenspc wrote:*   

>  *loopx wrote:*   2Go de mémoire max par VM     c'est un peu foireux ca :/ 
> 
> Sur x86 32bits seulement! Sur 64 bits c'est plus. 
> 
> Et ça m'étonnerait que tu ais besoin de cinquante douze giga pour une vm... Qui plus est, si tu utilises des vm sous nux, tu devrais utiliser virtio-balloon qui permet d'augmenter/diminuer la ram de la vm selon ses besoins.
> ...

 

Ouf, c'est une 64  :Smile:   et j'ai déjà tout optimisé presque ... look :

```
[0][root@qemu ~]$ lspci

00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)

00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]

00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]

00:01.2 USB Controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev 01)

00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)

00:02.0 VGA compatible controller: Cirrus Logic GD 5446

00:03.0 Ethernet controller: Qumranet, Inc. Virtio network device

00:04.0 SCSI storage controller: Qumranet, Inc. Virtio block device

00:05.0 RAM memory: Qumranet, Inc. Virtio memory balloon
```

maintenant, aucune idée de comment gonfler le balon  :Surprised: 

EDIT: 2Go, c'est trop peu, 4Go, c'est quand même mieux .. 72Go de mémoire, la oui, ca devient abusif  :Very Happy:   et j'ai meme pas de machine physique avec ce genre de quantité ..

----------

## kwenspc

 *loopx wrote:*   

> 
> 
> maintenant, aucune idée de comment gonfler le balon 

 

Faut boire avant, pour avoir le bon effet  :Laughing: 

----------

## loopx

Nan, c'est mauvais pour la ram ^^

le lien à un légé "edit" en trop   :Laughing: 

http://www.linux-kvm.com/content/balloon-driver-code-added-windows-guest-driver-gpl-repository

EDIT: je viens de lui mettre 10Go de mémoire, il a pas branché  :Very Happy:   et j'ai 10Go dans une VM ^^

----------

## man in the hill

 *kwenspc wrote:*   

>  *loopx wrote:*   2Go de mémoire max par VM     c'est un peu foireux ca :/ 
> 
> Sur x86 32bits seulement! Sur 64 bits c'est plus.

 

Je savais pas ça, je vais tester mais je pense que cela va évoluer rapidement  ... j'espère ... 

 *loopx wrote:*   

> EDIT: je viens de lui mettre 10Go de mémoire, il a pas branché  et j'ai 10Go dans une VM ^^

 

Une vm linux ?

----------

## loopx

 *man in the hill wrote:*   

>  *kwenspc wrote:*    *loopx wrote:*   2Go de mémoire max par VM     c'est un peu foireux ca :/ 
> 
> Sur x86 32bits seulement! Sur 64 bits c'est plus. 
> 
> Je savais pas ça, je vais tester mais je pense que cela va évoluer rapidement  ... j'espère ... 
> ...

 

Yes sir  :Smile: 

----------

## loopx

 *man in the hill wrote:*   

>  *kwenspc wrote:*    *loopx wrote:*   2Go de mémoire max par VM     c'est un peu foireux ca :/ 
> 
> Sur x86 32bits seulement! Sur 64 bits c'est plus. 
> 
> Je savais pas ça, je vais tester mais je pense que cela va évoluer rapidement  ... j'espère ... 
> ...

 

Yes sir  :Smile: 

----------

