Reprise du message précédent :
SR = storage repository, c'est un espace où dans ce cas tu déposes tes ISOs qui seront lues par n'importe quel VM et bootables (ça doit émuler un CD j'imagine)
 

 
Tu peux créer ton dépôt d'ISO directement dans l'hôte, il te suffit de choisir un dossier dans le file system de l'hôte. Relis mon post : new/storage/ISO/et choisi le path où tu vas caler tes ISOs. C'est tout

"SR CREATION - Unknown error from the peer"

settings/logs, regarde l'erreur là bas et colle le résultat ici.

tu passes /ISO comme chemin, mais existe-t-il dans ton dom0?

Il te faut un chemin qui existe dans ton filesystem

Tu veux dire que je dois créer un dossier à la main, qu'il ne peut pas le faire d'office en voyant que le dossier n'existe pas ?
 
Mais c'est de la merde !  

Créer un dépôt d'ISO sur l'hôte local c'est pas la façon conseillée de base déjà Vaut mieux utiliser un partage NFS, mais oui, XS/XCP-ng c'est pas pensé pour tout mettre sur un hôte mais s'insérer dans un réseau où t'as au moins un partage réseau quelque part.

Si t'es bloqué par un truc comme ça, c'est peut être pas la solution qu'il te faut.

edit : sinon tu peux le faire avec « xe » directement, cf premier résultat Google : https://xen-orchestra.com/blog/crea [...] xenserver/

boom

Aucune volonté de tacler dans ma réponse hein, c'est juste que je sais pas s'il a vraiment besoin d'un hyperviseur de ce type pour ces besoins, desfois un Virtualbox lui suffirait, j'en sais rien

Ou ... Un proxmox

 
Ici on parle de choses sérieuses monsieur

Dixit le type qui conseil virtualbox parceque XoA sais pas créer un dossier tout seul ²

Non mais si ça fait ma petite vengeance, je prends
 

 
Chut gros vilain
 

 
Sans doute pas, mais le premier post est trop vendeur
Puis là je test ça sur une bécane pour l'instant, donc pas en résal

 
Oui enfin « » ou pas, avant de tenter de taunt, faudrait savoir qui fait quoi XOA envoie juste une commande à la XAPI, qui elle ne va pas créer de dossier (la XAPI, enfin sur sa stack « legacy » va en gros envoyer des commandes à des drivers en Python, ici le file driver qui va faire du « mount » en gros. Essaie de passer à mount un chemin qui n'existe pas. Que se passe t il à ton avis ?). Bref, c'est donc un comportement de la toolstack, pas de XOA

Tu pourras donc inclure la fonctionnalité "créer un ISO SR" sur XCP-ng
 

Je peux créer une VM dans Xen et m'en servir comme répertoire réseau pour mes ISO, hein ?

Y'a un topic proxmox

 
C'est pas ultra logique d'utiliser une VM qui va servir d'infrastructure pour tes autres VMs. Pour du home usage, faire un mkdir pour créer ton dossier d'ISO va pas te tuer je pense. Si ta besoin d'y stocker beaucoup d'ISO, alors utilise un NAS.

sinon grave l'iso

Là par contre, je suis pas d'accord. C'est non seulement logique, mais c'est le genre de trucs que tu retrouve de plus en plus (openstack, vmware vsan, les nombreux produits de sds...).

De mon expérience, pour avoir design moi même un produit d'hyperconvergence (XOSAN) , je ne suis pas d'accord. Ça peut être pratique mais c'est moins robuste de compter sur des VMs pour le stockage. Rien qu'un exemple, au boot, l'hyperviseur va mettre un temps à booter la VM qui stock les Iso, mais il va tenter de monter le SR avant (car il a pas conscience que c'est dans une VM). Au mieux ta un timeout, au pire des Locks Nfs.

Bref, c'est un peu du bidouillage. D'ailleurs XOSANv2 sera dans l'hôte directement, plus proche d'un Vsan (qui IIRC ne fonctionne pas avec des VM).

Au final, si on veut des Iso sans storage réseau : dossier local dans l'hôte. Simple, robuste, efficace (mais faut faire un « mkdir », d'accord)

Openstack c'est quand même pas une référence à citer en terme de design

Si ton HV essais de monter le repos de stockage qui est géré par une VM avant qu'il soit dispo, c'est peut être qu'il te manque une brique logique quelque part. Si en plus ça casse tout, c'est qu'il manque clairement quelque chose. Genre un test de la dispo du fs avant de démarrer les VMs associées et des retry récurrent avec un délais exponentiel.
Et si effectivement vsan n'est pas une vm, des concurrents (Nutanix, Dell, HP), eux, le sont.

 
Oui les concurrents le sont car c'est un mal nécessaire pour eux (plus flexible). Mais tu y perds forcément quelque chose. En l’occurrence de la perf, de la gestion plus complexe (des timeout au boot ou un driver qui est « au courant » que ça se passe dans une VM, donc du dev).
 
Alors que quand tu as à la main dans l'hôte, tu vas forcément vers un truc intégré le plus bas niveau possible (le moins de couches). C'est pour ça que XOSANv2 (en terme de concept) a seulement été pensé post-fork XenServer, car maintenant on a plus de connaissances dans l'hôte, et on a moins peur de descendre des couches.
 
Donc oui, quand ton système n'est pas prévu pour (nécessite d'écrire des choses en plus) et que ça coûte des perfs, pour moi c'est pas mieux comme système. C'est futé comme solution (ce qu'on a fait nous aussi), ça permet d'avoir un produit multi-HV pour certains, mais c'est pas « mieux ».

Tout dépend de l'objectif. Là on est en train de débattre des fonctions d'infrastructures dans des VMs. Oui ça coûte des perfs. La virtualisation aussi, c'est pas pour autant qu'on fait tous du bare-metal.
Y'a pleins de gens qui choisissent des fonctionnalités/de la praticité/whatever au prix des performances. Alors oui y'a moyen de faire mieux. Mais c'est peut être pas l'objectif pour tout le monde.

 
j'aurais pas dit mieux

Moi je suis pour des modules standardisés niveau hyperviseur pour fournir du SDS

 
Non mais ici c'est carrément un anti-pattern. Surtout sur du NFS, qui est connu pour faire des locks quand c'est injoignable, qui va lui poser des problèmes au boot. Tout ça pour éviter un « mkdir » dans l'hôte, sérieusement, ya absolument 0 intérêt.

Alors que 3 posts au dessus tu déconseilles de créer le dépôt sur l'hôte local
 
Bon noraj, je vais faire un mkdir

 
 
Oui, il y a une notion subtile d'ordre dans lequel c'est du mieux au moins bien
 
Dans l'ordre :
 
Dépôt dans un partage réseau dédié >> dépôt dans l’hôte local >> dans une VM
 
Les 3 vont techniquement marcher, c'est juste une histoire de comment ça peut se comporter en cas de pépin ou si tu veux passer à l'échelle (pas juste 3 ISO dans un coin par exemple).
 
Maintenant tu fais bien ce que tu veux hein

Du coup, y'a quoi comme service d'infra qu'il faut sur du bare-métal selon toi ?
Le stockage, la partie contrôle d'un SDN, le DHCP/DNS (sinon t'a des locks possibles), les annuaires si tu veux relier ton interface de management de ton HV, ... ?

Tiens d'ailleurs, vous virtualisez vos DHCP/DNS ? Ou pire routeur ?

Sont sur un pi-hole perso (avec DNS tiers style FDN/CCC).
 
---
 
Bon j'ai fais mon directory, copié une iso dessus, et hop, installation depuis XoA en cours, c'est trop pratique  

Mon avis : si le service peut comporter de la HA, alors en VM c'est OK sur des hyperviseurs (idéalement pas au même endroit). Donc typiquement, du DNS, un annuaire etc. si t'as assez de copies et que si ton HV tombe, ça pète pas toute ton infra => OK

Après j'imagine que ta question vaut dans un environnement pro.

Concernant le stockage, c'est pas un mal d'avoir du matos dédié oui (ça te laisse une bonne latitude dans l'évolution de ton SR) mais c'est variable selon les besoins aussi (je connais des grosses boîtes qui font que du local SR pour des raisons de perfs, d'autres avec des gros Nexenta en NFS, c'est assez variable en fonction du besoin quoi).

Ya pas de solutions magiques, juste des bonnes pratiques et du dimensionnement en fonction des besoins. En général, l'idée c'est de pas péter la branche sur laquelle t'es assis, ce qui peut arriver vite si t'as pas des services critiques en HA au niveau applicatif. D'ailleurs la HA au niveau applicatif >>>> HA au niveau de l'HV, pour avoir bien vu de mes propres yeux des histoires d'horreurs avec des infras HA au niveau de l'HV qui ont explosé en vol à cause d'un grain de sable.

Mais bon, après j'ai plus d'expérience dans le monde XS/XCP-ng que d'autres HV, je suis pas un spécialiste de toutes les pratiques chez les autres, moi c'est du concret sur du support depuis 2015 environ chez des centaines de clients avec des infras de 1 à 5000 VMs en gros. J'ai même tendance à surprendre les gens parce que je suis pas fan des solutions ultra compliqués et j'ai tendance à préférer le KISS qui nécessite moins de maintenance à terme (genre un NFS tout simple pour le SR demande moins de maintenance qu'un iSCSI avec multipath…)

Au bureau, c'est le routeur qui s'en charge Avec plusieurs DNS différents (pas que celui d'Orange ). La prod c'est les DNS d'un provider pour nos domaines (Gandi), on s'occupe pas de ça nous

Ah bien Enjoy, et tiens bien les hyperviseurs à jour (avec XO ou yum update), normalement on est assez correct sur les patchs de sécu (même si c'est vrai que le risque est faible en dehors des gros cloud publics)

Cette nouvelle version d'XO  

J'ai même oublié de poster ici https://xen-orchestra.com/blog/xen-orchestra-5-29/

Une petite infographie sur XCP-ng :
 

SPlam !