J'ai ren­con­tré ce pro­blème sur une machine vir­tuelle déployée sur un Hyper-V, au moment où j'ai voulu créer un modèle via SCVMM. La machine vir­tuelle est res­tée figée sur l'état Sys­prep en cours... et aucune action n'était dis­po­nible, hor­mis l' affi­chage de la mise en réseau (ce qui ne sert pas beau­coup dans notre cas...).

Au niveau du Ges­tion­naire Hyper-V la VM n'était plus exis­tante et mal­gré un rede­mar­rage de la console SCVMM et même de la machine SCVMM, voici une vue de la console SCVMM avec la machine vir­tuelle res­tant figée :

Lire la suite...

Le pro­cess de Resi­gna­ture n'a rien de nou­veau sur­tout en VI3, mais il demande une quan­tité énorme d'opération sur une grosse infra. Voici donc quelle com­mande pour auto­ma­ti­ser un peu le process:

Pour faire une pre­mière fois la resi­gna­ture  des LUNs sur un ESX (un rescan sur une hba est suf­fi­sant), en ligne de com­mande dans le Ser­vice Console taper:

1
2
3
4

echo 0 > /proc/vmware/config/LVM/DisallowSnapshotLUN
echo 1 > /proc/vmware/config/LVM/EnableResignature
esxcfg-rescan vmhba1
echo 0 > /proc/vmware/config/LVM/EnableResignature

Ensuite pour faire  un rescan sur tous les ESX en Power­Shell, taper la com­mande sui­vante pour toute un cluster:

1
2
3
4
5

Connect-VIServer  -server "localhost"
get-cluster "cluster" | get-vmhost | Get-VMHostStorage -RescanAllHBA
get-cluster "cluster" | get-vmhost | Get-VMHostStorage -RescanAllHBA
get-cluster "cluster" | get-vmhost | Get-VMHostStorage -refresh
Disconnect-VIServer -Server "localhost"

Ou cette com­mande pour tout le VirtualCenter:

1
2
3
4
5

Connect-VIServer  -server "localhost"
get-vmhost | Get-VMHostStorage -RescanAllHBA
get-vmhost | Get-VMHostStorage -RescanAllHBA
get-vmhost | Get-VMHostStorage -refresh
Disconnect-VIServer -Server "localhost"

Et éven­tuel­le­ment, s'il faut ré-inventorier l'ensemble des VMs d'un VMFS, taper la com­mande sui­vante à par­tir du Ser­vice Console d'un ESX:

1
2
3
4
5
6

#!/bin/sh
for i in `find /vmfs/volumes/LUN -name *.vmx`
do
echo "registering VM: $i"
vmware-cmd -s register "$i"
done

Réfé­rence:

• L'explication des Resi­gna­ture de LUN sur Yel­low­Bricks

Pour assu­rer une haute dis­po­ni­bi­lité et une répar­ti­tion de charge vers les ser­veurs TSE, il est pos­sible d'implémenter le NLB (Net­work Load Balan­cing) de Micro­soft avec le ser­vice Ses­sion Direc­tory pour Ter­mi­nal Serveur.

Le NLB va per­mettre d'avoir une seul IP vir­tuel et un host­name vir­tuel pour un ensemble de serveur.

Et le ser­vice Ses­sion Direc­tory va per­mettre équi­li­brer la charges des ses­sions sur les ser­veurs TSE. Le ser­vice créer une petite base qui contient la liste des ses­sions TSE sur les ser­veurs, ce qui per­met aux uti­li­sa­teurs de retour­ner sur le bon ser­veur si leur ses­sion était déconnectée.

Confi­gu­ra­tion NLB:

Aller dans les pro­prié­tés de la cartes réseau, sélec­tion­ner Net­work Load Balan­cing et cli­quer sur Pro­prié­tés.

Lire la suite...

VMware a sorti récem­ment l’Update 2 de vSphere 4.0. Cette mise à jour com­prend une nou­velle ver­sion des VMware Tools pour les machines virtuelles.Dans un envi­ron­ne­ment View 4.0.x avec PCoIP, la mise à jour des VMware Tools dans les vir­tual desk­tops pro­voque l’arrêt du fonc­tion­ne­ment de PCoIP.
Il n’existe pas à l’heure actuelle de solu­tion ni de wor­ka­round.
Une KB est dis­po­nible chez VMware : http://kb.vmware.com/kb/1022830

Un job de répli­ca­tion dans Vizion­core vRe­pli­ca­tor plante avec l'erreur "VzVSS 'Stop' API com­mand fai­led to exe­cute". Dans la par­tie vRe­pli­ca­tor Ser­vice de l'eventlog, on a le mes­sage d'erreur suivant:

VzVss 'Stop' API com­mand fai­led to execute.

Note that a detai­led log of the repli­ca­tion can be found at xxxxxxxxxxxxxxxx.rep­job

If you can­not resolve this pro­blem on your own, Vizion­core sup­port team will require the atta­ched log to deter­mine the cause of the pro­blem and advise you on the resolution.

Regards,
Vizion­core Team

La solu­tion est de redé­mar­rer le ser­vice VSS (Volume Sha­dow Copy ou Cli­ché Ins­tan­ta­nés) sur la machine source. Et par la même occa­sion redé­mar­rer le ser­vice "Vizion­core VSS Adap­ter" ca ne coute rien.

Si cette solu­tion n'est pas suf­fi­sante, il faut alors ré-installer l'agent VSS dans la VM en allant dans le menu "Tools > VSS options".

Très utile pour se connec­ter sur des infra­struc­tures clientes :

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=4603c621-6de7-4ccb-9f51-d53dc7e48047

Source : http://blogs.technet.com/b/windows7/archive/2010/05/28/remote-desktop-connection-manager-disponible.aspx

L'update 2 de vSphere est dis­po­nible depuis jeudi, voici les liens vers les Release notes

VMware vCen­ter Ser­ver 4.0 Update 2
http://www.vmware.com/support/vsphere4/doc/vsp_vc40_u2_rel_notes.html

VMware ESX 4.0 Update 2
http://www.vmware.com/support/vsphere4/doc/vsp_esx40_u2_rel_notes.html

Atten­tion, la mise à jour .Net fra­me­work 2.0 SP2 & 3.5 SP1 du 8 juin (kb980773) pro­voque une l'erreur sui­vante au lan­ce­ment du vSphere client:

Error par­sing the ser­ver "clients.xml" file.
The type ini­tia­li­zer for VirtualInfrastructure.Utils.HttpWebRequestProxy' threw an exception.

VMware a rep­porté ce pro­blème dans la KB1022611, il concerne seule­ment le client 4.0.0 et non l'update 1.
Le cor­rec­tif est donc d'installer l'update 1 du vSphere client.

Réfé­rences:

• /!\ Micro­soft Update KB 980773 /!\ sur Hypervisor.fr
• La KB1022611: vSphere Client does not open on any Win­dows ope­ra­ting sys­tems with the error: par­sing the ser­ver "clients.xml" file

Voici une pro­cé­dure pour étendre à chaud une par­ti­tion sur Win­dows XP/2003.

Sai­sir les com­mandes sui­vantes dans une invite de commande

disk­part
list disk --> Iden­ti­fier le disque conte­nant la par­ti­tion à étendre
select disk 1  --> Sélec­tion­ner le disque
list par­ti­tion --> Iden­ti­fier la par­ti­tion à étendre
select par­ti­tion 1 -> Sélec­tion­ner la par­ti­tion
extend --> Exten­sion de la par­ti­tion
exit

Remarque : Cette méthode ne fonc­tionne pas pour les disques sys­tèmes et sous Win­dows 2008 il est pos­sible de le faire graphiquement.

Après une mise à jour des VMware Tools et du Vir­tual Hard­ware (suite à une upgrade en vSphere), j'ai remar­qué que les para­mètres WINS des cartes réseau dans les VMs Win­dows ne sont pas conservé.

En effet suite à cette opé­ra­tion, c'est une nou­velle carte réseau qui est pré­senté (Cf. article pré­cé­dent) et il faut bien entendu sup­pri­mer l'ancienne de la liste des péri­phé­rique Win­dows.
Avec les com­mandes classiques:

set devmgr_show_nonpresent_devices=1

start devmgmt.msc

et cocher la case "affi­cher les péri­phé­riques cachés"

Lors du rem­pla­ce­ment par une nou­velle carte, seule la confi­gu­ra­tion IP & DNS est copié. On perd donc la confi­gu­ra­tion WINS.

Exemple de pro­blème: Un vCen­ter en VM avec des comptes uti­li­sa­teurs LDAP, suite à la mise à jour de la VM vCen­ter avec le VMware Tools et le VM hard­ware 7, il est impos­sible de se connec­ter au vCen­ter avec le vSphere client. Le pro­blème vient sim­ple­ment de la perte de la confi­gu­ra­tion WINS.