Reprise du message précédent :

j'ai jamais eu de soucis avec les snapshots, mais la BDD c'est tout de même différent (un FS moderne -journalisé-, pas de problème de corruption)
Pour la BDD, si elle est arrêtée oui, mais c'est vraiment plus simple de la dumper via un cron nocturne, quitte à récup ce fichier dans le snapshot après.

ok, effectivement le dump à l'intérieur du snapshot me parait pas mal comme solution.

Un truc auquel j'avais jamais pensé, mais quand on restaure un snapshot ça ne pose pas de problème au système invité l'heure qui change brusquement ?

 
Tu vas booter sur le machine, donc il va récupérer le temps au boot.

mais un snapshot, ce n'est pas une image d'un système déjà booté ?
 
( désolé pour les question de noob )

Vous parlez pas des même snaphsots là
 
Et aucun ne pose de problème de ce genre

 
LVM il s'en fout qu'il soit allumé ou éteint. Lui il snapshot. Et si tu montes se snapshot pour le booter afin d'avoir une VM clone, il n'y aura pas de soucis.

d'accord, un snapshot LVM (je ne suis pas très familier avec LVM non plus en fait). Donc si tu fais un snapshot de la partition LVM d'une VM allumée, ça se passe comment quand tu la restaures/clones ailleurs ? du point de vue OS invité ça fait comme si le système rebootait salement alors ?

C'est tout à fait ça
Et généralement ça se passe très bien avec les FS actuels.

 
Voilà c'est tout à fait cela

ah ok, merci à vous
 

bon, j'ai du mal à comprendre le mécanisme de fonctionnement des snapshots LVM. Notamment sur la page wikipédia il est dit que les snapshots ne sont pas une sauvegarde complète du volume, à partir de là comment on peut faire une restauration en cas de crash si on n'a pas de sauvegarde complète ? comment ça marche exactement ?

 
c'est une photo à l'instant de t de ton FS, qui grossi (en différentiel) à chaque fois que ya des modifs (enfin une différence) sur le FS d'origine. D'où la rapidité du snapshot.

comme je le comprends, ça veut dire en quelque sorte qu'au moment où on fait le snapshot on arrête d'écrire sur l'espace actuel et on écrit toutes les modifications sur un nouvel espace, et ensuite si on peut donc tranquillement backuper le premier espace (puisqu'il ne bouge plus). C'est ça ?

 
non : ton snapshot est fait sur un volume à coté, et ça continue d'écrire sur le volume d'origine. C'est ce snapshot que tu va monter à coté pour par exemple récup fichiers.

ce qui veut dire qu'une fois qu'on a fait un snapshot, toute nouvelle écriture entraîne en fait l'écriture effective sur le volume d'origine + l'écriture du différentiel (pour retrouver l'état à l'instant t du moment où on a fait le snapshot) sur le volume créé lors du snapshot ? si c'est ça ça veut dire qu'on ne peut rien backuper ailleurs puisque tout continue d'être écrit en permanence... du coup je pense que j'ai pas compris.

 
De mémoire xen list images c'est pour les fichiers de conf. Si ta vm apparait pas dans xm list, c'est qu'elle n'a pas démarré.

Effectivement elle n'a simplement pas démarré, c'est le "Started new Xen guest" qui m'avait induit en erreur. Rien à voir avec un problème de réseau donc (du coup j'ai effacé mon post, juste au moment où tu répondais malheureusement).

si je comprends bien pour la démarrer je dois donc faire "xm create /etc/xen/mondomU.cfg". Mais quand je le fais, j'ai ce résultat :

il manque de RAM donc.
Comme c'est préconisé un peu partout j'ai interdit le ballooning et fixé la quantité de RAM utilisée par dom0 : dans le fichier de conf de xen, (dom0-min-mem 1024) et (enable-dom0-ballooning no) ainsi que dans la conf de grub l'option GRUB_CMDLINE_XEN="dom0_mem=1024M"

Dom0 se limite donc effectivement à 1Go de RAM mais du coup il a l'air de vouloir prendre dans ce pool pour créer les VMs au lieu de prendre dans le reste (mon serveur a 20Go, xm info le détecte bien en tant que total_memory ).
Y'a un truc que je dois avoir fait de travers mais je comprends pas quoi.

Donne la sortie de :
xm info | grep mem
 

total_memory           : 20469
free_memory            : 762
node_to_memory         : node0:762
node_to_dma32_mem      : node0:387

 
Il te reste 762 Mo de dispo pour Xen Ta du faire une erreur quelque part dans ta conf

ben j'ai limité (via l'option GRUB_CMDLINE_XEN="dom0_mem=1024M" ) la mémoire à 1Go comme c'est recommandé dans le guide ici (section "Configure Domain 0 Memory" ), le système dom0 doit occuper environ 238 et du coup il reste 762, c'est comme ça que je le comprends.

Je vais essayer sans cette option de boot pour voir, mais du coup je comprends pas bien pourquoi c'est recommandé de faire comme ça.

nan l'option est bonne. (dans defaut de grub)
# Xen
GRUB_DISABLE_OS_PROBER=true
GRUB_CMDLINE_XEN="dom0_mem=1024M dom0_max_vcpus=2 dom0_vcpus_pin"

Bonjour,
 
Petite question de débutant :
La config : host archlinux x86_64 (réseau ethernet sur eth0, config en dhcp), virtualbox et guest Windows XP sp3 (accès par pont sur eth0, dhcp également)
 
Quand je suis sur le réseau de ma boite, aucun soucis, j'arrive à faire communiquer les deux environnements via réseau sans aucun souci (j'ai des serveurs sur les deux environnements).
 
Par contre dès que je sors du réseau, comment faire pour faire communiquer les deux environnements via le réseau ?
 
Merci d'avance

ok de toutes façons j'ai essayé sans, ça change rien.

bon bah niveau mémoire il ne me reste plus qu'à toucher au dom0-min-mem et au enable-dom0-ballooning pour voir ce que ça fait alors, je crois pas avoir touché à quoi que ce soit d'autre.

Ma conf qui marche :  
(dom0-min-mem 1024)
(enable-dom0-ballooning no)
(total_available_memory 0)
 
Check ça.

C'est le paramètrage que j'avais au début. Je l'ai remis et sans surprise le résultat est le même.
 
J'ai presque envie d'installer une testing pour voir si ça fait la même chose  

T'as relancé xend après la modif de la config ?
T'as rebooté le serveur après la modif de grub ?
 
Si tu fais "xm list" il doit t'afficher la mémoire prise par le dom0 (dans le cas ou s'est fixé par grub), ça t'indique quoi ?

j'ai carrément rebooté après chaque modif, et pour ce qui est de xm list :

donc c'est pas bon ? ça devrait m'afficher 1024 ? comment je peux vérifier que les arguments passés au kernel via /etc/default/grub sont bien pris en compte au reboot ? (oui j'ai bien fait update-grub)

Enfin dans tous les cas c'est bizarre, même sans fixer la mémoire pour le dom0, tu devrais pouvoir lancer ta VM qui ne demande que 1G

Regarde le fichier /boot/grub/grub.cfg généré, tu devrais retrouver ce que t'as défini dans le /etc/default/grub sur la ligne concernant xen, genre :
        multiboot       /boot/xen-4.0-amd64.gz placeholder dom0_mem=1024M  

Réponse à moi-même : a priori le mode réseau host-only permet de gérer mon cas, je vais tester ça

ah zut ça y est j'ai compris, en fait j'avais déjà ajouté une ligne GRUB_CMDLINE_XEN pour autre chose, du coup celle pour limiter la mémoire à 1024 n'était pas prise en compte, du coup ça utilisait quasiment les 20Go, et avec le ballooning à off pas moyen d'en libérer.

C'est réglé, ça marche. Erreur humaine what else   et merci à vous !

 
Voilà, ça expliquait le soucis
 
Impec, te voilà ready du Xen du coup

OpenVswitch dans VmWare ? pour remplacer leurs bridges tout pourri ? concurrence directe au NexusV1000 ? Impact (arrêt ?) sur le développement d'openvswitch ? gestion type openflow dans Vmware ? et/ou via tunnel GRE ?
http://www.lemondeinformatique.fr/ [...] 49851.html

coup de maitre de vmware...

Nous le sentions arriver ... l'inclusion dans le kernel main stream s'est qu'en même faite avant ...
En tout cas VmWare va disposer d'une nouvelle corde à leurs arcs (déjà bien fournis)

salut a tous
 
savez vous comment je peux faire en sorte que l'ecran de ma machine virtuelle qemu soit en 1366x768?
 
par defaut je peux changer sur les resolutions "standard" en 4:3 mais c'est tout

les gens qui ont du dom0 Xen, vous monitorez comment les IO sur vos disques ? là j'essaye en SNMP (les entrées diskIOReads et diskIOWrites) mais déjà c'est chiant parce qu'il n'y a pas d'OID qui donne directement un nombre d'opérations par seconde (ou alors j'ai pas trouvé), seulement un compteur donc c'est pas pratique, et ensuite ce qui est curieux c'est qu'en relevant de cette manière le nombre d'IOPS est souvent plus élevé sur le lv du dom0 que sur le disque physique entier, donc j'ai un peu de mal à comprendre (ma config étant une paire de disques en raid1 hard, avec un vg qui prend tout l'espace et 3 lv, un pour chaque dom). D'ailleurs je vois qu'iostat donne les mêmes chiffres. Le nombre d'IOs sur le disque physique ne devrait-il pas être le total de celui de tous les LV ?

Et vous, vous faites comment ?

 
munin est pas mal pour ça, sinon un plugin NRPE avec Shinken (ou Nagios)

en fait on a déjà un NMS et il n'est pas envisageable d'en changer, je me posais plutôt la question de comment récupérer des informations fiables et valides et de la bonne manière de les interprêter, puisque là en l'état je sais récupérer des chiffres mais je ne suis pas sûr de ce qu'ils veulent dire.