Ce vendredi 30 Septembre, deuxième réunion du NCUG auquel je participe après les locaux de Microsoft, c’est chez Citrix que le meeting a eu lieu avec la présence encore une fois encore de très bons intervenants :

Simon Mijolovic expert sécurité chez Nutanix, je n’aurai jamais imaginé un tel niveau d’engagement de l’éditeur pour la sécurisation de ses produits.

Puis Kees Baggerman qui m’a définitivement donné envie de tester Xendesktop sur AHV !

L’hôte de la journée représenté par Fabrice Colas, a fait une présentation de quelques-unes des nouvelles fonctionnalités 7.11 et l’intégration des produits Norskale avec le Workplace Environement Management.

Une rencontre vraiment enrichissante, et un vrai plaisir de rencontrer ces experts très accessibles, vivement la prochaine !

En parallèle des NCUG, le French Citrix User Group Community  (FCUGC) propose de réserver le 9 novembre dans notre calendrier, ce que je ferai sauf si Vienne m’ouvre les bras du 8 au 10 Octobre pour les .NEXT Conference  Nutanix.

image-1

Effectivement pas d’article technique ce soir, mais la mise en place d’un nouveau template et du logo icone, n’hésitez pas à me dire ce que vous en pensez dans les commentaires à la fin du post.

On m’a souvent reprocher mon précédent thème trop sombre et les options peu accessible, j’espère que le côté coloré et fonctionnel vous plairons plus !

Avec la précédente version de Prism Central 4.6, la question de l’update ne s’était pas posée puisqu’elle n’était pas possible, il fallait absolument procéder à une nouvelle installation de l’appliance.

Pour la 4.7, l’update est bien réalisable mais n’ayant pas accès à internet depuis cette machine, j’ai cherché à uploader directement les 2 fichiers de mise à niveau à savoir les binaires et le fichier de metadata.

Aucune trace de ces fichiers dans la section réservée à Prism Central sur le site de Nutanix, simplement les sources d’installations complète en fonction de vos hyperviseurs.

prism_centra_471

Finalement, il suffit faire la mise à jours de Prism Central avec les fichiers de la version de l’AOS (NOS), en prenant le fichier tar et le fichier de metadata.

aos471

 

prismupdate

uploading

Et voilà, bonne upgrade !

upgrade

 

Nous avions déjà un export automatique vers notre CMDB en place mais suite à une demande de modification, je me suis dis qu’il était temps de remplacer notre bon vieux get-vm.

Je pensais arriver à un meilleur résultat, mais les requêtes pour le Datacenter et le Cluster ralentissent vraiment l’exécution, malgré ça, l’ancien script prenait 2h55, le nouveau 39min soit presque 4.5 fois plus rapide pour le même scope soit 5 vCenters et un peu plus de 2200VMs.

@"

===============================================================================
Description:   Exports VM Informations to CMDB
Usage:         Schedule task on vCenter
===============================================================================

"@
$StartMs = (Get-Date)
0..1000 | ForEach-Object {$i++}

#Standard PowerCli cmdlets
add-pssnapin VMware.VimAutomation.Core

#Renseigner votre/vos vCenter(s) separé par des virgules
Write-Host "Renseigner votre/vos vCenter(s) separé(s) par des virgules"
$vCenters= Read-Host "VCENTER_NAME"
$Path = Read-Host "Path"

#Date
$Date = Get-Date -Format yyyy-MM-dd

Write-Host "Renseigner le chemin d'export du fichier resultat ainsi que le nom du fichier"
$ExportFilePath = Read-host "$Path\$date\Export-CMDB.csv"

$listVM=@("VMName,VMHostname,Datacenter,Powerstate,OS,IPAddress,MacAddress,NetworkName,ToolsStatus,Cluster,NumCPU,MemMb,Datastore,DiskGB,DiskFree")

 Foreach ($vCenter in $vCenters) {
 Connect-VIServer $vCenter

 $VMs = Get-View -ViewType VirtualMachine
 

 
ForEach ($vm in $VMs) {
      $VMName = $vm.Name
      $VMHostname = $vm.Guest.Hostname
      $parentObj = Get-View $vm.Parent
      #while ($parentObj -isnot [VMware.Vim.Datacenter]) {$parentObj = Get-View $parentObj.Parent | select -Unique}
      while ($parentObj -isnot [VMware.Vim.Datacenter]) {$parentObj = Get-View $parentObj.Parent}
      #Boucle et remonte d'un niveau dans l'arborescence jusqu'à trouver le datacenter
      $Datacenter =   $parentObj.Name
      $Powerstate = $vm.Summary.Runtime.PowerState
      $OS = $vm.config.GuestFullName
      $IPAddress = $vm.Guest.Net.IPAddress
      $MacAddress = $vm.Guest.net.MacAddress
      $NetworkName = $vm.Guest.net.Network
      $ToolsStatus = $vm.Guest.ToolsStatus
      ## use UpdateViewData() to populate the linked view, then access said linked view
      $vm.UpdateViewData("Runtime.Host.Parent.Name")
      $Cluster = $vm.Runtime.LinkedView.Host.LinkedView.Parent.Name
      $NumCPU = $vm.Summary.Config.NumCpu
      $MemMb = $vm.Summary.Config.MemorySizeMB
      $Datastore = $vm.Summary.Config.VmPathName.Split()[0].split('[]')
      #le premier split prend la premiere expression, le deuxieme retire les crochets
      $DiskGB = [Math]::Round((($vm.Guest.Disk | Measure-Object -Property Capacity -Sum).Sum / 1GB),2)
      $DiskFree = [Math]::Round((($vm.Guest.Disk | Measure-Object -Property FreeSpace -Sum).Sum / 1GB),2)
      $listVM+=("$VMName,$VMHostname,$Datacenter,$Powerstate,$OS,$IPAddress,$MacAddress,$NetworkName,$ToolsStatus,$Cluster,$NumCPU,$MemMb,$Datastore,$DiskGB,$DiskFree")
      Write-Host "Traitement de la machine $VMName" -ForegroundColor Yellow
      }
Disconnect-VIServer $Vcenter -Force -Confirm:$false
}

$listVM > $ExportFilePath
Write-Host "Creation du Fichier résultat" -ForegroundColor Red


Write-Host "Déconnection des vCenters" -ForegroundColor Gray
#$VC = Disconnect-VIServer * -Confirm:$False

$EndMs = (Get-Date)
Write-Host "Le script s'est executé en  $($EndMs - $StartMs)"

 

Je ne l’avais pas anticipé, mais lors de la suppresion d’une VM VDI Côté Xendesktop, le nettoyage du Protection Domain côté Nutanix n’est pas automatique si bien qu’hier j’ai eu un petit warning « Unable to locate VM with name ‘VM_Name and internal ID ‘60069aa8-29d5-2c52-6827-945372df5a5a’ in protection domain ‘ProtectionDomain_Name’.

Capture

Voici le script que j’utilise pour faire le nettoyage :

#Chargement des Addins
Add-PSSnapin Citrix*
Add-PSSnapin Nutanix*

#Renseigner votre broker Xendesktop
$XenBroker = Read-Host "Broker_name"

#Renseigner vos IP CVM Nutanix
$NutanixCluster1 = Read-Host "IP_VCM_Cluster1"
$NutanixCluster2 = Read-Host "IP_VCM_Cluster2"

#Connexion aux clusters Nutanix
Connect-NTNXCluster -Server:$NutanixCluster1 -UserName:admin -AcceptInvalidSSLCerts
Connect-NTNXCluster -Server:$NutanixCluster2 -UserName:admin -AcceptInvalidSSLCerts

#Recupération des VDI Xen
$VDIs=Get-ProvVM -AdminAddress $XenBroker

#Création de la liste des VDI Xen
$XEN_VMs = $VDIs.VMName

#Récuperation de la liste de Protection Domain Nutanix
$NUT_VMs = Get-NTNXPRotectionDomain

#Création de la liste des VM Nutanix
$NUT_VMS = $NUT_VMS.vms.vmName

#Comparaison des deux precedentes listes, conservation des machines présentent côté nutanix, absentent côté Vdi Xendesktop
$VMs2Delete = Compare-Object -ReferenceObject $NUT_VMs -DifferenceObject $XEN_VMs | Where { $_.SideIndicator -eq "<=" }

#Pour chaque VM de cette liste à supprimer, recuperation du Protection Domaine associé et suppresion de la VM de celui-ci
foreach ($VM in $VMs2Delete) {
$ProtectionDomain = Get-NTNXProtectionDomain | Where {$_.vms.vmname -like $VM.InputObject}
Remove-NTNXProtectionDomainVM -name $ProtectionDomain.name -input $VM.InputObject
}

#Déco et fin du script
Disconnect-NTNXCluster *

Il y aura un peu de rouge à l’exécution étant donné que le script essayera de supprimer la VM sur les 2 Sites donc pas d’inquiétude.

A la suite de mon précédent article « Nutanix Async DR  with Citrix Xendesktop MCS VDI« , le point a été remonté chez Nutanix et la prochaine mise à jour de la documentation devrait éclaircir les choses sur ce point.

J’avais des réplications fonctionnelles mais une autre limitation du design été en train de me poser problèmes.

En version 4.5 d’après la doc Nutanix « System Maximums », nous ne pouvons avoir plus de 50 VMs par Protection Domain, consistency group, ou SRA.

Nous avons donc décidé d’automatiser la création des « Protection Domains » de sortent que tous les soirs chaque nouvelle VM soit protégée et répliquée.

Je ne vais pas poster ici le script car il est vraiment spécifique à notre environnement mais je vais lister les commandes Nutanix utilisées.

J’ai vraiment eu beaucoup de mal à trouver des exemples et de la documentation pour certaines :

# Création d'un ProtectionDomain
Add-NTNXProtectionDomain -PDName "My_PD"
#Ajout d'une VM à ce Protection Domain
Add-NTNXProtectionDomainVM -PDName "My_PD" -names "My_VM"

Évidemment Attention si vous êtes dans un scenario VDI Xendesktop MCS comme moi, cette commande ne fonctionne que pour synchroniser une machine, les suivantes ne seraient pas dans le bon « Consistency Group »

#Ajout d'une VM à ce Protection Domain avec le meme nom de "Consistency group" 
Add-NTNXProtectionDomainVM -PDName "My_PD" -names "My_VM" -ConsistencyGroupName "My_PD"
#Création d'une tache planifiée associée au précédent Protection Domain
# qui tournera tous les jours à 00:01
Add-NTNXProtectionDomainCronSchedule -Name "My_PD" -Type "DAILY" -EveryNth "1" -UserStartTimeInUsecs "1463522460000000"
#Configuration de la "retention policy"
Set-NTNXProtectionDomainRetentionPolicy -pdname "My_PD" -Id ($(Get-NTNXProtectionDomainCronSchedule -Name "My_PD").Id) -LocalmaxSnapshots 2 -RemoteMaxSnapshots "My_Remote_Site=1"

Je configure donc un snapshot local et un snapshot sur le site de réplication.
Pour la configuration du « RemoteMaxSnapshots » il faut impérativement indiquer le RemoteSite (vous pourriez en avoir plusieurs) coller avec « = » et le nombre de snapshots. 1f616

 

Pour faire le grand nettoyage dans vos configurations de réplication:

#Supprimer tous les snapshots
$snaps=Get-NTNXProtectionDomainSnapshot
foreach ($snap in $snaps){
Remove-NTNXProtectionDomainSnapshot -ProtectionDomainName $Snap.ProtectionDomainName -SnapshotId $Snap.SnapshotId }
#Supprimer toutes les taches planifiées
$PDs = Get-NTNXProtectionDomain
foreach ($PD in $PDs) {
Clear-NTNXCronSchedule -PDname:$PD.name
}
#Sortir toutes les VMs de tous les ProtectionDomains
$VMs = Get-NTNXVM
foreach ($VM in $VMs){
Remove-NTNXProtectionDomainVM -name $VM.protectionDomainName -input $VM.vmName
}

 

Une fois vide les ProtectionDomains devraient être supprimable également:

#Destructions des ProtectionDomains
$PDs = Get-NTNXProtectionDomain
foreach ($PD in $PDs) {
Mark-NTNXProtectionDomainForRemoval -name $PD.name
}

 

 

Concernant l’automatisation, nous avons choisi de reprendre le nom du disque de base Xendesktop dans le nom du « Protection Domain », ainsi que pour le « Consistency Group ».

Cette méthode nous permet de surveiller la limite des 50 machines et nous n’avons qu’un upgrade de l’image de base à réaliser pour faire le découpage.

Vivement l’augmentation de cette limite car elle est encore administrable dans un petit environnement de quelques centaines de VDI, mais cela deviendrait difficilement compréhensible avec plusieurs milliers.

Si vous avez un autre mode de découpage, ou si vous gérez différemment vos réplications, n’hésitez pas à laisser un message dans les commentaires.

 

J’expliquais dans un précédent article, comment se connecter en powershell au Prism Central pour lancer des commandes comme sur des vCenters en linked mode.

Il s’avère que c’est une mauvaise idée, bon nombre de cmdlet ne s’exécutent plus avec les messages d’erreurs :

Request is not supported by this cluster.
Le serveur distant a retourné une erreur: (500) Erreur interne du serveur.
 WebException
+ FullyQualifiedErrorId : {« message »: »Request is not supported by this cluster. »}

ntnxerror

Connectez-vous directement sur chaque de vos clusters, cela évitera une bonne perte de temps. emo

Si vous débutez complément, voici les commandes à faire pour se connecter avec un minimum de pré-requis à savoir Powershell et les cmdlet nutanix.

Ce dernier est disponible directement depuis la console Prism dans admin > download Cmdlets Installer.

cmdlet


#chargement des cmdlets
asnp nutanix*

#Connexion sur un noeud du cluster
Connect-NTNXCluster 10.0.0.1 -AcceptInvalideSSLCerts

 

 

Pour cet article, je partirai du principe que vous avez les bases pour monter une infra nutanix et xendesktop, le point ici concerne spécifiquement la réplication asynchrone de VDI Xendesktop provisionné par MCS pour des machines persistantes évidemment.

La réplication en mode synchrone ne posera aucun problème car elle fonctionne au niveau du datastore et ne sera donc pas traité dans l’article.

Oui, il est possible d’avoir une réplication asynchrone de VM VDI généré par Machine Creation Service de Xendesktop entre deux clusters Nutanix sur du VMware ,et je vais vous expliquer comment !

Voici les bases de notre archi, 2 datacenters ayant chacun leur vCenter (5.5), un cluster de 3 nœuds Nutanix (4.5.2) et un broker Xendesktop (7.7).

Avec MCS, un basedisk est créé dans un répertoire portant le nom du catalogue Xendesktop, ce sont ces fichiers en plus de la VDI qu’il faut répliquer.

La documentation nutanix « Prism Web Console Guide » traite de ce point mais de façon incomplète :

nuta-xen-doc

En effet, il est clairement indiqué que les « linked clones » et leurs disques de bases doivent être hébergés dans le même groupe de consistance et le même domaine de protection.

nuta-linked

Il faut donc absolument spécifier le même groupe de consistance que celui de la VM à basculer.

/!\ attention, je simplifie volontairement ici avec une seule machine en partant du principe que vous avez conservez les options par défaut pendant la configuration du domaine de protection.

nuta-update-pd

Avec la commande ci-dessous on liste les groupes de protections, les noms des groupes de consistance ainsi que les fichiers ajoutés manuellement à la synchronisation:

ncli> pd ls

 

Puis on complète la ligne de commande dans la documentation :

ncli> protection-domain protect \ files=/container1/view-gold-image/replica-ABC.vmdk name=vmware1-pd  cg-name=vmware1-cg

 

En rapport avec les captures d’écrans cela donne:

ncli> protection-domain protect files=/nom_du_container/chemin_vers_basedisk/date_du_snapshot_xendesktop.vmdk name=test_VM cg-name=test_VM
ncli> protection-domain protect files=/nom_du_container/chemin_vers_basedisk/date_du_snapshot_xendesktop-flat.vmdk name=test_VM cg-name=test_VM

 

L’argument « cg-name » vous évite à la réplication le message d’erreur suivant : « Snapshot of Protection Domain PD_name failed as some files in consistence group CG_name are common with another consistence group » :

nuta_alert

Une fois la réplication opérationnelle avec toutes les dépendances, deuxième problématique, le  « parentFileNameHint » ce point mérite d’être mis en avant car il est très simple à éviter.

Après un migrate Nutanix, notre VM était bien basculé sur le site distant mais impossible de la démarrer.

« An unexpected error was received from the ESX host while powering on VM VM_name.
Reason: Reason
Cannot open the disk disk_name or one of the snapshot disks it depends on. »

nuta_poweron

Comme pour un « linked clone », la machine ne trouvait pas le chemin vers son disque de base, cette valeur étant renseigné dans le paramètre « parentFileNameHint » du vmdk de la machine.

Ce chemin n’était pas correct car dans notre cas l’ID du volume VMFS était celui du site source. Oui, vous avez bien lu, l’ID et non l’UUID, car les montage NFS n’en n’ont pas et sont simplement hashés. J’ai obtenu cette information sur ce site : NFS datastore does not have a UUID.

Il faut donc impérativement avoir les mêmes noms de conteneurs nutanix, étrangement ce conseil entre en parfaite opposition avec l’un des points de la documentation pour une config mono vCenter :

nuta_vc

Une fois les « remotes sites » nutanix reconfigurés plus de problèmes, les machines s’éteignent, se ré-enregistrent sur le vCenter du site distant et sont fonctionnelles.

Je viendrai enrichir ce billet dès que possible, en attendant n’hésitez pas à poser vos questions en commentaire si vous avez des difficultés avec cette configuration.