Reprise du message précédent :
Malheureusement le feedback ici j'ai du mal à le gérer, il vaut mieux poster sur le forum XCP-ng, comme ça tu auras d'autres gens pour confirmer/infirmer

C'est chose faites je vous tiendrai au courant de leur réponse ça peut aider quelqu'un(s)  
 
Mais du coup ici on parle de quoi si c'est pas des retours d'expérience de XCP ?      

XO 5.38 : https://xen-orchestra.com/blog/xen-orchestra-5-38/

Hello
 
J'ai voulu mettre à jour les guest via https://github.com/xcp-ng/win-pv-drivers/releases (8.2.2.200);
 
Résultat, écran bleu au reboot... Reprit un ancien snapshot, j'ai du enlevé et remettre la VM sur le domaine....
Du coup, je ne sais pas comment je vais faire pour faire cette mise à jour des guest tools, car pourtant le windows update était à jour...
 
(Ils disent qu'il faut bien mettre à jour WindowsUpdate avant, il l'était bien pourtant.... ; https://xcp-ng.org/forum/topic/1690 [...] uest-tools Je n'ai pas eu le même message et le même écran bleu, mais j'ai tout de même eu ça (Sur windows server 2016))
 
Une idée pour ceux ayant réussi ?

Quel OS ?

edit : tu utilises pas les tools via Windows Update en meme temps que les drivers XCP-ng ?

J'ai essayé sur deux VMs distinctes sous Windows server 2016 (Anglais en langue).
L'hôte est encore en 7.6.
 
Je n'ai jamais coché l'option Windows Update sur XOA, donc les windows servers vont chercher sur Windows Update les mises à jour "normalement".
 
Edit: Hum, autant pour moi, une d'entre elle (Le DHCP... J'ai eu un coup de stress une fois le Snap remis car le domaine avait sauté... ^^) avait l'option cochée, et l'autre VM où j'ai aussi eu le crash avait l'option bien décochée.
Sachant que la VM du DHCP par exemple, a les drivers en 8.2.1 actuellement (les anciens drivers béta que j'avais prit quand il n'y avait pas les "rc" ) => Ce serait la cause ? Il faudrait que je les désinstalle manuellement avant ?

Peut être. Clean bien tout et réinstalle.

D'accord
 
Du coup, je désinstalle chaque driver non étiquettés "XCP-ng", je redémarre, je revérifie qu'ils ne sont pas remis, et je réinstalle les XCP-ng 8.2.2.200 et je vois si le redémarrage se passe bien ?

Oui. Tu peux booter en safe mode pour bien tout supprimer.

Ok, je vais voir ça à distance ou demain, et je vous tiendrais au jus.
 
Merci

Toute petite parenthèse, Veeam permet de faire la sauvegarde de 10 VMs gratuitement (si je ne me trompe pas actuellement) avec vSphere ou Hyper-V uniquement.
XCP-ng pourrait permettre cela sur son plan gratuit avec XOA ou ce n'est pas du tout envisagé pour le moment et cela restera sur la première des éditions payantes au minimum?
 
PS: Mon entreprise ne souhaite vraiment pas dépenser de l'argent, et de ce fait, ils ont accepté le PRA qui stipule qu'il y a uniquement des snapshots, et qu'aucune sauvegarde de VM n'est donc faite... Donc ils acceptent le faite que je me retape toute l'infra à la main durant au moins une semaine (sachant que les données critiques sont sur OneDrive donc, pour eux, "ça va"...)
=> Du coup, j'investigue dès que j'ai un peu de temps sur des solutions ""gratuites"".

Du coup, j'ai toujours un Windows Management tools en failed to install
 
=> Windows server 2016 standard (v1607)
=> Langue d'affichage en Anglais
=> Drivers "XenServer" enlevés (Network/Storage), au reboot, il y avait plus de leur trace donc j'ai tenté d'installer via le setup, puis retenter avec le "repair" pour tenter la réussite des tools mais toujours en failed, mais les drivers comme la capture d'écran du forum ne s'y trouvent pas J'ai donc remis le Snapshot avant même de redémarrer.
=> Hôte XCP-ng en 7.6
 
Repartir d'une VM toute neuve fonctionnerait très certainement, mais bon, ce n'est pas le but, surtout pour la VM de l'AD par exemple que je ferais en dernière quand j'aurais la procédure "OK".

C'est probablement qu'il reste des morceaux quelque part. Demande sur le forum, borzel c'est l'expert en drivers Windows.

Salut, besoin d'un petit conseil SVP, j'ai 4 serveurs sur xenserver 7.1, dont un pas trop chargé, donc j'ai migré les quelques VMs sur un serveur temporaire, pour mettre à jour le xenserver 7.1 en XCP 8.0. pour cette installation j'ai choisis la clean install car pas trop embêtant. Pour les autres bien plus lourd car beaucoup de VMs!
 
Ma question: De la version Xenserver 7.1, est il envisageable sans risque de passer a XCP ng 8.0 en faisant un upgrade via l'iso ? Ou une fresh install de XCP ng 8.0 est préférable, et donc devoir migrer toutes les vms sur un autre serveurs pour pouvoir faire l'installation de XCP?
 
Merci d'avance ! bonne journée!
 
Ps: a savoir qu'entre deux VMS sur xcp-ng 8 je viens de faire le test d'une migration a chaud via XOA 5.50 et ça ne fonctionne pas à la toute fin, la vm arrivé sur le serveur disparait et j'ai l'erreur : Xenops_interface.Xenopsd_error(internal_error)"connection reset by peer" write) migration a chaud impossible entre XCP ? je vais tenté a froid mais moins pratique Sur le center j'ai une erreur de CPU, peut être ça...ce ne sont pas exactement les même serveur effectivement

Pas de soucis pour faire l'upgrade. Même la migration à chaud doit marcher de 7.1 vers XCP-ng.
 
Tout ça c'est documenté ici : https://github.com/xcp-ng/xcp/wiki/ [...] -XenServer
 
Et ici en vidéo : https://www.youtube.com/watch?v=WNcuyRThfso
 
Si la migration à chaud n'a pas marché, c'est peut être un bug lié au template "Other Install Media" auquel il manque un paramètre. Normalement un « xe vm-param-set uuid=... platform:device_id=0001 » doit fixer le soucis.

Ok merci pour ta réponse, je vais refaire des tests, ya des chances qu'on en profite pour changer les SSD car ils commencent à dater donc je serais obligé de passer par une reinstall complète, a voir. En tout cas via le center il me dit direct problème de compatibilité, XOA me dit rien, le fait, mais chie à la toute fin et en plus il ma planté le VDI de cette vm
 Une copie de Xen7.1 vers xcp 8.0 a froid marche mais dans l'autre sens ça ne marche pas car pas versions non compatible! Bizarre  
 
J'ai été un peu surpris de voir que sur xcp-ng 8.0 à jour, on est justement pas le choix que de se mettre en "other install media" si on veut mettre du Debian 10 ou CentOS8 ! Les templates ne sont pas encore dans la liste et l'autostart des VMs au boot marche toujours pas dommage (ils m'ont viré mon post du forum XCP lol)

Oulà alors dans l'ordre

1. Ya aucun soucis de « compatibilité » c'est juste que Citrix se couvre le cul. Ici tu as peut être un bug avec le platform ID, mais c'est un bug, pas un cas normal
2. Euuuuh. Dans l'autre sens ? JAMAIS faut migrer du récent à l'ancien, pour plein de raisons. Autant la compatibilité vers l'avant est assuré, mais pas l'inverse, c'est même quasi impossible. C'est la même chose au niveau des CPU entre pool différents par exemple (ancien vers nouveau OK, pas l'inverse)
3. What ? Mais pourquoi tu utiliserai pas le template Debian 9 ? Un template ce sont juste des metadonnées, aucun risque d'utiliser le template Debian 9.
4. Forum : hein ? qui ta viré quoi ?

1 OK si c'est un bug je ferais d'autres testes pas très grave
 
2 Effectivement c'est assez logique mais j'en avais besoin et j'ai remarqué ça, pas très grave non-plus c'est juste une situation entre deux un peu chiante !
 
3 Ok pour le debian9 pour moi c'était assez important d'avoir le bon template (même si je ne sais pas exactement ce que ca engendre derrière)
 
4 je parle du forum XCP-Ng officiel, j'avais fais la demande pour l'autostart qui marche pas sur xcp 8, pas de réponses j'ai fais une petite relance, puis là depuis 1 semaine je retrouve pas le thread a priori il me l'ont viré, j'ai pourtant trouvé nulle part ce soucis sur le forum.. Et bien embêtant que les Vms s'autostart pas au boot (ou reboot/crash) du serveur.

1. C'est un bug qui peut être fixé avec ajoutant un paramètre dans la VM
2. Une migration faut la prévoir dans tous les cas pour pas se retrouver bloquer. Sinon tu peux tricher avec la CR de XO pour répliquer sur un XS/XCP plus vieux
3. Non, un template c'est un ensemble de métadonnée « optimisée » pour ta VM. Et aussi son mode (PV vs HVM). Depuis Debian 7, les template se ressemblent vraiment.
4. Je crois pas que qui que ce soit ait supprimé ton thread, il est même ici : https://xcp-ng.org/forum/topic/1872 [...] xcp-ng-8-0
C'est juste que ya 1k visiteurs uniques par jour sur le forum, donc ça défile vite

2: oui c'est juste que j'avais faus un template de VM qui peux servir pour les vieux srerveur (car long a tout migrer!!) du coup j'ai essayé de l'envoyé sur les anciens si besoin... Pas grave, effectivement le CR marche sur de l'ancien, on a ca en ce moment d'ailleurs DR/CR
 
4: ah oui GG je l'avais pas retrouvé même avec la recherche lol, bon pas de réponses toujours... tant pis J'espère au moins qu'ils l'ont vu et qu'ils regardent un jour....ou l'autre!

Question bête , sur le nouveau xoa, comment active t on les plugins ? Style pour l'envoi de mail par exemple backup-report et transport-email ? je les vois biens à l'endroit ou il fallait les mettre avant, mais dans la section plugin je n'ai rien...
Normalement il faut faire un lien symbolique de ce style:  
 
ln /opt/xen-orchestra/packages/xo-server-"module" /usr/local/lib/node_modules
 
mais je n'ai pas /usr/local/lib/node_modules . . .
 
EDIT: peut être ici maintenant sur debian9: /usr/lib/node_modules/npm/node_modules/

T'es sûr d'être sur XOA ? Car les plugins sont visibles par défaut (dépendant de ton édition de XOA bien sûr) Si installé depuis les sources, c'est en fonction de comment tu l'as installé.

Oui pardon je dis XOA mais c'est XO 5.50.1 et xo-web 5.50.2 en open source effectivement, installer sur une debian 9 comme expliquer dans le tuto. Si on va dans packages on voit bien quelques "plugins" mis de base je suppose:
 
~/xen-orchestra/packages/xo-server-transport-email
 
Et dans ~/xen-orchestra/node_modules il y a bien les liens symboliques (qu'il fallait faire avant à la main de mémoire)
 
rwxrwxrwx  1 root root   27 oct.   9 14:55 xo-acl-resolver -> ../packages/xo-acl-resolver
lrwxrwxrwx  1 root root   18 oct.   9 14:55 xo-cli -> ../packages/xo-cli
lrwxrwxrwx  1 root root   25 oct.   9 14:55 xo-collection -> ../packages/xo-collection
lrwxrwxrwx  1 root root   21 oct.   9 14:55 xo-common -> ../packages/xo-common
lrwxrwxrwx  1 root root   33 oct.   9 14:55 xo-import-servers-csv -> ../packages/xo-import-servers-csv
drwxr-xr-x  2 root root 4,0K oct.   9 14:55 xok/
lrwxrwxrwx  1 root root   18 oct.   9 14:55 xo-lib -> ../packages/xo-lib
lrwxrwxrwx  1 root root   28 oct.   9 14:55 xo-remote-parser -> ../packages/xo-remote-parser
lrwxrwxrwx  1 root root   21 oct.   9 14:55 xo-server -> ../packages/xo-server
lrwxrwxrwx  1 root root   33 oct.   9 14:55 xo-server-auth-github -> ../packages/xo-server-auth-github
lrwxrwxrwx  1 root root   33 oct.   9 14:55 xo-server-auth-google -> ../packages/xo-server-auth-google
lrwxrwxrwx  1 root root   31 oct.   9 14:55 xo-server-auth-ldap -> ../packages/xo-server-auth-ldap
lrwxrwxrwx  1 root root   31 oct.   9 14:55 xo-server-auth-saml -> ../packages/xo-server-auth-saml
lrwxrwxrwx  1 root root   36 oct.   9 14:55 xo-server-backup-reports -> ../packages/xo-server-backup-reports
lrwxrwxrwx  1 root root   27 oct.   9 14:55 xo-server-cloud -> ../packages/xo-server-cloud
lrwxrwxrwx  1 root root   35 oct.   9 14:55 xo-server-load-balancer -> ../packages/xo-server-load-balancer
lrwxrwxrwx  1 root root   32 oct.   9 14:55 xo-server-perf-alert -> ../packages/xo-server-perf-alert
lrwxrwxrwx  1 root root   36 oct.   9 14:55 xo-server-sdn-controller -> ../packages/xo-server-sdn-controller
lrwxrwxrwx  1 root root   26 oct.   9 14:55 xo-server-test -> ../packages/xo-server-test
lrwxrwxrwx  1 root root   33 oct.   9 14:55 xo-server-test-plugin -> ../packages/xo-server-test-plugin
lrwxrwxrwx  1 root root   37 oct.   9 14:55 xo-server-transport-email -> ../packages/xo-server-transport-email
lrwxrwxrwx  1 root root   38 oct.   9 14:55 xo-server-transport-nagios -> ../packages/xo-server-transport-nagios
lrwxrwxrwx  1 root root   37 oct.   9 14:55 xo-server-transport-slack -> ../packages/xo-server-transport-slack
lrwxrwxrwx  1 root root   36 oct.   9 14:55 xo-server-transport-xmpp -> ../packages/xo-server-transport-xmpp
lrwxrwxrwx  1 root root   34 oct.   9 14:55 xo-server-usage-report -> ../packages/xo-server-usage-report
lrwxrwxrwx  1 root root   26 oct.   9 14:55 xo-vmdk-to-vhd -> ../packages/xo-vmdk-to-vhd
 
Du coup comme c'est déjà fait, soit il y a une autre méthode, soit il faut juste les activer quelque part, mais pour le moment je n'ai pas trouvé où

Bonjour    
 
Concernant la gestion des vCPU, j'ai une machine avec 8 coeurs logiques (4C/8T).
 
Est-ce que du coup je suis limité 8 vCPU qui peuvent fonctionner ensemble ou je peux dépasser ce nombre? J'ai vu dans une autre discussion qu'on pourrait faire un rapport de 4:1 entre les vCPU et les coeurs logiques (soit 32 vCPU)
En gros, est-ce que je peux gérer plus finement l'allocation de vCPU qu'au 1/8è de la puissance CPU réelle?
 
Parce que j'ai des VM où 1vCPU c'est déjà trop (et pourtant le host est pas tout jeune).
 
Edit: et si c'est possible, faut-il respecter certaines règles? Par exemple, on peut allouer 1, 2, 4, 8, 16 ou 32 vCPU à une machine (soit 25, 50, 100% d'un coeur logique ou 2, 4, 8 coeur logique)

C'est pas grave ça, ton vcpu est pas dédié à ta VM (enfin tu peux mais dans cette situation ce serait dommage).
Tu ne peux pas disposer de plus de vcpus dans une VM que ce que t'as de dispos sur la machine physique, même si c'est des "quart de CPU" (en fait si tu peux, mais ne le fait pas, ça sera contre-performant).
Par contre tu peux donner plus ou moins de priorité sur les vCPU à chacune de tes VMs.

Mais d'expérience, ne t'embête pas trop à customiser ça, à moins d'avoir une visibilité très précise sur les besoins, y a de forte chance pour que tu te crées des situations de contre-performances plutôt que de laisser l'ordonnanceur de Xen gérer.
Le seul truc réellement pertinent c'est de dédier vraiment des coeurs à une machine donnée pour s'assurer qu'elle a ce dont elle a besoin.

 
OK merci.
 
Je pense avoir compris.
Toutes les VMs peuvent avoir 8 vCPU si je veux, l'ordonnanceur s'occupe du reste et si besoin, en dernier recours, je dédie des cœurs logiques à des VM en particulier.

Non c'est jamais une bonne idée de mettre autant de vcpu. La VM doit attendre que les 8 CPU soient dispo pour pouvoir bosser. Toujours rester en dessous

Plus de vCPUs que de threads : scheduling au niveau de Xen (ou de n'importe quel autre hyperviseur).

Note qu'aujourd'hui à cause de Metldown/Spectre, tu peux plus booter une seule VM avec plus de vCPUs que de threads. Mais plusieurs VMs qui dépassent le nombre total de thread oui.

Ça dépend de ta charge. Pour les VMs qui utilisent « moins » d'un seul vCPU, tu peux utiliser CPU Weight et CPU cap pour gérer leur priorités les unes par rapport aux autres. M'enfin ça nécessite de très bien connaitre sa charge actuelle.

Au plus simple : 1 vCPU si pas besoin de plus. Et faire « grandir » si besoin. Dans le monde des VMs « qui peut le plus peut le moins » va se payer très cher sur la perf finale.

 
C'était un exemple... extrême    
 

 
Merci    

Up si quelqu'un a une idée pour les plugins à activer sur XO from source svp Surtout email transport et rapport de bq  
 
Merci d'avance !

Je me reponds à moi même, en fait c'est a peu près pareil qu'avant, sauf qu'il faut faire un lien comme ça:
 
ln -s /opt/xen-orchestra/packages/xo-server-transport-email /usr/local/lib/node_modules/
ln -s /opt/xen-orchestra/packages/xo-server-backup-reports /usr/local/lib/node_modules/
 
Même si on a pas de dossier à cet endroit ça le crée
 
++

Je me réponds également à moi même sur l'autostart des VMs sur xcp-ng 8.X
De base désactivé en fait! (ils pourraient griser l'option du coup à mon avis!) et il faut l'activer sur le pool via CLI en faisant:
 
xe pool-param-set uuid=UUID other-config:auto_poweron=true
 
A priori c'était pareil sur Xenserver 6.X, ils ont fait ça à cause du HA qui se comportait mal avec l'autostart! Bizarre que XCP-Ng 8 est remis ça ! Voilà voilà!

Hello, question con, moyen d'installer les guest-tools sur centos8? En montant l'iso de xcp-ng (a jour) j'ai une erreur qui me fait comprendre que centos8 pour le moment pas trop compatible?
 
[root@localhost ~]# mount /dev/cdrom /mnt/
mount: /mnt : Attention: périphérique protégé en écriture, monté en lecture seule.
[root@localhost ~]# cd /mnt/Linux/
[root@localhost Linux]# ./install.sh  
Detected `CentOS Linux release 8.0.1905 (Core) ' (centos version 8).
 
Unable to install guest packages for distribution
CentOS Linux release 8.0.1905 (Core)  (centos).
 
Unknown RedHat Linux variant `centos 8'.
 
You should manually install a version of
xe-guest-utilities which is suitable for your
distribution.
[root@localhost Linux]#  
 
Pour le template on pourrait le recuperer en faisant ça:
 
yum update guest-templates* --enablerepo=xcp-ng-testing
 
Pour les guest tool est ce raisonnable/fiable de faire pareil dans le style ? ou attendre tout bêtement que ça arrive en stable?
 
yum update xen-tools --enablerepo=xcp-ng-testing
 
Si le package xen-tools c'est bien les guest-tools à monter en iso ?
 
EDIT: Je vais tester ça:  bash /mnt/Linux/install.sh -d rhel -m 7 ; de toute façon c'est du test donc.... ça a l'air de marcher il me vois operating system comme :  CentOS Linux 8.0.1905 (Core) et Virtualization state en optimized version 8.0 ...

Le sujet est déjà passé sur le forum. Il y a un même une maj en testing des tools.
 
Dans ton cas, il suffit de faire un "-m rhel" et ça passe (cf la doc : https://github.com/xcp-ng/xcp/wiki/ [...] ted-distro )

ouep je l'ai mis en edit j'ai trouvé un peu après. Cool qu'on puisse faire  ça quand l'OS est très proche d'un Os qui a déjà le tool
J'imagine que le testing marche aussi m'enfin je préfère attendre que ça arrive en stable, pour le moment juste pour tester CentOS8 donc pas très grave
 
MErci

Y'a le vGPU sur xcp-ng ? Obliger d'utiliser du nvidia pro ?
La feature est intéréssante pour les calculs GPU j'imagine () si l'overhead est pas trop important.

Je pense à ça parce que finalement on fout des 2080Ti dans les serveurs de calculs gpu

Des GPU grand public dans des serveurs Tu pourras faire ni passtrhough, ni vGPU.
 
Passtrhough : Quadro (sinon le driver nVidia refuse de s'activer)
vGPU : Grid donc Tesla etc.
 
Sinon AMD tout marche sans restriction (passthrough ET vGPU)

Les restrictions sont donc du côté d'nvidia et de leurs drivers ?

Pour du passthrough, oui. Le vGPU c'est une autre histoire, ya certain morceaux proprios nécessaires. Rien de tout ça chez AMD

edit : il existerai des solutions pour « trick » le driver Nvidia

Tricker je suis pas sur que ça soit viable sur le long terme, tu changes de drivers/sdk et tu peux avoir une merde.
Donc chez AMD avec ta soluce je pourrais avoir du vGPU ?

Chez AMD avec des Firepro ça tourne super bien (ya des feedback sur le forum), que ce soit en vGPU ou passthrough