Reprise du message précédent :
Pas de bras pas de chocolat, aucune chance que j'ai le temps de debug ton issue ici, ça sera dans les mains de l'équipe de dev

Pensez à patcher vos hôtes : https://xen-orchestra.com/blog/fore [...] nd-xcp-ng/

Commencent à être reloo chez Intel

Je te le fait pas dire

Hier j'ai fini de migrer (à chaud sur un nouvel hôte ) mes XenServer 7.2 vers XCP-ng 7.5, je pouvais pas laisser un trou pareil (surtout la faille XAPI).

J'ai plus de XS ailleurs que dans mon lab

Il y a un équivalent des vApp de vmware dans XO ? Afin de regrouper logiquement certaines VM et pouvoir les démarrer dans un certain ordre.

Dans XS/XCP-ng oui, mais c'est pas exposé dans XO parce que quasi-jamais demandé (le rapport Q/P est pas terrible pour exposer ça)

Dommage, je trouve ça pratique (idem le rangement des VMs en dossiers).

Bonjour,
 
J'ai mis à jour mes XCP 7.4 en 7.5 puis sur chaque serveur, un "yum upgrade" suivi d'un redémarrage.
 
Depuis cela, je rencontre un problème :
Quand je souhaite migrer une VM d'un serveur à un autre (Via XCP-ng Center 7.5 (ou via 7.6 release RC1)), parfois ça passe, parfois ça ne passe pas et la VM se "casse temporairement" et c'est assez fastidieux afin de pouvoir la relancer.
 
Auriez-vous une piste s'il vous plaît ?
 
Merci par avance de votre aide  

1. Tes XCP-ng 7.5 sont bien à jour ?
2. Tu te rends bien compte que « parfois ça passe parfois pas » c'est un tantinet vague si tu veux un coup de main Message d'erreurs, logs, taux de remplissage de tes SR, version/OS de ta VM qui échoue, etc.
3. Dans tous les cas je te suggère d'aller faire un saut sur https://xcp-ng.org/forum

1. Oui, et pour cela, si je ne me trompe pas, il suffit de faire un yum upgrade, puis une fois fait, de redémarrer ?
Ce "yum upgrade" est conseillé de faire à quel intervalle ?
 
2. Oui ^^
3. D'accord
 
Je vais tenter de réinstaller le serveur en question qui "plante", en espérant que ce soit que lui.

2 choses différentes :
 
* "yum update" pour passer de 7.4 à 7.5 est pas la façon la plus conseillée.
* "yum update" une fois que t'es en 7.5, car il y a probablement des paquets en update depuis l'ISO actuel.

Je fais les mises à jour à partir de l'iso monté sur CD, en sélectionnant l'upgrade et non la clean install.
Je n'ai jamais eu de soucis jusqu'à présent (XS>XCP 7.2, 7.3, 7.4.1 et maintenant 7.5).
Ensuite, je fais un "yum upgrade" pour les paquets depuis l'ISO.
 
Néanmoins, sur les 4 XCP, la migration de VM se passe bien sauf si l'on souhaite migrer une VM sur le 3ème XCP que j'ai réinstallé avec l'ISO (en sélectionnant l'upgrade et non la clean install, donc comme les 3 autres), je ne comprends pas.
Je précise que je viens de le refaire une deuxième fois en cas où l'upgrade s'était mal passé.
 
Ce que j'ai fait :
Ce 3ème XCP vient d'être refait, et remis à jour.
Il n'a aucune VM.
La VM (un W10 de test) étant sur le 1er XCP.
J'ai testé de la mettre sur le 3ème XCP.
Ca charge pendant très longtemps... (16 minutes actuellement)
(Auparavant, si je la migre sur le 2ème ou 4ème XCP, cela est normal et va très vite)
 
Ce que je remarque à l'instant :
La VM-test que je cherche à déplacer est sur le 1er XCP, où il reste 5Go de RAM de dispo.
Pour migrer une VM, le 1er XCP prend de la RAM, et là, durant le changement, la RAM est à saturation vu que la migration de cette VM n'est pas "rapide" comme cela l'est quand je migre ce W10 vers d'autres XCP que ce 3ème.
 
(Ce problème m'est arrivé et m'a été découvert ce matin en migrant tous les XCP en 7.5, et lorsque j'ai voulu changer le DHCP de serveur, du coup, plutôt embêtant, donc je test maintenant sur un W10 de test ^^)
 
 
Faudrait-il tenter d'enlever le serveur du pool, et d'y faire une clean install ?

C'est probablement lié aux tools dans ton Windows.
 
Aussi, vérifie que tu n'aies pas de ballooning dans cette VM (quand tu migres, Xen fait descendre la RAM au dynamic min, si c'est trop short ça pète ton OS).

Cela le fait sur n'importe quelle VM, même un petit linux avec 1Go de RAM (WAPT).
Et cela ne le faisait pas avant l'upgrade de 7.4.1 à 7.5. Mais uniquement vers ce serveur, c'est ça qui est étrange sachant que j'ai tout fait pareil sur les autres...
 
J'ai lancé la clean install pour repartir de 0 sur ce serveur... Je verrais si le problème persiste à nouveau après.

Okay tiens au jus.
 
Et regarde les logs aussi.

Après une réinstallation et un rattachement au pool, les VMs ont pu à nouveau se migrer à chaud sur ce serveur
 
Une coincidence, ou un upgrade qui s'était mal passé tout à l'heure ? Aucune idée...
 
PS: Sur XOA, je n'ai encore aucun plan (me faudrait trouver 15 jours pour vraiment bien profiter et tout expérimenter), mais cela me stipule que j'ai des patchs à faire, mais je ne peux les voir vu que je suis juste enregistré, d'où ma question, le "yum upgrade" ou "yum update" permet de faire toutes les mises à jour sur nos XCP 7.5, non ?

Le vue des MAJ dans XO est faite via un plugin XAPI qui fait `yum check-update` (pour afficher les paquets à mettre à jour) et `yum update`. Tu peux très bien tout faire à la main sur chaque hôte.

Ok.
Les mises à jour se font genre 1 fois par mois ? (Enfin, si on le fait manuellement je veux dire, prendre l'habitude de le faire une fois par mois ?)
 
Le faire ("yum update" ) alors que des VMs de prod sont fonctionnelles peut poser problème ou pas ? (Le redémarrage n'est pas automatique je crois)

1. Pas de régularité, ça dépend des fix de sécu et des patch Citrix la plupart du temps (et de nous quand on fait des fix nous meme). Dans XO, dès que tu vois une MAJ, tu peux regarder de quoi il s'agit.
 
2. Aucun risque de faire des update pendant que ça tourne, la plupart du temps tout est en RAM et seul un reboot prend en compte les modifs.
 
3. C'est à toi en tant qu'admin de t'orga pour reboot. TOUJOURS commencer par le master.

D'accord
 
Je viens de voir une chose, en 7.4.1, les guest-tools étaient là.
En 7.5, à ce que j'ai compris, vous n'avez plus les droits nécessaires.
 
"Des travaux sont en cours pour les construire à partir des sources pour les ajouter dans cette image ISO."
Le jour où ceci sera fait, il faudra simplement faire un "yum update" ou ce sera pour la 7.6 ?
 
En attendant, comment faites-vous si Windows Update ne trouve rien ?
(Une VM est en 100M au lieu de 1Gbps à cause de ça )
 
Merci !

Si Windows update ne trouve rien, c'est peut être dépendant de la langue de l'OS (ça marche avec les Windows US, mais WIndows étant tellement un OS merdique…)

Sinon tu cheat et tu récupères les binaires des drivers depuis un XS, en attendant qu'on signe les nôtres chez MS. Quand ça sera fait un simple yum update et ça sera OK.

Nouvelles ISO toutes fraîches avec au menu : Software RAID 1 à l'install, et ISO de net install de 100MiB.
 
https://xcp-ng.org/2018/09/21/xcp-n [...] l-features

Elle m'a l'air bien sympa cette nouvelle version d'XO

Woops, oublié de MAJ ici https://xen-orchestra.com/blog/xen-orchestra-5-27/
 
Pas mal de trucs mieux un peu partout, le travail de fond est bien avancé aussi pour la fin d'année (meilleures perfs, proxies etc.)

La bannière sur DistroWatch
 

Si j'arrive à me motiver, je vais tenter de monter en compétences sur kubernetes.
Et, je viens de voir que tout tourne sur CoreOS et que XO est compatible docker-CoreOS. Ça promet

Bonjour,
 
Ayant des performances moins bonne en NFS, je suis passé en ISCSI pour le partage.
Des choses spécial à savoir là dessus avec xcp-ng 7.5, ou la façon de partager notre stockage n'impacte pas les hyperviseurs (outre les performances) ?
 
PS: XOA avec les Backups des VMs fonctionne tout aussi bien en ISCSI qu'en NFS ?
PPS: Désolé si ma question peut paraître bête.

Moins bonnes de combien ? Ça devrait pas être énorme comme écart (enfin ça dépend du serveur NFS). En iSCSI t'es thick pro, donc le premier snapshot double la taille des disques de la VM snapshoté.
 
À part ça, ça change rien côté backup. C'est pas une question bête.

Au revoir Wordpress (j'ai bien essayé pourtant ), bonjour nouveau site en statique : https://xcp-ng.org
 
Et Ghost pour les news : https://xcp-ng.org/blog

 
 
- Sur le Pool où nous avons FreeNAS 11.1-U6, XCP-ng est encore en 7.4 (pour garder les tools Xen qui ne sont pas encore en 7.5) -
(Les chiffres sont une moyenne via le soft ATTO Disk Benchmark v4)
 
En NFS :
Sans Update Windows ni les tools de Xen : ~80MB/s
Avec update et les tools de Xen : ~7MB/s
 
En ISCSI :
Sans Update Windows ni les tools de Xen : ~115MB/s
Sans Update Windows mais Avec les tools de Xen : ~50MB/s (étrange...)
Avec update et les tools de Xen : ~110MB/s
 
(Nos hypersiseurs n'ont qu'un disque système, le stockage des VMs se fait par le FreeNAS du coup)
-
 
Je ne comprends pas le sens d'être "Thick Pro" ?
Pour les snapshots, je n'ai pas encore fait attention.

 
Fixed!
 

 
T'es sûr que ton Windows update a bien tourné parce que là ça ressemble à un problème de driver, sans tools arriver à faire 80MiB/s ça me parait pas normal, ça devrait être l'inverse
 
Thick provisioning: quand tu crées un disque de VM de 100GiB, ça va réserver 100GiB (même si c'est vide dedans). Quand tu vas faire un snapshot, tu vas prendre de nouveau 100GiB (donc 200GiB au total).

Oui, j'ai juste installé l'OS, puis lancé directement le soft et ensuite, j'ai fait les mises à jour + les tools avant de relancer un autre test, et oui, c'est très étrange... Car de plus, sans tools, la carte réseau sur l'OS de W10 est en 100M, et avec les tools, en 1G.
Mais du coup en iSCSI, c'est ok après avoir tout mis à jour.
 
A "l'époque", on s'était mis en NFS car la HA ne fonctionnait pas en iSCSI (D'après l'ancien AdminSys). Mais maintenant que ça a l'air d'être bon, autant privilégier l'iSCSI je pense...
 
PS: Une fois que le stockage sera vraiment "Opérationnel" pour de la prod, on pourra investiguer sur les plans de XOA pour le backup des VM ^^

Le « seul » problème du iSCSI c'est l'espace utilisé.
 
En tout cas c'est chelou le problème de perfs en NFS.

Oui, ça ne provisionne pas au contraire du NFS, je viens de comprendre, par exemple une VM de 200Go, ça prend vraiment 200Go sur l'espace de stockage même si la VM en occupe pour le moment 50. Et du coup, un Snapshot prend aussi de la place. Faudra que je vois combien de place prennent les snapshots en plus via l'interface de xcp-ng center, je crois que ça snap uniquement les changements par rapport au premier snap, ou je me trompe ?
 
Oui, car sur l'autre Pool que l'on a (Uniquement NFS), nous avons aussi un FreeNAS (mais en 9.2) paramétré de la même manière que l'autre FreeNAS et câblé exactement pareil (1G) et là, nous n'avons pas de problème de perf...
=> Seul différence, le serveur de stockage physique (Dell 2950) de ce pool qui fonctionne "normalement" est en 3x1To SAS 7200trs/min en RAID5 pour 2To et le serveur de stockage (R330) du pool qui a du mal en NFS est en 3x6To SATA 7200trs/min pour 11To.

Le **premier** snapshot ça va te doubler l'espace total de la VM. Exemple ta VM de 200GiB, ça va rajouter 200GiB. Donc 400GiB au total.
 
En gros si tu veux tout snapshot, il te faut utiliser <50% de ton SR.
 
Les snapshots d'après (après le premier) prennent « que » la taille réelle des blocs de diff.
 
Sinon côté NFS, check tes réglages de mount (côté serveur et client), c'est bien une histoire propre à ton NFS pas à XCP visible

D'accord, merci

Pour le moment XCP-ng 7.4 permet la migration à chaud et la HA via le stockage en iSCSI, c'est toujours le cas dans la 7.5 je suppose ?
 
Et dans le futur, cela sera toujours le cas ?
 
Ou cela dépendra pas de vous, mais plutôt du stockage iSCSI en LVM (migration possible*) ou GFS2 (migration non possible*) ? *si je ne me trompe pas.
 
Edit: Faites-vous un tableau comparatif de version ?