Reprise du message précédent :

Sur le site ubuntu tu as une tres bonne doc pour faire ca

Meme chose qu'au dessus, je me suis aidé de ca et ca fonctionne tres bien ! apres c'est qm pour passer le partage a ta VM

tu peux pas faire de SFTP par exemple, de VPN non plus me semble (de mémoire) ni de sécurité.
apres au niveau des mises a jour, je sais pas trop comment ca se passe... style si le paquet pour samba a une mise a jour dispo est ce que ca fonctionne bien quand tu mets a jour ou pas meme si j'imagine que oui

Salut à tous,
Y aurait-il dans l'assemblée quelqu'un qui pourrait tester une VM avec nanoboot  ? Je sais qu'ici il n'y a pas trop de fans de xpenology, mais c'est juste nanoboot qui me saoule    
J'ai testé sous proxmox pur, puis sous debian + proxmox et toujour le même constat :
- lorsque la virtualisation matérielle KVM est activée, La VM freeze au 2ème écran avec CPU à plus de 100%    
- lorsque la virtualisation matérielle KVM est désactivée, la VM se lance jusqu'au bout mis avec une extrème lenteur    
 
Bref, je suis dessus depuis longtemps et sans succès alors que sur d'autres forum certains disent avoir réussi    
Merci d'avance à ceux qui se pencheront sur mon problème    
 
Les liens pour le différentes versions de nanoboot (x64 de préférence pour mon N40L) :
versions originales par Sancome : http://www.colafile.com/u/sancome
versions d'un fofo batave : http://www.xpenology.nl/boot-images/#ISO
 
http://youtu.be/jtGqbz_RrDU ce que j'appelle le 2ème écran se trouve à partir de la 1ère minute

Useless, c'est exactement la même chose

Ok, je ne savais pas    c'est aussi pour dire que je n'ai pas glandé, j'ai essayé des trucs... mais là je sèche....  

Non mais c'est quoi cette histoire ?  
 
XaT

 
Félicitation!
 
Mais il y a un truc que je comprends pas, 12x Xeon et 62 Go de RAM?  

Le numéro de version, (en haut dans la gui web), c'est le même ?
Si oui, aucun soucis. Si non, ça peut fonctionner, mais je suppose que c'est pas trop supporté
Gaffe à avoir les deux serveurs synchro niveau heure (ntp, toussa), sinon il arrive des trucs pas fnu

J'aime pas turnkey
Le backup, tout dépend de ton setup/applis/toussa...
Perso, j'ai tendance à penser que le backup idéal, c'est :
- Tout le code de toutes les applis sur une forge git/svn/whatever
- backup de la vm forge
- backup des db sql
Et si une vm foire, tu en recrée une, tu git clone (30s) tu repose le dump de db et voilà. Ce sera toujours plus rapide que de restaurer un backup complet.
 
Mais ça, ça marche que dans le meilleur des mondes, où les applis sont bien codées/t'a des templates de vm qui vont bien/...
 
Sinon, gros tips pour le backup : depuis le nouveau format de backup c'est la mort, faut un proxmox pour extraire les fichier (dd virtuel et conf) des archives. Donc s'assurer de toujours avoir un proxmox sous la main dans une version pas trop loin de ta prod. Même sans vm, même sans gros cpu/ram, mais juste pour avoir les binaires. Dans un futur lointain, ça finira peut être intégré dans qemu, mais c'est pas demain la veille.

Simple :
T'exporte le répertoire /var/lib/vz/dump (ou un truc du style) en samba/nfs/sftp/whatever de ton local vers ton proxmox de prod, tu ajoute ton répertoire sur la gui du proxmox de prod comme répertoire de backup, et tu définis au niveau "datacenter" de ton proxmox de prod, dans l'onglet backup, un backup de tes vms, tout les X temps, à destination du répertoire en question (en mode snapshot/live).

Tu peux toujours demander du support pour installer proxmox sur une image debian ovh.

Ou passer sur XenServer

Sinon pour l'image OVH, normal si ils savent pas ce que c'est

XaT

J'étais partis du principe que tu monterais pas le cluster.
Mais sinon, oui.

Le fait que là, ça a pas l'air de marcher ?
Non, plus honnêtement, aucune idée, ça m'a pris comme ça    
Faut dire, j'ai encore un peu d'alcool dans le sang  

VPN ouai

J'ai tout compris

Mais, oui, je peut te le faire si tu veux
Au tarif consultant, toute heure commencée est due...

Pareil pour l'espace disque

 
ça fait un baille pourtant, et c'est aussi valable pour le CPU et la taille du "disque"
 
edit: grillé sur au moins 50%