Vous avez configuré votre sauvegarde locale, mais votre collège Citrix préféré supprime et provisionne sans cesse de nouvelles VDI persistantes :

Je passe la partie authentification, mais voici quelques lignes pour ajouter automatiquement toutes nouvelles machines à la sauvegarde existante (avec le nom LocalBackup) et supprimer de la sauvegarde les machines qui ne seraient plus disponibles.

 

Détermine la liste des VMs qui ne sont pas des CVM et qui ne sont pas
# dans un ProtectionDomain, c'est l'endroit idéal pour exclure des machines
# qui ne seraient pas à ajouter comme les CVM ou d'autres VMs si votre
# convention de nommage permet de les identifier facilement.
$UnProtectedVMs =  (get-ntnxvm | where {$_.vmName -notlike "*CVM*"} | where {$_.ProtectionDomainName -like $null}).vmname

#Ajout les machines non protégées à la sauvegarde
foreach ($VM in $UnProtectedVMs){
    echo "VM à protéger : $VM"
    Add-NTNXProtectionDomainVM -name LocalBackup -names $VM -Consistencygroupname $VM
}

#Determine la liste des VMs protégées dans le dernier snapshot
$ProtectedVMs = (Get-NTNXProtectionDomainSnapshot | Sort-Object Snapshotid | select -last 1).ConsistencyGroups

#determine la liste des VMs hébergées sur le cluster Nutanix
$VMList = (get-ntnxvm | where {$_.vmName -notlike "*CVM*"}).vmname

#Compare la liste complète des VMs à la liste des VMS protégées et conserve les protégées qui n'existent plus
$VMstoRemove = (Compare-Object -DifferenceObject $VMList -ReferenceObject $Protectedvms | where {$_.Sideindicator -like "<="}).InputObject

#Supprime les $VMtoRemove du ProtectionDomain
foreach ($VMtoRemove in $VMstoRemove){
    Remove-NTNXProtectionDomainVM -name LocalBackup -input $VMtoRemove
    echo "VM à supprimer :" $VMtoRemove
}

Rate this post

Excellent article Microsoft

https://support.microsoft.com/en-us/help/929851/the-default-dynamic-port-range-for-tcp-ip-has-changed-in-windows-vista-and-in-windows-server-2008


netsh int ipv4 show dynamicport tcp
netsh int ipv4 show dynamicport udp
netsh int ipv6 show dynamicport tcp
netsh int ipv6 show dynamicport udp

netstat -abn | find /c ":"


Get-Counter -Counter \TCPv4\*
Get-Counter -Counter \TCPv6\*

Rate this post

Depuis l’ESXi qui héberge la VM :

net-stats -l

noter le PortNum Correspondant à la VM qui nous intéresse dans notre exemple 67108873.

Pour avoir les statistiques nombre de packet et nombre de drop en émission et réception :

vsish -e get /net/portsets/vSwitch2/ports/67108873

Résumé des réceptions :

vsish -e get /net/portsets/vSwitch2/ports/67108873/vmxnet3/rxSummary

Résumé émissions :

vsish -e get /net/portsets/vSwitch2/ports/67108873/vmxnet3/txSummary

Toutes ces commandes peuvent aider à surveiller les drops de remplissage de « ring buffer » :

Large packet loss at the guest operating system level on the VMXNET3 vNIC in ESXi (2039495) 

Rate this post

Comme j’en faisais la démonstration à un collègue la semaine dernière, en dehors des gros bundle d’update HP ou Dell, voici ce que je fais pour mettre à jour un driver réseau.

Liste des cartes :

esxcfg-nics –l

côté HBA, noter le type de driver mptspi, lpfc par exemple

esxcfg-scsidevs -a

Driver version/firmware réseau :


ethtool -i vmnic0
driver: ixgbe
version: 3.21.4iov
firmware-version: 0x800007f4, 17.0.12
bus-info: 0000:01:00.1

ou

esxcli network nic get -n vmnic0

pour les HBA :

vmkload_mod -s HBADriver | grep Version

_______________________________________

ensuite il faut déterminer le driver recommandé

vmkchdev -l | grep vmnic0
0000:01:00.0 8086:10fb 1028:1f72 vmkernel vmnic0

ici :

  • VID = 8086
  • DID = 10fb
  • SVID = 1028
  • SDID = 1f72

Il est indispensable de vérifier sur le site de VMware : VMware Compatibility Guide

 

Choisir sa version :

 

télécharger le driver :

Intégration du pilote dans VMware Update Manager :

Depuis Update Manager administration > patch Repository > Import Patches :

 

décompresser le zip précédemment télécharger, pour VUM c’est le zip offiline bundle qui nous intéresse :

 

Créer la baseline et l’attacher aux serveurs pour mise à jour

Rate this post

 Alors que je me faisais une joie d’avoir un client vSphere « supporté » en HTML5, quelle ne fut pas ma surprise à la connexion sur le VCSA (vCenter Server Appliance) fraîchement upgradé:

Oui, vous avez bien vu, il y a toujours 2 clients, un avec Flash et l’autre en HTML5 mais avec des fonctionnalités partielles.

Je ne m’attendais pas à ça, mais VMware a simplement pris le fling du client HTML5 et collé un tampon supporté dessus !

Pour rappel, les flings sont des outils mis à disposition en mode laboratoire expérimental, ils ne devraient pas être utilisés en production au dire même de VMware, mais c’est une source d’outils très pratiques et communément utilisés par beaucoup d’Admin. Vous pouvez explorer cette caisse à outils ici : Labs VMware Flings

Du coup, j’ai fait quelques recherches sur les différences entre les deux clients, la liste est un peu longue, elle se trouve ici : vSphere 6.5 HTML 5 functionnality support.

Des mises à jour régulières sont promises et elles seront poussées d’abord sur le fling qui lui reste bien sr non supporté…

 

A noter la convention de nommage, le « vSphere Web Client » correspond au client Flash et le « vSphere Client » le HTML5.

 

Lien vers le fling du client html5 à réserver pour vos labs : vsphere-html5-web-client.

 

Rate this post