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
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!
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!
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
Hoi effettuato seguendo passo passo il kb di VMware, il tutto senza grossi intoppi..bhe qualcuno piccolo si!
Sicuramente il peggiore è stato questo, in pratica il server vCenter si stoppava dopo pochi secondi di esecuzione, dopo circa un paio di giorni di utilizzo.
Dopo un breve sguardo all’event viewer si capiva che il problema stava nel SQL Server, nel mio caso l’Express, “Transaction log for database VIM_VCDB is full” quindi come risolvere?
Abbastanza semplice, usate il Management Studio Express, cliccate sul database VIM_VCDB con il destro, proprietà, sotto opzioni “Recovery Model” selzionate simple (nella versione italiana credo si chiami modello di recupero -> minimo).
Questo effettuerà lo shrink del Transaction Log, pertantò il vCenter sarà riavviabile senza problemi.
VMware consiglia di lasciare a simple (o minimo) questo valore.
Come tutti saprete ESXi non ha la service console, ma di fatto è possibile ancora collegarsi da remoto tramite SSH (nonchè usare SCP per trasferire files), ovviamente non esiste nessuna possibilità di farlo tramite vClient, ma tramite una “porta di servizio”.
Niente di più semplice
1. Dalla console di ESXi premere ALT+F1 per accedere alla console
2. Digitare “unsupported” (al buio) e premere invio. A video non comparirà nulla.
3. Se avete digitato il comando correttamente, vi comparirà una console denominata “Tech Support Mode” e vi verrà richiesta la password dell’utente root
4. Editare il file /etc/inetd.conf attraverso vi
5. Cercate la linea che inizia con “#ssh” e rimuovete il # iniziale. Salvare il file con :wq
6. Eseguite ps | grep inetd e controllate il pid del processo inetd. Se ad esempio il valore dovesse essere 1979, eseguite kill -HUP 1979 per riavviare inetd e di conseguenza ssh.
Ovviamente questa opzione “non è supportata” da VMware e potete usarla anche con ESX 3.5 Update 2,3,4,5
Dato che nella futura major release ESX scomparirà in favore del solo ESXi, mi sono detto..proviamolo!
Quindi ho fatto fuori un server con il vecchio ESX 3.5 e ci ho installato ESXi 4.0, aggiornato poi alla Update 2.
Ovviamente è molto più veloce, perchè la classica installazione Linux RedHat è sostituita dalla snella BusyBox, ma apparte ciò a me interessava inserirlo nel mio cluster vSphere, niente di più facile…o quasi.
Infatti collegango ESXi insieme a degli ESX potrete avere questo errore
HA agent on <esxhostname> in cluster <clustername> in <datacenter> has an error Incompatible HA Network:
Consider using the Advanced Cluster Settings das.allowNetwork to control network usage
Questo perchè a partire dal VirtualCenter 2.5 Update 2, due opzioni avanzate sono state aggiunte per permettere un maggiore controllo sulle reti utilizzate per la comunicazione di cluster. Queste due impostazioni avanzate permettono una maggiore flessibilità nel controllo e l’utilizzo delle reti di VMware HA, che i nodi abbiano reti compatibili.
Un’opzione, che non tratteremo ora, è das.allowVmotionNetworks mentre quella che interessa adesso è das.allowNetwork[...]
In pratica la rete di gestione in ESX si chiama tipicamente Service Console, mentre in ESXi Managment Network, quindi elevando ESXi a nodo del cluster otteniamo l’errore e per toglierlo semplicemente facciamo click con il tasto destro sul cluster, Enable VMware HA, click su VMware HA e poi Advanced options.
Qui scrivete das.allowNetwork0 Service Console e das.allowedNetwork1 managmnet Network, come in figura.
I massimi valori ammissibili sono da 0 a 10.
Fatto ciò potrete tranquillamente procedere alla riconfigurazione del cluster HA.
Ieri mi è arrivato questo libro, ovvero Mastering VMware vSphere 4, acquistato in USA su Amazon.
Non ho avuto molti libri d’informatica in lingua originale, questo è nuovo e non esiste la traduzione e non è detto che sarà mai fatta, comunque sia è troppo superiore leggere questi manuali in lingua originale.
Sicuramente si mantiene meglio il pensiero dell’autore, che ha provato sul campo quella cosa, in quanto anche se bravo l’edizione italiana è curata da un traduttore, non necessariamente tecnico.
Poi l’edizione è della SYBEX, una garanzia per i manuali tecnici, devo dire un grande acquisto!
Previous Entries
Categories
Tag Cloud
Blog RSS
Comments RSS
Last 50 Posts
Back
Void 
Life 
Earth 
Wind 
Water 
Fire