Reprise du message précédent :
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.

J'utilise pas beaucoup SNMP parce que je trouve ça un peu le bordel.. Après ta toujours moyen de récupérer via des scripts perso et sysstats des données plus parlantes...

zabbix

J'ai un serveur sous ProxMox 1.9 avec des VM Debian en OpenVZ.
 
Je souhaite migrer l'une des VM OpenVZ (103) vers ESXi.
 
Pour ce faire, j'ai sous la main 2 tuto ; je bloque sur les deux aux étapes ci dessous  
 
1. http://www.raphink.info/2012/03/fr [...] mware.html
Install grub on the disk:

 
2. http://communities.vmware.com/message/1719787#1719787
convert  image to VMDK format

 
Si vous avez une idée ou avez une autre méthode pour passer une VM en OpenVz de Proxmox à ESXi, je suis preneur !
 
++

Pourquoi tu bloque sur le grub-install ?
En gros, il te dit qu'il installe grub en complet en créant un /boot dans ton fichier (avec un FS rempli de 0) et qu'il créer un secteur d'amorçage dessus

La problématique : à priori une VM OpenVZ dans Proxmox ne contient pas le boot ; du coup, si on veut migrer directement une VM Proxmox OpenVZ vers ESXi = la VM ne bootera pas.
Tag : OpenVZ 2 ESXi ; Proxmox 2 Esxi ; OpenVz to VMWare  
 
Voici donc la manip, adapté à mes besoins
 
Je crée un image de 2 Go

 
Là il me dit

Je réponds Y
 
Je crée le dossier /mnt/tmp
 
Ensuite je monte l'image

 
Je copie dans le répertorie /mnt/tmp qui correspond au RAW galerie.img

 
C'est là que je tente d'ajouter le bootloader :

 
L'erreur que j'obtiens :

 
Où est ce que je me plante ??
 
++

C'est peut être pas /dev/loop, mais /dev/loop0 ou /dev/loopX.
Regarde avec "losetup -a"

 
C'est trop la lose ce truc ^^
 

 
du coup, je retente avec grub :

tente à coup de chroot
mount -o bind /dev /mnt/tmp/dev
mount -o bind /proc /mnt/tmp/proc
mount -o bind /sys /mnt/tmp/sys
chroot /mnt/tmp
grub-install /dev/loop0

Sinon édite le fichier device.map et rajoute "(hd0) /dev/loop0" dedans.

Au moment de :

=> : grub-install: command not found

Ah ben faut installer grub dans ton disque virtuel, hein

Oulah, oulah, y'a des soucis dans ta procédure (celle juste après ma réponse)
 
On reprend dans l'ordre (j'adapte suivant se que tu me dit en mettant en gras se qu'il te manque avec le pourquoi de l'action)
 

on créer notre fichier rempli de 0 de 2gigs

on va créer une table de partition, important a faire ça ! avec ça comme param : o n p 1 2048 w pas de table de partition = la suite du tuto marchera pas et grub voudra rien savoir <_<

on monte un loopback qui va simuler un block device pour notre image, sinon mk2fs nous fera chier sa maman et a partir de ce moment là, on ne travaillera plus en mode image puisqu'on aura un block device virtuel (le driver loop s'occupe de tout, sinon grub peu pas bosser non plus /!\ne pas oublier de renseigner le -o cylindre par rapport a ta taille de partoche ! /!\)

on formate le block device monté avec une taille de block de 1k

on installe une journalisation sur le block device, optionnel

on monte notre block device dans un coin, on s'en fou de dire que c'est un loop a mount, puisque le block device virtuel a déjà été configuré AVANT

tu fait ta copie du raw

et hop on grubise, pas de "="

Merci de te pencher sur le sujet.
 

Je suis sous Debian Sqeeze, la version Proxmox OpenVZ ... et là il n'y a pas le paramètre o ni n  
 
Par contre en faisant comme : http://www.omninerd.com/articles/I [...] Image_File

Là je peux mettre les paramètres o n p 1
... il me demande alors  

A priori la bonne syntaxe serait :

Avec de légères corrections :
 
Créer notre fichier rempli de 0 de 2gigs :

 
Créer une table de partition, important a faire ça !

 
.... avec ça comme param : o x c 2048 r n p 1 2048 w pas de table de partition = la suite du tuto marchera pas et grub voudra rien savoir <_<
 
 
On monte un loopback qui va simuler un block device pour notre image :

 
... sinon mk2fs nous fera chier sa maman et a partir de ce moment là, on ne travaillera plus en mode image puisqu'on aura un block device virtuel (le driver loop s'occupe de tout, sinon grub peu pas bosser non plus /!\ne pas oublier de renseigner le -o cylindre par rapport a ta taille de partoche ! /!\)
 
 
On formate le block device monté avec une taille de block de 1k :

 
 
On installe une journalisation sur le block device, optionnel :

 
On monte notre block device dans un coin, on s'en fou de dire que c'est un loop a mount, puisque le block device virtuel a déjà été configuré AVANT :

 
On fait la copie du raw :

 
Jusque là tout se passe bien
 
                                                                                                                         
 

 
Sauf qu'il me dit :

 
What iz ze goud wey tou procid ?

 
Peut être une idée :
=> http://savannah.gnu.org/bugs/?27737

 
.... par contre, aucune idée de comment faire sous Debian  !!
 
++

ancienne version de grub donc (ou nouvelle j'en sais rien et j'ai pas envie de checker la version mais le workaround c'est d'utiliser la syntaxe proposée )
Donc la correction/workaround c'est :

on vérifie si y'a un /mnt/tmp/boot
Si non >

on créer notre /boot pour installer notre kernel et notre /boot/grub (chemin relatif dans notre image)
Si oui et après la commande du dessus si /boot n'existait pas :  

On dit a grub de s'installer (grub-install) mais pas dans le /boot de notre host mais dans le /boot de notre image (--root-directory=/mnt/tmp) avec comme param disques /dev/loop0 (notre interface virtuelle loopback) et ca devrait roulèze, on passera a la suite du tuto si tout est OK jusqu'ici (edit : avec donc la syntaxe proposée par ta version de grub)
 
Edit bis : ton nombre de cylindres est pas bon d'ailleurs quand tu configure ton loopback je viens de voir ça ... Sous fdisk fait un "p" et récupère le nombre de secteurs total, une fois ce nombre connu tu fait nbrsecteur*512 (taille de block standard) = ton paramètre -o (offset)

Hello,
 
Est ce que ce cas de figure est possible via virtualbox ou tout autre système :
 
OS installés physiquement sur disque dur (multiboot):
 
- Windows
- Distrib Linux
 
Booter sur windows et faire démarrer en mode VM l'OS installé physiquement sur le disque dur ?
 
A+
 

Windows va merder du au changement intempestif de matériel. Et l'inverse je ne sais pas ...

Un petit tuto Xen 4.2 et Debian Wheezy PCI Passtrough pour ceux que ça intéresse
 
http://wiki.xen.org/wiki/Comprehen [...] h_Tutorial

Il récupère où ses drivers GPLPV ? Et quelle version ?

Ici => http://www.meadowcourt.org/downloads/
 
http://www.youtube.com/watch?featu [...] oQ#t=1399s

GLPV késako ?  l'équivalent fonctionnel des drivers virtio de kvm ?

Ok, c'est là où j'allais... mais à l'époque ça faisait longtemps qu'ils avaient pas été MAJ..

C'est des drivers pour les systèmes MS qui permettent de fonctionner en mode para-virtuel (donc plus efficace qu'en passant par la couche qemu pour la partie I/O disques et réseaux).

XCP 1.6 BETA vient de sortir:
 
http://blog.xen.org/index.php/2012/10/01/xcp-1-6-beta/

 
 
Merci. C'est effectivement le même objectif que les drivers virtio windows

 
 
Les fonctionnalités sont alléchantes

Faudra que je jette un oeil à ce machin de StorageLink un des ces quatres quand même, c'est la principale fonctionnalité que je trouvais manquante à XCP jusqu'à présent (même si j'avais déjà lu des choses sur le sujet, on trouve peu de retours utilisateurs).

Actuellement j'utilise XCP 1.0 avec un serveur NFS (Linux Debian) comme SR (datastore) avec un pool de 7 dom0.
 
J'ai des problèmes de perf et régulièrement le montage NFS tombe, je suis obligé de rebooter tous les dom0.
 
 
J'envisage de remplacer le SR NFS par autre chose, j'hésite entre iSCSI et FC, tous mes serveurs physiques ont des cartes HBA inutilisées, 2 cartes réseaux Gb (1 dédié pour le NFS actuellement).
 
Quel type de SAN / NAS abordable (2/3 To suffiront) est à privilégier ?

Prends du iSCSI, ça marche très bien et c'est bien moins d'investissements qu'une infra en FO.
Surtout pour 2 ou 3To

D'ailleurs pour du iscsi c'est quoi les bonnes pratiques au niveau LUN/LVM/fichier vm:
1 LUN, 1 target avec un lvm sur l'hyperviseur et on balance un volume logique à chaque VM ou 1 LUN par vm ou autre combinaison ?

Y a différentes églises.
Je dirais que ça dépends des possibilités de ton target iSCSI.
Si il est capable d'augmenter la taille de tes LUNs à chaud, de les migrer sur différents volumes RAID, etc. en gros qu'il gère tout ce que fait LVM, ben ça sert à rien de se prendre le chou avec LVM => 1 ou N Lun par VM
Si il gère pas ça, ben LVM apporte un peu de souplesse => 1 LUN pour N VMs
 
Perso LVM je n'aime pas, je n'ai jamais aimé, et je pense que je n'aimerai jamais (mais ça n'engage que moi )

Le plus secure c'est effectivement une LUN par Vm, après si ta pas d'outils pour les gérer facilement (comme moi par exemple), c'est une LUN avec un LVM qui découpe le total pour chaque vm.

Je demande parce que dans mon nouveau taf on me demande de revoir l'archi de virtu. Actuellement y'a une LUN sur une baie qui est découpé avec LVM au niveau de l'hyperviseur. Le soucis c'est que un hdparm dans une vm donne 20Mo/s en débit
Alors j'ai regardé niveau conf: c'est du raw, avec le drivers virtio.
Par contre j'ai pas la main sur les switch entre la baie (PS4000, bas de gamme) et le serveur pour vérifier les optimisations iSCSI.

ps4000 ou PS 4000X ?
 
Quel type de raid ? quel firmware ? Combien de vm par lun ? Quels switch pour le iscsi, quelle config ? Meme avec du 4000 ce n'est pas normal cette perf.

Si vous deviez monter une archi iSCSI pour 10K€ environ, vous prendriez quoi ?

tu inclues les serveurs (hotes) dans le prix ? si oui, c'est impossible
 
10 k c'est vraiment pas assez pour une infra iscsi en prod. si c'est du test, iscsi software à la rigueur.

Ça va dépendre de ses besoins aussi On a pas tous 10k users
 
edit : d'ailleurs je vais tester GlusterFS, notamment avec des VM dessus (vu que la plupart font du read et pas du write, ça devrait le faire avec 4 noeuds (et surtout grandement me simplifier l'infra !!!)

Ca dépends surtout de la volumétrie dont t'as besoin.
 
En connaissant seulement la variable $$$$ on ne peut pas répondre

J'ose espérer que t'as d'autres VM/LUN en activité quand tu fais ta mesure