Reprise du message précédent :
Salut le tu

J'ai installé mon serveur Xen ce week-end sans trop de soucis, Xen orchestra compris. Tout fonctionne au poil mis à part deux petites choses :

-Que ça soit avec XenCenter ou Orchestra, impossible d'avoir accès aux consoles des VMS si je me connecte à partir d'un autre réseau que mon réseau local. Normal ?

- Le raid de mon serveur (un Dell t20) n'est pas reconnu par Xen. Du coup, je vais devoir m'acheter une carte raid pour pallier à ça, j'ai vu qu'il y avait une liste sur le site de Xen mais je ne suis pas contre quelques conseils si vous avez déjà eu le même soucis dans le choix de la carte  

Tu as installé la dernière version de XenServer ? (6.5)

Pas eu de soucis sur mes serveurs (Dell R210 et R220)

edit : pour les consoles, oui, malheureusement il faut attendre qu'on ait développé un proxy pour la console (car la XAPI ne sert pas d'intermédiaire pour les consoles, mais renvoie l'IP interne de l'hôte concerné = gros fail sur un réseau en NAT)

Ok pour les consoles, vivement alors    
 
Pour le Dell, ça ne marchait déjà pas avec ESXI, je pense que le chipset (Intel C226) n'est pas pris en charge...

Je dirai que le FW doit bloquer (mais à confirmer via un iptables -L ou l'equivalent sur le nouveau)

C'est quoi ta CM ? Ton product code ?
 
XaT

Le product code : 6Q22002
 
Pour la CM, pas eu d'autres info que le chipset : Intel C226.

Pour info, je vais me prendre la PERC H700 pour gérer le raid, cette carte est marquée comme compatible sur le site de Xen. Pour ceux qui auraient le même soucis, cette carte et les Dell un peu plus anciennes ( PERCI 6i) sont de bonnes opportunités pour un prix pas exorbitant.

Genre ça : http://www.ebay.fr/itm/Dell-Perc-H [...] 2a4adbc335 ?

edit : Sur le site de Dell, le T20 semble supporter officiellement que 2008R2+

XaT

665mo la XOA ? uh ?  
 
XaT

Eh ouais, on est retourné sur le Git directement* et plus les packages, donc c'est forcément plus gros
 
* : on a encore quelques soucis dans l'upgrade des packages npm, ça fait parti des axes de développement d'ici la Starter 1.0

Pourquoi tu t'es register deux fois avec la même adresse ? (je parle pas du premier essai avec une fausse adresse )

 
J'ai une connect' de merde, du coup je clique souvent 2 fois  
 
XaT

 
T'es pas le seul, c'est pour ça que je demande

J'ai d'abord tapé sur Enter, j'ai cru que rien ne se passait du coup j'ai cliqué sur le bouton rouge
chrome39 sur win7x64
 
XaT

Merci, c'est noté

Il supporte 2012 (livré avec sur la plupart des versions du t20), mais je ne vois pas trop le rapport, vu que je passe par Xen ?  

Bah tu passes sur du RHEL/CentOS, ce genre de support est marqué sur ce genre de site, du coup t'as les drivers et tout.  
La c'est aléatoire, à toi de trouver le driver qui faut pour ton système
 
XaT

C'est quoi les bonnes pratiques question sécurité sur le dom0 ?

edit: Tiens j'ai un force reboot qui a pas marché sous XO

XaT

Je dirais idem que sur un serveur lambda.

Dans l'absolu : le moins d'exposition possible : idéalement, si tout ne peut être accessible qu'en console (physique ou virtuelle) c'est le mieux.
 
Je suppose que ta question était probablement plus précise

Gros fail sur un réseau en NAT ? cad (qui est où ? positions des xenservers, du serveur server XOA, et du client/browser web vis à vis du NAT) ?

Bah la XAPI renverra 192.168.1.10 au lieu de l'IP WAN.
 
XaT

Nan mais je sais ce que c'est que le NAT
 
Ce que je demandais, c'était la position des différents éléments (Xenservers, XOA, browser web) p/r au dispositif qui fait le NAT

Ça peut fail à deux niveaux : il faut voir « xo-server » comme un relais entre l'UI et les hôtes.

Par exemple, pour l'export de VM via la XAPI, « xo-server » télécharge le contenu de la VM sur un hôte, puis le passe (via un flux, à se représenter comme le cours d'une rivière) à « xo-web » (ou « xo-cli »). Gestion de la back-pressure et tout, c'est parfait, même si le client est en dehors du réseau, pas de problème, tant qu'il a un lien avec « xo-server ».

Mais effectivement, le cas de la console est moins fun.

•  Client en dehors du NAT : échec, puisqu'il va tenter de se connecter directement sur l'IP interne de l'hôte.
• « xo-server » en dehors du NAT : pas une bonne idée, en cas de changement de pool master (admettons qu'on ait NATé que le master), il perd la connexion.

Solution : faire comme pour l'export de VM, intercepter le flux dans « xo-server » et le rediriger vers un client. Dans ce cas, tant que « xo-server » est dans le réseau NATé, ça roule.

Question un peu à part, vous utilisez quoi comme solutions pour sauvegarder vos Vms ?

Ca va, réveil difficile
 
XaT

• je fais des snapshots régulier pour pouvoir rollback si besoin (c'est pas vraiment du backup)
• j'exporte mes VM en complet de temps en temps

Il est prévu d'avoir un planificateur de backup directement dans « xo-web » d'ici fin février

Les snapshots, c'est de l'incrémental ? ou c'est un "bon gros dump des familles" ?
(je pense que c'est la première réponse vu ce que tu expliques avec l'export complet des VMs après les snapshots )
 
Oui, je sais, c'est trivial mais je rattrape bcp d'années d'un coup sur la virtualisation et les outils qui existent maintenant

J'ai un cas tout bête en ce moment, où j'ai un serveur (un Dom0) avec une IP publique, une série de VMs en IP privée
Je fais du masquerading pour que les VMs puissent avoir accès au net et du NAT plus statique pour accéder au services proposés par les VMs (Web et SSH, dont notamment ceux proposés par XOA), et j'arrive à accéder à toutes les consoles virtuelles que ce soit via Openxenmanager ou via XOA
 
C'est normal ? ou je suis pas dans le cas de figure que tu décris ?  
(toutes les VMS/DomU, y compris celle qui fait tourner XOA sont sur le même réseau virtuel privé IP, le Dom0 a une patte sur ce même réseau virtuel privé, et mon client web est ailleurs sur le net)

Snapshot incrémental (derrière c'est un « bête » LVM). Ceci dit, tu peux exporter les snapshots dans XO en fichier dump complet ! (ce qui est très pratique !)

La XAPI renvoie pas l'URL dans la VM mais du Dom0 ! Donc si la XAPI te retourne l'IP publique de ton Dom0, aucun soucis pour accéder à toutes les consoles  

Là où c'est casse gueule c'est quand tu as plusieurs dom0 dans un même pool, et que tes dom0 on des IP uniquement internes. De l'extérieur t'es fucké !  

ok, je vois le souci
Le plus important, c'est l'IP "visible" du/des Dom0 parce que le/les protocoles utilisés dans XAPI ne sont pas natables  

 
Voilà Après à nous de régler le « problème » avec XO en utilisant « xo-server » comme relais. Bon là ya le lead dev qui est en train de s'occuper de faire une première implémentation des permissions/ACL et le nouveau qui bosse sur le portail client pour un véritable process d'achat qui va bien. Mais on devrait y arriver le mois prochain

Au fait, un truc bête mais bon, pensez à mettre une deuxième saisie pour confirmation lors du changement des mdp dans l'écran d'admin des users
Je sais que c'est pas forcément le truc le plus urgent, mais qqun qui fait une faute de frappe lors de la saisie du nouveau mdp, se retrouvera
comme un con devant l'écran de login, la fois suivante

 
C'est déjà rapporté
 
https://github.com/vatesfr/xo/issues/31

Pour les impatients de la console à travers un NAT, bonne nouvelle : ça devrait arriver ce soir ou demain

Super

https://xen-orchestra.com/blog/xo-c [...] verywhere/
 
\o/

 
Tu entends quoi par FW ? J'ai toujours ce soucis de console innateignable depuis l'extérieur avec XenCenter    
 
Pour Plam, petit beug sur XOA dans la partie console, quand je tappe 123456789 avec mon pavé numérique, j'obtiens &??"'(-??_?? Moi qui ne comprenais pas pourquoi je n'arrivais pas a rentrer mon mot de passe  

"xencenter firewall" dans google devrait te donner pas mal de pistes à explorer

 
Console RFB ou VT100 ? (en gros : VM PV ou PVHVM ?)

Vu que c'est une VM associée a un template de base, c'est du PV je pense