Problemi noti e soluzioni

In presenza di uno dei seguenti tipi di domini di risorse condivise basati su partizioni :

eseguendo nelle partizioni l’aggiornamento degli agenti gWLM, da gWLM A.01.x a gWLM A.02.00.00.x, nel medesimo complesso non sarà possibile aggiungere altre partizioni al dominio di risorse condivise.

Utilizzare l’interfaccia a riga dei comandi di gWLM per ripristinare il dominio di risorse condivise:

Se un nodo amministrato perde il contatto con il server di amministrazione centrale, non sarà più visibile in Shared Resource Domain View e nell’output di gwlm monitor, senza alcuna indicazione della presenza di un problema.

Controllare che gwlmagent sia ancora in esecuzione e che non ci siano problemi con la rete.

Quando l’agente gWLM è installato in un sistema con installato HP Integrity Virtual Machines - Integrity VM - le operazioni di rilevamento segnalano solamente i compartimenti di Integrity VM, anche se sono presenti pset e gruppi fss.

Per rilevare i pset o i gruppi fss nel sistema, è necessario disinstallare Integrity VM.

Il rilevamento di gWLM non segnala sempre le informazioni aggiornate delle macchine virtuali arrestate In particolare, quando una macchina virtuale è arrestata ed è stato modificato il numero di vCPU, il rilevamento fatto da gWLM non mostra il nuovo numero di vCPU. Segnala invece il numero di vCPU del più recente avvio della macchina virtuale.

Avviare la macchina virtuale prima di eseguire la rilevazione.

In quanto applicazione client-server, gWLM è maggiormente sensibile alla configurazione di rete del proprio host rispetto ad altri tipi di applicazioni. gWLM supporta l’amministrazione solamente all’interno di un singolo dominio di rete. Se, ad esempio, il proprio host del server di amministrazione centrale ha più schede di rete che sono connesse a più reti distinte tra loro, gWLM richiede che il nome host completamente qualificato sia convertito nell’indirizzo IP che sarà raggiungibile dagli agenti gWLM da amministrare.

Questo problema è sovente fastidioso quando un host è connesso ad entrambi i soggetti seguenti:

gWLM tenta di rilevare e di segnalare i problemi di configurazione di rete che possono essere causa di funzionamenti indesiderati, ma, in alcuni casi, il rilevamento avviene in un contesto che può essere segnalato solamente in un file di log.

In caso di comportamenti imprevisti - come un agente gWLM che non riesce ad eseguire un aggiornamento o un rapporto dello stato dei suoi carichi di lavoro - esaminare il file /var/opt/gwlm/glwmagent.log.0 dell’host per eventuali errori.

gWLM non supporta gli alias dei nomi host. supporta solamente il nome host DNS canonico (nome di dominio completamente qualificato).

Quando si configura gWLM tramite HP Systems Insight Manager, oppure tramite il file XML utilizzato dal comando gwlm, utilizzare solamente nomi DNS canonici.

Nell’interfaccia di SIM a gWLM, è visualizzato il messaggio seguente:

Unable to build a single shared resource domain from the set of specified hosts: nome_host_A.nome_dominio.com nome_host_B.nome_dominio.com

Questo messaggio è in genere dovuto a degli host che si trovano in complessi differenti. Se però gli host sono nel medesimo complesso, controllare le versioni degli agenti gWLM in questi host.

gWLM richiede che tutti gli agenti all’interno di un singolo dominio di risorse condivise siano della medesima versione. Installare la stessa versione dell’agente in tutti i nodi amministrati del dominio di risorse condivise.

Utilizzando la procedura guidata Manage New Systems, oppure il comando gwlm discover, si incontra il messaggio seguente:

Error during discovery of compartments.

e nel file /var/opt/gwlm/gwlmagent.log.0 è presente il messaggio:

com.hp.gwlm.common.PlatformException: /usr/sbin/parstatus -w exited with a non-zero exit status. Captured stderr is: Error: Unable to get the local partition number.

La causa più probabile è la presenza di una versione superata del software per le nPartition. Installare la versione più recente del software per le nPartition - anche se non le si utilizzando.

Con HP-UX 11i v1, accertarsi di avere la versione B.11.11.01.03.01.01 o successiva.

Con HP-UX 11i v2 in HP 9000, accertarsi di avere la versione B.11.23.01.03.01.01 o successiva.

Con HP-UX 11i v2 in HP Integrity, accertarsi di avere la versione B.11.23.01.04 o successiva.

Dove è possibile reperire questo prodotto:

(gWLM utilizza un comando fornito da questo software, che è presente in ogni versione di HP-UX, per stabilire le capacità del sistema.)

Occasionalmente, un agente gWLM ed il server di amministrazione centrale gWLM possono non essere d’accordo se un dominio di risorse condivise è stato effettivamente messo in attività. Ciò può avvenire quando si utilizza ^C - Control-C - per interrompere il comando gwlm deploy oppure quello undeploy. Può verificarsi anche in caso di errori durante il salvataggio di una configurazione di gWLM: la configurazione è messa in attività, quindi salvata nell’archivio delle configurazioni gWLM. Nel caso che avvenga la messa in attività, ma non il salvataggio, gli agenti gWLM considereranno il dominio di risorse condivise come in attività, mentre il server di amministrazione centrale lo considererà come non in attività.

Utilizzare l’opzione --force con gwlm deploy oppure con gwlm undeploy per sincronizzare nuovamente l’agente ed il server di amministrazione centrale.

Ad esempio, per ripetere la sincronizzazione, ed obbligare sia l’agente sia il server di amministrazione centrale a considerare come messo in attività il dominio di risorse condivise, eseguire il comando seguente:

# /opt/gwlm/bin/gwlm deploy --srd=nome_dominio --force

sostituendo a nome_dominio il nome del proprio dominio di risorse condivise.

Per ulteriori informazioni sul comando gwlm, consultare la manpage gwlm(1M).

È ripetutamente visualizzato un messaggio simile al seguente:

Unable to acquire the repository lock necessary to store changes. The lock is already held by: root(Tue Feb 08 13:11:08 CST 2005). Please retry your operation.

È possibile rimuovere il blocco arrestando e riavviando gwlmcmsd, anche se sarà necessario attendere fino ad un minuto prima di poter utilizzare gWLM:

	NOTA: L’arresto di gwlmcmsd disattiverà HP Integrity Essentials Virtualization Manager e HP Integrity Essentials Capacity Advisor.

# /opt/gwlm/bin/gwlmcmsd --stop

# /opt/gwlm/bin/gwlmcmsd

Non sono disponibili dati cronologici per i grafici - anche si è sicuri che nel lasso di tempo in questione è stato messo in attività un dominio di risorse condivise.

Un problema correlato si verifica quando si seleziona un periodo in cui ci si aspetta un’elevata attività del sistema, ma il grafico mostra un’attività limitata. Analogamente, ci si aspetta un’attività minima in un dato lasso di tempo, ma il grafico mostra un’attività elevata.

Controllare che l’orologio di sistema del server di amministrazione centrale e quelli di tutti i domini di risorse condivise siano sincronizzati. Se gli orologi segnano orari decisamente diversi, gWLM potrebbe non essere in grado di far coincidere i dati dei nodi amministrati con il periodo di cui si desidera il grafico.

Un rapporto di gwlmreport è basato su un periodo che parte da mezzanotte di un dato giorno e termina la mezzanotte del giorno seguente. Qualsiasi campione che si sovrappone all’ora iniziale oppure a quella finale del periodo sarà escluso dal rapporto.

Non esiste una soluzione, ma è necessario essere a conoscenza di questo fatto.

Questi campioni potrebbero essere contenuti nel rapporto in una release futura.

I criteri per weight consentono a gWLM di stabilire l’assegnazione delle risorse in caso di loro eccesso. Impostando al medesimo valore tutti i criteri per weight utilizzati in un dominio di risorse condivise, le risorse dovrebbero essere assegnate ai carichi di lavoro associati un modo bilanciato. Tuttavia, in un dominio di risorse condivise, impostando a 0 tutti i criteri farà sì che ad un singolo carico di lavoro siano assegnate tutte le risorse in eccesso.

Utilizzare 1 invece che 0 come valore per weight.

Tentando di rimuovere da un dominio di risorse condivise il carico di lavoro predefinito (OTHER), è restituito il messaggio:

Removal of all compartments from an SRD is not allowed

Non è possibile rimuovere dal dominio di risorse condivise il carico di lavoro predefinito (OTHER). È necessario invece interrompere l’attività del dominio di risorse condivise.

gWLM è ideato per utilizzare le estensioni .log.0, .log.1 e .log.2 per i suoi file di log. Per il blocco dei file e garantire che in un dato momento solamente un processo gWLM aggiorni un log, gWLM utilizza Java. A partire da Java 1.4.2.06, il blocco dei file consente la creazione di file con estensione nel forma .log.0.n, dove n è un numero intero.

Se si utilizza Java versione 1.4.2.06 o successiva, e si desidera controllare nei file di log la presenza di errori, per cercare quali file contengono messaggi di errore recenti, utilizzare il seguente comando:

# /bin/ls -ltr /var/opt/gwlm/*log*

Quindi, sarà possibile utilizzare /usr/bin/tail to per visualizzare i messaggi nei file di log aggiornati di recente.

Se i file di log devono essere inviati all’assistenza HP, creare un file tar:

# cd /

# tar cvf /tmp/gwlmlogs4support.tar var/opt/gwlm/*log*

Inviare quindi all’assistenza il file /tmp/gwlmlogs4support.tar.

Il valore per il tasso di convergenza specificabile facoltativamente quando di definisce un criterio, attualmente ha effetto solo sui criteri personalizzati. I criteri per OwnBorrow e l’utilizzo non ne sono influenzati.

Questo problema sarà risolto in una futura release di gWLM.

Si riceve un messaggio che contiene:

...unable to create new native thread

La sua causa sono alcuni parametri del kernel con valori troppo bassi.

Con i criteri di utilizzo, è possibile ricevere un avviso nella forma:

Policy maximum (x CPUs) is greater than compartment maximum (y CPUs). Using compartment maximum instead.

dove x è inferiore a y.

È possibile ignorare questo messaggio: gWLM utilizzerà effettivamente il valore massimo del criterio.

Se si desidera eliminare questi avvisi, per ogni criterio di utilizzo:

I criteri personalizzati utilizzano dei valori metrici forniti dall’utente tramite il comando gwlmsend. Ripetendo la messi in attività di un dominio di risorse condivise che abbia dei criteri personalizzati, il valore più recente della metrica del criterio va perduto. In tale situazione, gWLM basa le sue assegnazioni sulla richiesta massima specificata nel criterio del carico di lavoro. Il carico di lavoro può ricevere le risorse di CPU rimanenti dopo che tutti i criteri sono stati soddisfatti.

Accertarsi di aggiornare i valori della metrica di tutti i criteri personalizzati subito dopo avere ripetuto la messa in attività.

In genere, gWLM non consente, in una singola nPartition o in un singolo sistema, la creazione nello stesso momento di più domini di risorse condivise basati su partizioni virtuali. Tuttavia, quando più utenti gWLM mettono in attività nello stesso momento più domini di risorse condivise, gWLM può inavvertitamente consentire questi domini multipli.

Eliminare uno dei domini di risorse condivise, quindi gestire nuovamente i carichi di lavoro del dominio appena eliminato, collocandoli in quello rimanente.

È visualizzato un messaggio d’errore simile al seguente:

Unable to deploy Shared Resource Domain: system1.pset.000, due to: Error starting Compartment Manager. Please save file /var/opt/gwlm/gwlmagent.log.0 and contact HP technical support.

Questo errore può verificarsi se in un sistema è presente un pset vuoto - un pset senza CPU ad esso assegnate - quando si crea e si tenta di mettere in attività un dominio di risorse condivise che comprende il sistema.

Assegnare delle CPU al pset, oppure rimuoverlo, quindi ripetere la creazione e la messa in attività del dominio di risorse condivise.

Tentando di visualizzare dei rapporti in tempo reale, si riceve il messaggio seguente:

Real-time data is currently loading, please wait...
You might also verify that the remote node is running and SRDs have been deployed.

Questa situazione è di norma solo temporanea. Se dovesse persistere, controllare che il daemon gwlmagent sia in esecuzione nei nodi remoti. Se è in esecuzione, fermarlo e riavviarlo. Nel caso che tale situazione persista, interrompere e ripetere la messa in attività del dominio di risorse condivise.

È visualizzato un messaggio simile al seguente:

Error trying to deploy SRD, nome_sistema.vpar.000 to
nome_sistema_2.nome_dominio.com. SRD, nome_sistema_2.fss.000 is already
deployed. Only one SRD is allowed to be deployed.

Interrompere l’attività utilizzando l’opzione --force con gwlm undeploy e riavviare gwlmagent nel nodo amministrato.

gWLM non aggiorna il monitoraggio di un dominio di risorse condivise - nelle riga dei comandi oppure tramite l’interfaccia grafica in HP SIM.

Una causa possibile può essere l’inattività di un nodo amministrato, oppure non è in esecuzione il suo gwlmagent. Se il nodo è in funzione, ma non l’agente, può essere disponibile un monitoraggio limitato. Per risolvere il problema, riavviare gwlmagent nel nodo amministrato.

con HP-UX 11i v2 (B.11.23), un’applicazione all’interno di un gruppo fss può bloccarsi quando è eseguita in una partizione virtuale, nPartition, o sistema a singolo processore.

Installare la patch PHKL_33052.

Con i compartimenti basati su pset o i gruppi fss, gWLM consente di collocare gli script in questi compartimenti, utilizzando dei record di applicazioni con nomi alternativi. Questo funziona solamente se la shell - o interprete - utilizzata è elencata nel file /etc/shells. In genere, perl non è contenuto in questo file. Gli script perl - ed altri script basati su shell o interpreti non elencati in in /etc/shells - non sono perciò collocati correttamente.

Questo problema non riguarda gli eseguibili.

Aggiungere /opt/perl/bin/perl, e qualsiasi altra shell o interprete, al file /etc/shells. gWLM riconoscerà le shell così aggiunte entro 30 secondi.

	NOTA: Dato che per lo script non è necessario il percorso completo, un utente malintenzionato potrebbe ottenere l’accesso ai compartimenti basati sui pset o i gruppi fss - che altrimenti non sarebbero accessibili - utilizzando il nome dello script per nuovi script e wrapper.

Se dei processi sono stati collocati nei carichi di lavoro utilizzando il comando gwlmplace, e si verifica uno qualsiasi dei seguenti eventi, i processi saranno in genere spostati nel pset o gruppo fss predefinito.

In questi casi, i processi saranno collocati secondo i record delle applicazioni, oppure secondo i record utente validi. Nel caso non esistano record, i processi sono soggetti alle regole di collocazione, descritte nella guida in linea, in “pset / fss group tips”, nella sezione “Precedence of placement techniques.”

Per conservare la collocazione dei processi attraverso la ripetizione della messa in attività, in gWLM, durante la creazione o la modifica delle definizioni dei carichi di lavoro utilizzare i record delle applicazioni o quelli degli utenti di gWLM.

Quando gWLM gestisce i pset in un sistema, ogni processo del sistema deve andare ad un carico di lavoro. gWLM colloca i processi secondo i record delle applicazioni o degli utenti, specificati al momento delle creazione o della modifica della definizione del carico di lavoro. Nel caso non esistano record, i processi sono soggetti alle regole di collocazione, descritte nella guida in linea, in “pset / fss group tips”, nella sezione “Precedence of placement techniques.”

Utilizzando psrset per la collocazione dei processi nei pset, gWLM molto probabilmente sposterà i processi nel pset predefinito.

Per conservare la collocazione dei processi, in gWLM, durante la creazione o la modifica delle definizioni dei carichi di lavoro utilizzare i record delle applicazioni o quelli degli utenti di gWLM. Se l’utilizzo dei record non è pratico, utilizzare il comando gwlmplace. Tuttavia, sarà necessario utilizzare gwlmplace ogni volta che sarà ripetuta la messa in attività di un dominio di risorse condivise, per riportare il processo nel carico di lavoro desiderato.

I gruppi fss creati da gWLM sono diventati abbandonati e non è possibile rimuoverli facilmente. Questa situazione può verificarsi in seguito a varie circostanze. Un caso è quando gestendo un dominio di risorse condivise basato sui gruppi fss, è utilizzato un secondo dominio di risorse condivise, per esempio a causa dell’inattività del primo. Ciò può lasciare il dominio di risorse condivise con dei gruppi fss che non è possibile rimuovere.

Rimuovere i gruppi fss.

Per rimuovere i gruppi, ci sono varie possibilità. Se è installato PRM, eseguire il comando:

# /opt/prm/bin/prmconfig -r

Se non è installato PRM, eseguire i seguenti comandi di gWLM:

I gruppi fss ora dovrebbero essere stati eliminati dal sistema. Tuttavia, le loro definizioni nei carichi di lavoro si troveranno ancora nell’archivio delle configurazioni di gWLM. È possibile rimuovere dall’archivio queste definizioni, e quella del dominio di risorse condivise, in due modi.

La prima possibilità è di rimuovere queste definizioni utilizzando l’interfaccia di gWLM in HP Systems Insight Manager. Scegliere il menu:

selezionare quindi il dominio di risorse condivise con i gruppi fss, quindi scegliere - nella barra dei menu di VSE Management - il menu:

La seconda possibilità è di utilizzare la riga dei comandi: