Buongiorno a tutti,
nuovo giorno, nuovo problema. Dopo l'installazione della versione 5 il boot del ESXi è diventato lentissimo.
Ho visto che il mio problema dipende dal solito e simpaticissimo cluster microsoft e che Vmware ha rilasciato una procedura da fare per ovviare al problema...la seguente: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=101610...
Ovviamente se sono qui...è perchè non ha funzionato! :smileycry: La procedura è per un cluster attivo/passivo da quanto ho capito....ovviamente il mio è attivo/attivo...qualcuno ha avuto la fortuna e il piacere di avere lo stesso "intoppo".
Ciao e grazie
Ciao
a me è capitato poche settimane fa lo stessissimo problema
un upgrade da vmware infrastructure 3.5 a vsphere 5 , il tutto è nato quando ho presentato le lun RDM del cluster MSCS al nuovo ambiente
la differenza (come hai già sottolineato) è che il mio era un cluster active-stanby , ma non riesco a comprendere la differenza in quanto
il problema sembra dovuto ad una diversa gestione degli RDM sulla ver 5
l'attività è stata fatta per tutte le lun RDM del cluster Microsoft?
dopo averle dichiarate come "Perennially Reserved" i log del nodo dicono la stessa cosa?
ciao
Sicuro che il tuo sia attivo/attivo?
Si parla per servizio/LUN, e per ovvie ragioni di condivisione dei dischi, di solito sono sempre attivi/passivi (una LUN è acceduta solo da un nodo).
Ciao a tutti,
aggiorno e chiudo la discussione...dopo aver "sbroccato" leggendo log etc etc mi sono deciso ad aprire la chiamata al support...
Il problema era che il comando suggerito dalla KB che lanciavo mancava di un prefisso naa.
Facendo la verifica risultava che i dischi fossero riservati, ma in realtà quei dischi non esistevano...cioè il numero era quello dei miei, ma senza naa. ovviamente esx non li riconosceva come riservati.
Es:
Questo il comando suggerito per mettere la reservation sugli rdm e non ritardare i rescan e i reboot
esxcli storage core device setconfig -d <naa.id> --perennially-reserved=true
La stanchezza (li ho fatti durante la notte) e la mia demenza (ma questa è colpa di madre natura :smileygrin: )mi hanno portato a scrivere il comando così
esxcli storage core device setconfig -d
600601602cf02810da2c079dfe8gh11 --perennially-reserved=true
anziché
esxcli storage core device setconfig -d
naa.600601602cf02810da2c079dfe8gh11 --perennially-reserved=true
Lanciando poi il comando per verificare se fosse riservato o meno
esxcli storage core device list -d <naa.id>
quindi nel mio caso(sbagliato senza naa.) esxcli storage core device list -d
600601602cf02810da2c079dfe8gh11
ricevevo come output quando mi diceva vmware dentro la KB e cioè...
Is Perennially Reserved: true
.
A questo punto mi sembrava tutto perfetto..ma non funzionava nulla
MI chiedo però come mai inserendo un comando senza un prefisso importante naa. l'elaboratore non abbia dato un messaggio di errore...boh...
Capisco che lui ti faccia inserire la reservation su un disco che attaccherai in seguito (in via del tutto preventiva) ma c'è la possibilità che il disco non abbia il prefisso naa. ? Magari non lo so io...
Comunque, l'errore è stato tutto mio ma alla fine grazie al support ho risolto...
Spero di aver aiutato qualche altro minchione come me a evitare di perdere del tempo
Saluti e buona serata!!
MI chiedo però come mai inserendo un comando senza un prefisso importante naa. l'elaboratore non abbia dato un messaggio di errore...boh...
Questo mi sembra un bel bacozzo, potresti chiedere di aprire un bug, in modo che lo fissino con una patch o una nuova release.
Capisco che lui ti faccia inserire la reservation su un disco che attaccherai in seguito (in via del tutto preventiva) ma c'è la possibilità che il disco non abbia il prefisso naa. ? Magari non lo so io...
Assolutamente sì, se il disco compare come "naa." significa che lo storage dall'altra parte supporta lo standard SCSI T11 per il formato di naming NAA, preferibile nonché teoricamente univoco in tutto il mondo (funziona in modo simile ai MAC address, anche se alcune volte non è così univoco).
Storage più vecchi che non supportano questo tipo di naming appaiono con prefisso "t10.", dall'omonimo standard SCSI.
Ciao,
Fabio
Capisco che lui ti faccia inserire la reservation su un disco che attaccherai in seguito (in via del tutto preventiva) ma c'è la possibilità che il disco non abbia il prefisso naa. ? Magari non lo so io...
Assolutamente sì, se il disco compare come "naa." significa che lo storage dall'altra parte supporta lo standard SCSI T11 per il formato di naming NAA, preferibile nonché teoricamente univoco in tutto il mondo (funziona in modo simile ai MAC address, anche se alcune volte non è così univoco).
Storage più vecchi che non supportano questo tipo di naming appaiono con prefisso "t10.", dall'omonimo standard SCSI.
Grazie Fabio,
come si suol dire...nella vita non si smette mai di imparare