Reprise du message précédent :

Ben DHCP maitrise les adresses IP en fonction des adresses MAC, t'es pas forcé de le laisser faire ce qu'il veut

Oui enfin j'entends par la que mettre a jour le serveur dhcp à chaque coup n'est pas très pratique...
 
Pour le moment je me résigne à démarrer ma nouvelle VM dupliquée et faire les changments à la main faute de mieux.

C'est pas plus compliqué que de modifier la conf de la vm, m'enfin...

A la base je souhaité automatiser la tache de duplication d'une VM, c'est-à-dire que lorsque je duplique une vm j'aimerai qu'elle soit totalement opérationnelle.
 
La il faut que j'arrete la première VM, allume la seconde modifie le hostname et les ip puis redemarrer la vm. Enfin redemarrer la vm originale.
 
Je trouve ça contraignant. J'aurai préferai directement spécifier les ip et le hostname dans le fichier de conf de la vm et bast comme on dit

Alors :
1) si tu ulises DHCP t'as rien à modifier dans la VM, pisqu'elle se configure en DHCP... tu modifies la mac dans ta config, tu rajoute la machine dans le DHCP et basta
2) Tu sais que tu peux modifier le contenu d'une VM sans la lancer ? (et encore heureux )

1) DHCP, trop contraignant    
 
2) J'utilise des VM au format block device avec du LVM donc c'estun peu galère à monter comme FS d'autant plus que cela peut poser des problèmes car l'hypervisuer aussi est un LVM donc je me retrouve avec les mêmes labels une fois la VM montée  

   
 
sinon au pire, tu fais un snapshot d'une Vm propre, tu le montes, tu copies les fichiers ailleurs. Ensuite tu peux faire un script pour customiser tous les paramètres que tu souhaites (ip, nom) en modifiant ces fichiers, puis tu crées ta machine avec la methode copy de xen-tools.

Oula, merci pour la réponse, mais c'est pas vraiment pratique de monter le FS de la VM pour aller ensuite modifier les infos pour les raisons indiquer plus haut.
Mais je vais y réfléchir quand même car le fait de démarrer la nouvelle VM m'oblige à me logguer sur la machine avec le compte root puis à la rebooter et ça c'est encore moins top .
 
Je vais partir du coté de lsof pour pas avoir de problème    
 
Bref pour le moment pas de méthode vraiment simple pour automatiser la duplication d'une VM  

C'est toi qui ne fait pas/voit pas les choses simplement je pense

C'est simplement que je me fixe des contraintes pour voir si c'est un produit viable .

 
Attend, ca prend 10 minutes à faire la 1ere fois , et 30sec après    
 

 
+1  

http://etbe.coker.com.au/2008/10/2 [...] 64bit-xen/

Je teste si c'est un produit viable, donc chacune des opérations que je fais est scriptée, or dupliquer une VM est plus complexe qu'il n'y parait
 
Mais maintenant je vois toutes les solutions qui s'offrent à moi même si elles ne sont pas forcément très aisées
 

Ce qui est dommage c'est qu'il explique pas son choix de dom0 en 2.6.18 et domU en 2.6.26

Voilà, la solution de booter la VM etde lancer un post script pour modifier les IP marchent bien  
 
MErci pour votre aide
 
Sinon je regardai un peu du coté des migrations, si j'ai bien compris la mémoire est migrée sur un canal non crypté par défaut ?
 
Par contre je ne comprend pas bien pour le moment, à quoi correspondent les éléments suivants :
#(xend-http-server no)
(xend-unix-server yes)
#(xend-tcp-xmlrpc-server no)
(xend-unix-xmlrpc-server yes)
#(xend-relocation-server no)
(xend-relocation-server yes)
 

c'est pour acceder à xend via :
- http
- socket-unix
- xml/rpc
Utilisé par certains outils /certaines libs pour controler le dom0 à distance ou meme localement.
 
le relocation server c'est pour migrer les VM

Ok, donc avec ça je peux controler mon Dom-0 via une application distante , super . Ca pourra être utile.
 
Bon alors par contre grosse decéption, je viens de réaliser une migration en mode live et l'horloge du système déconne... (elle se fige notamment, le système répond mais aucunes modifs possibles )
 
On peut réaliser 2 migrations en mode live succesivement (1 à 2 min d'intervalles) ?

Tes disques sont dispos des deux cotés ?
J'ai comme un gros doute vu ton histoire de LVM

Il y a quelque chose que j'ai du mal a comprendre pour la migration, la domU doit elle  se trouver obligatoirement sur un partage réseau (san, nfs, iscsi ...) et donc monté sur 2 hyperviseurs en meme temps ?

=> e_esprit
 
Oui les disques sont bien vu des 2 cotés correctement. En fait je viens de voir que la migration se passe tjrs bien dans un sens mais pas dans l'autre...
 
La mémoire est OK, le réseau également.
Le disque est vu de la même manière de chaque coté des hyperviseurs (/dev/mapper/id_du_disk)

Oui, tu peux rajouter drbd à ta liste aussi

Pour la migration, j'ai résolu mon problème en synchronisant les DOM-U avec le DOM0 via le démon ntp (ntpd)
 
Alors petit edit pour parler du problème suivant    
 
Après une migration live, impossible de rebooter la VM (la machine s'arrete mais ne redemarre pas)
J'ai passé le fichier de conf de la VM sur mes 2 DOM-0 mais en fait il utilise un kernel-image temporaire dans /var/lib/xen en lieu et place du fichier de conf dans /etc/xen
 
Une idée pour contourner le problème ?

salut, vous avez quoi comme vitesse de transfert entre un guest et un host.
Je trouve ça hyper lent avec virtualbox

vous utilisez quoi pour minitorer vos dom0 ?
 
J'ai trouvé des script pour munin,  perso j'utilise zabbix mais c'est facilement adaptable

Hello à tous,
Je n'arrive pas sur Virtualbox à integrer ma Debian virtuelle sur le réseau.
Voila ma conf:


 
 

 
Que dois-je changer pour que la debian virtuelle profite du dhcp et du réseau ?
 
 
 
 
Edit: Si je met en NAT, celà fonctionne, mais j'ai une IP en 10.quelque chose alors que mon réseau en 192.168.2.
Donc ma machine virtuelle a le net, mais en tapant son ip sur ma machine réelle par exemple, forcement, je n'ai rien...

Faut passer en bridge. Je crois que c'est expliqué dans la partie consacrée au réseau dans la doc.

oui il faut créer un interface bridge dans la config réseau en selectionnant l'interface physique et l'interface virtuelle, click droit.

tout est dans la doc bridge, script toussa

et d'ailleurs à ce sujet, j'aimerai savoir si il y a moyen d'obtenir des meilleurs de transferts entre guest et host car ça la misère là

Entre hôte linux et guest windows, le partage de fichier est très très lent.
Du moins, c'est le temps de réaction qui est lent, pas le débit une fois que ça transfère. Par moment, ça prend plusieurs minutes avant de bouger.
En cherchant un peu, il y a quelques mois, j'avais trouvé pas mal de monde qui s'en plaignait mais aucune solution.

En effet, j'ai la bonne ip toussa, merci, en fait j'arrivais pas a faire le bridge parsque la connexion vmware était partagée    
 
Bon, reste plus qu'a pour acceder au serveur samba depuis kde  

 
c'est lent dans l'autre sens aussi avec host windows

Question : j'ai installé ces paquets du depot debian. Je suis sous etch64.
 
ii  linux-image-2.6.18-6-xen-amd64       2.6.18.dfsg.1-22etch2                Linux 2.6.18 image on AMD64
ii  linux-modules-2.6.18-6-xen-amd64     2.6.18.dfsg.1-22etch2                Linux 2.6.18 modules on AMD64
ii  xen-hypervisor-3.0.3-1-amd64         3.0.3-0-4                            The Xen Hypervisor on AMD64
ii  xen-ioemu-3.0.3-1                    3.0.3-0-4                            XEN administrative tools
ii  xen-linux-system-2.6.18-6-xen-amd64  2.6.18.dfsg.1-22etch2                XEN system with Linux 2.6.18 image on AMD64
ii  xen-tools                            2.8-2                                Tools to manage debian XEN virtual servers
ii  xen-utils-3.0.3-1                    3.0.3-0-4                            XEN administrative tools
ii  xen-utils-common                     3.0.3-0-2                            XEN administrative tools - common files
 
linux-serv:~# xm info | grep ^xen_caps
xen_caps               : xen-3.0-x86_64 hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64
 
Est ce que je peux deployer des Etch 32 bits avec ces paquets ?

Oui mais en HVM seulement à priori

Bon j'ai installé etch 32 bits en HVM et ca marche sur un dom0 etch 64 bits.
 
Le problème, je n'arrive pas à attacher la console quand je démarre le domU :
 
info-test4:~# xm create -c /etc/xen/etch32.cfg
Using config file "/etc/xen/etch32.cfg".
VNC= 1
Started domain etch32
xenconsole: Could not read tty from store: No such file or directory
 
Je me connecte en VNC pour l'instant.
 
Des idées?

y'a pas de console pour les domU hvm

Ok bon j'arrète de chercher alors
 
Au juste, pour mixer du 32 bits / 64 bits natif (sans hvm, sur un dom0 64 bits), il faut xen 3.1 minimum.
 
Sinon deux options pour lesquelles je n'ai pas trouvé d'info pour un host hvm :
 
device_model
memmap  
 
Ca correspond a quoi ?

Tiens mais ce serait le bon topic pour poser ma question : au cas ou, si un modo veut merger http://forum.hardware.fr/hfr/OSAlt [...] 8262_1.htm ici :-)
C'est un probleme avec virtualbox, et la mise en reseau d'un OS invite.

device_model  The device emulation tool for HVM guests. This parameter should not be changed.
http://www.cl.cam.ac.uk/research/s [...] /user.html
 
L'autre je sais pas.

Voila mon fichier de config , ca tourne mais je ne sais pas si l'on peut l'améliorer :
 
kernel = "/usr/lib64/xen-default/boot/hvmloader"
builder='hvm'
memory = '256'
name = 'etch32'
disk = [ 'phydev/xen-lvm/etch32-disk,ioemu:hda,w','phydev/xen-lvm/partimage,ioemu:hdb,w','filetmp/ETCH32.ISO,ioemu:hdc:cdrom,r' ]
vif = [ 'type=ioemu, bridge=xenbr0' ]
device_model = '/usr/lib64/xen-default/bin/qemu-dm'
boot='dc'
vnc=1
vncpasswd=''
vncviewer = 1
vncdisplay = "5900"
serial = "pty"
keymap="fr"
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'
vcpus=1
acpi=1
apic=1
 
 
Au passage, j'ai un pb : j'ai le réseau pendant l'install sur le domU puis au 1er reboot plus rien, et eth0 ne veut pas se monter alors qu'elle est reconnue dans lspci. 8139too et 8139cp sont chargés !! comment faire ? je suis en bridge.