Mi è capitato di recente che nel vClient collegato al nostro vCenter fossero presenti molteplici messaggi come nell’immaigne sottostante
Di fatto la soluzione a questo problema è veramente semplice!
Infatti vi basterà collegarvi al vCenter, aprire la finestra dei servizi (services.msc) e cercare il servizio VMware vCenter Update Manager Service e riavviarlo!
Se siete amanti del cmd i comandi sono
net stop vmware-ufad-vci e net start vmware-ufad-vci
Utilizzando degli ESXi standalone non abbiamo la possibilità di sfruttare gli alert generati dal vCenter, ma possiamo sfruttare degli script che ci avvisano per email in caso di problemi.
Un ottimo script potete trovarlo qua, il quale ha la necessità di avere installato vCLI per funzionare.
Può capitare, ad esempio nei server Windows Server 2003, che al momento d’esecuzione dello script, si ottega un errore del tipo (generato eseguendo perl.exe)
The ordinal 3212 could not be located in the dynamic link library LIBEAY32.dll
In internet si trovano soluzioni in cui suggeriscono di rinominare tale libreria, ovviamente non funziona e con la versione 4.1 di vCLI è ancora presente, vedremo con la 5.0 appena uscita!
Comunque come amministratore nel caso di 7/2008 R2 o semplicemente tramite CMD in 2003/XP eseguiamo il comando ppm e una vuola aperto il Perl Package Manager rimuoviamo il pacchetto Crypt-SSLeay ancora alla versione 0.53
Fatto ciò ricerchiamo tra i pacchetti disponibili lo stesso pacchetto alla versione 0.57.
Problema risolto!
In tutti questi anni di blog non avevo ancora usato il mezzo per pubblicare qualcosa sul mio lavoro e quindi e’ l’ora di rimediare!
Grazie anche all’arrivo di un collega molto valido in azienda, ovvero la Silog Sistemi Logici di Siena, siamo in grado proppore in provincia e nelle province limitrofe, soluzioni vmware a tutto tondo, dalla “semplice” servers consolidation, al VDI con View fino al nuovo sistema di collaboration, Zimbra.
Per maggiori informazioni su tutte le nostre soluzioni www.silog.it oppure silog at silog dot it
Fantastico ricevere questo errore!
Nel mio caso era dovuto ad una SAN che aveva deciso di prendersi una vacanza..bhe ma che fare?
La risposta può essere anche molo semplice, create un nuovo snapshot e subito dopo cancellatelo, provate a dare power on e con buone possibilità la macchina ripartirà!
Ci potrebbero essere anche altre possibilità, ma dato che è sabato non vi tedierò, buon weekend!
Per i nostri clienti, anche per piccoli uffici, stiamo puntando molto sulla virtualizzazione, agli albori provammo VMware Server (1 e 2) ma adesso con ESXi 4.1 non c’è paragone.
L’installazione è velocissima e il parco hardware è notevolmente aumentato anche se è sempre consigliabile usare una cosa decente, no esclusivamente Lenovo ed IBM.
Parlando con addetti ai lavori e fornitori oramai sembra che questa sia il trend di VMware, infatti nelle future versioni dell’hypervisor, sarà disponibile solo ESXi, difatto facendo uscire di scena lo storico Linux di ESX.
Prossimamente stiamo progettando di riformattare tutti i nodi del nostro cluster in favore di ESXi.
Vorrei provare la versione embedded ufficiale IBM, anche se credo sia possibile farsela “in casa” abbastanza facilmente.
Altra interessante uscita nel mondo Apple, anche questo si è fato attendere ma finalmente è uscito il client VMware View per iPad, compatibile con la sola versione 4.6, in grado di sfruttare la potenza del protocollo PCoIP!
Provato sia in wifi che wan (a casa con Alice) attraverso il security gateway e senza VPN, con una fluidità veramente incredibile sui filmati flash.
Un’altra notevole feature è il touch pad virtuale, che permette un fluido controllo della freccia del mouse, sicuramente una soluzione più comoda di quella di Citrix (non tutti hanno anche l’iPhone).
Trovo che il range delle applicazioni è vasto, semplicemente il poter usare applicazioni normali Windows, quindi non native touch ma renderle tali è fantastico!
Puo’ succedere una cosa strana con gli snapshot, ovvero che tramite il vClient lo snapshot manager NON siano visibili alcun snapshot, ma semplicemente collegandosi via ssh al nodo esx o semplicemente tramite l browsing del datastore, nella dir della VM in questione sono presenti file NOMEVM-000002.vmdk e dai settaggi il disco in uso risulta proprio essere quel file.
Per risovere la questione delle volte basta creare un nuovo snapshot e poi consolidarlo e dovrebbero sparire tutti.
Ma potrebbero scaturire due errori
Unable to access file
Oppure
A general system error occurred: Protocol error from VMX.
Questo perche’ il file vmdk puo’ darsi che sia bloccato da un altra applicazione, magari un backup nel mio caso Acronis e su questo faro’ un post apposito, ma lo stesso succede anche con VMware VDR.
Una volta sbloccato il file principale bastera’ ripetere la procedura di cui sopra.
Questo potrebbe causare molti ma molti mal di testa, trovare una vm spenta, che già di per se è una cosa non bella (se non voluta), ma al riavvio viene un rassicurante messaggio del tipo “A General System Error Occurred” e nel dettaglio “A file was not found.”
Cos’è successo? Semplicemente nella cartella della macchina virtuale il file NOMEMACCHINA.vmdk è sparito…
Come saprete il file (principali) di VMware sono composti da
- *.vmdk : il file descriptor
- *-flat.vmdk : i dati veri e propri (raw)
- *.vmx : file di configurazione
Può capitare per le ragioni più disparate, nel mio caso Acronis Backup 10, il file vmdk venga usato e se qualche cosa va storto…perso!
Ovviamente senza di questo la macchina non può più riavviarsi! Ma niente è perso, può essere ricreato, ovviamente qui faccio un esempio SENZA la presenza di snapshot, cosa molto più complicata penso, in quel caso credo sia da far riferimento al file tipo NOMEMACCHINA-00000X.vmdk..
Comunque vieniamo a noi (si suppone di avere ESX e quindi la service console):
- Per prima cosa collegarsi via SSH al server ESX
- spostarsi nella cartella contente i file, es. /vmfs/volumes/myvmfsvolume/mydir
- controllare l’ESATTA grandezza del file vmdk, es. ls -l vmdisk0-flat.vmdk
-rw——- 1 root root 4294967296 Oct 11 12:30 vmdisk0-flat.vmdk- controllare nel file vmx la tecnologia del disco fisso virtuale, di solito lsilogic
- creare un nuovo disco virtuale vuoto vmkfstools -c 4294967296 -a lsilogic temp.vmdk
- a questo punto possiamo cancellare il flat APPENA creato, quindi temp-flat.vmdk
- rinominare il temp.vmdk con il nome originale, nell’esempio vmdisk0-flat.vmdk e editarlo come sotto (modificando il riferimento a temp.vmdk)
# Disk DescriptorFile
version=1
CID=fb183c20
parentCID=ffffffff
createType=”vmfs”
# Extent description
RW 8388608 VMFS “vmdisk0-flat.vmdk”
# The Disk Data Base
#DDB
ddb.virtualHWVersion = “4″
ddb.geometry.cylinders = “522″
ddb.geometry.heads = “255″
ddb.geometry.sectors = “63″
ddb.adapterType = “lsilogic”
ddb.thinProvisioned = “1″l’ultima riga va messa SOLO se il disco originale e quello creato sono stati fatti con l’opzione thin!!!!
A questo punto sarà possibile avviare (di nuovo) la nostra vm!
Titolo contorto? Può darsi!
Fatto sta che ho aggiornato in azienda (l’ottimo) Acronis per il backup aziendale e di conseguenza avevo aggiornato su di una macchine VMware ESX 3.5 (l’unica rimasta) l’appliance per il backup.
Al primo backup (quello di Exchange server, che risiede su questo host) mi da un bell’errore, sul SOAP, dicendo che non trova lo SDK all’url dell’host e così via…
Mi sono detto…vuoi vedere che non è compatibile con questa versione??
Infatti di diverso rispetto alla vecchia versione c’erano almeno un paio di cose, che in AMS veniva riportato l’FQDN dell’host-VA, mentre nelle vecchie versioni l’IP ed inoltre nella configurazione dell’agent era presente solo la richiesta di autenticazione sull’host, cioè prima andava impostata anche la password dell’agente stesso….(chi usa Acronis mi ha capito!).
Fatto sta che leggendo nella documentazione ho scoperto che ufficialmente l’appliance per ESX NON HA MAI SUPPORTATO ufficialmente ESX 3.5 pre Upgrade 2, l’host in questione è un 3.5 senza upgrade, dato cheè una macchina standalone non ho mai avuto la necessità dell’upgrade.
Mentre è probabile, anzi sicuro, che le nuove versioni dell’appliance sfruttano le nuove API di VMware e quindi non vanno più bene, per la cronaca quindi fino alla build 11105 si lavora tranquillamente con ESX 3.5 e U1, mentre dalle successive (adesso ho la 11639 no).
In breve, come funziona il cluster HA di vSphere?
Quando si configura un cluster HA su ESX, è consigliabile avere oltre la service console, anche una service console di backup su NIC separate e su switch separati per garantire che gli heartbeats continuino ad essere ricevuti in caso di una scheda di rete o switch vadano giu.
Se gli heatbeats non sono ricevuti per 15000 millisecondi (15 secondi), i server ESX entrano in isolation response che è, per impostazione predefinita arrestano le macchine virtuali in esecuzione in modo che possano essere riavviate su un altro host.
L’isolation response inzia quando un host ha smesso di ricevere gli heartbeats da altri nodi del cluster e l’indirizzo di isolamento non può essere pingato.
L’indirizzo di isolamento predefinito è il servizio di ESX console gateway, e la risposta di default tempo l’isolamento è di 15000 millisecondi (15 secondi).
Utilizzando la configurazione sopra descritta, con indirizzi IP nella stessa sottorete per la console di Backup Service e Service Console, entrambi gli indirizzi IP verranno risolti con lo stesso MAC per entrambe le NIC.
Questo farà sì che il nodo è segnalato come “isolato”, producendo effetti indesiderati sull’host, ad esempio l’impossibilità di accendere nuove vms sull’host e/o il non funzionamento del cluster stesso.
E ‘il comportamento di default di Red Hat Enterprise Linux che le interfacce di rete rispondano alle richieste ARP per l’indirizzo IP su qualsiasi interfaccia della macchina stessa. Un comportamento simile può essere visto quando un servizio di console è disconnesso, a causa di problemi di routing etc..
Su ESXi il problema non dovrebbe esserci, su ESX 3.5 non è risolvibile facilmente (e non è tema di questo post), mentre su ESX 4.x dato che è presente il nuovo kernel rispetto alla 3.5 è possibile farlo semplicemente collegandosi in ssh alla service console e digitare
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
mentre per rendere permanente la modifica aggiungere la seguente riga al file /etc/sysctl.conf
net.ipv4.conf.all.arp_ignore = 1
Previous Entries
Categories
Tag Cloud
Blog RSS
Comments RSS
Last 50 Posts
Back
Void 
Life 
Earth 
Wind 
Water 
Fire