Resolution:

I have modified the registry key

HKLM\Software\Symantec\Backup Exec For Windows\Backup Exec\Engine\DOMINO

And changed Enable Notes Databse Filtering to 0

Now all seem working.

Thank you

Francesco

La migrazione a freddo sposta i file di configurazione delle macchine virtuali e riposiziona talvolta i file dei dischi. La migrazione a freddo prevede 3 passaggi principali:
Passaggio 1: vCenter Server sposta i file di configurazione, tra cui i file di configurazione del BIOS NVRAM, i file di registro, il file di sospensione per le VM sospese e, opzionalmente, i dischi delle macchine virtuali dall’host di origine all’area di storage associata all’host destinazione.
Passaggio 2: vCenter Server registra la macchina virtuale sul nuovo host.
Passaggio 3: al termine della migrazione, vCenter Server elimina le versione precedente della macchina virtuale dall’host di origine.
Se durante la migrazione si verificano errori, vengono ripristinati lo stato e la posizione originale della macchina virtuale.
Per eseguire la migrazione, è possibile spostare le macchine virtuali manualmente o impostare un’attività programmata.

La migrazione con VMotion consente di mantenere i processi attivi in esecuzione durante la migrazione. Tutto lo stato della macchina virtuale e il suo file di configurazione, se necessario, vengono spostati sul nuovo host, mentre lo storage dei dati rimane nella stessa posizione nello storage SAN condiviso tra i due host.
Le informazioni sullo stato della macchina virtuale includono il contenuto attuale della memoria e tutte le informazioni che definiscono e identificano la macchina virtuale. Il contenuto della memoria include i dati delle transazioni e qualsiasi bit del sistema operativo o applicazione presenti nella memoria. Le informazioni di definizione e identificazione memorizzate nello stato comprendono tutti i dati mappati agli elementi hardware della macchina virtuale, come il BIOS, le periferiche, la CPU, gli indirizzi MAC per le schede Ethernet, gli stati dei chipset, i registri e così via.
Questo schema mostra una configurazione elementare per illustrare il funzionamento della migrazione delle macchine virtuali con VMotion. Gli host di origine e destinazione hanno entrambi accesso a un datastore condiviso che contiene i file delle macchine virtuali. Gli utenti accedono alla macchina virtuale A tramite la rete Production (Produzione) evidenziata in arancione nello schema. La rete VMotion è evidenziata in blu.
Quando un amministratore utilizza la procedura guidata Migration (Migrazione), VMotion copia lo stato della memoria della macchina virtuale dall’host di origine a quello di destinazione nella rete VMotion. Mentre VMotion copia la memoria, gli utenti continuano ad accedere alla macchina virtuale ed è possibile quindi che aggiornino le pagine della memoria. VMotion mantiene un elenco delle pagine modificate in una mappa di bit della memoria sull’host di origine.
Quando VMotion ha copiato la maggior parte della memoria della VM dall’host di origine a quello di destinazione, disattiva la macchina virtuale, ossia mette la macchina virtuale in uno stato che impedisce l’esecuzione di ulteriori attività. Il periodo di disattivazione è l’unico momento durante la procedura VMotion in cui gli utenti non possono utilizzare la macchina virtuale. Il periodo di disattivazione è davvero minimo, solitamente inferiore al secondo, ed è completamente trasparente all’utente.
Durante il periodo di disattivazione, VMotion completa il passaggio finale verso l’host di destinazione trasferendo lo stato del dispositivo della macchina virtuale e la mappa di bit della memoria contenente l’elenco di pagine modificate durante la migrazione. VMotion mantiene la macchina virtuale di origine attiva in modo da poterla riportare sull’host di origine in caso di guasto.
Subito dopo aver disattivato la macchina virtuale sull’host di origine, VMotion inizializza la macchina virtuale sull’host di destinazione. Una richiesta di prenotazione ARP inversa avvisa la subnet che l’indirizzo MAC della macchina virtuale si trova ora su una nuova porta dello switch. A questo punto, gli utenti accedono alla macchina virtuale sull’host di destinazione anziché su quello di origine.
Mentre gli utenti accedono alla macchina virtuale sull’host di destinazione, VMotion copia la memoria rimanente (identificata nella mappa di bit della memoria) dall’host di origine a quello di destinazione. Se in questo intervallo di tempo un’applicazione tenta di leggere o scrivere da/su una delle memorie modificate, le pagine vengono acquisite dall’host di origine.
Quando tutta la memoria rimanente è stata copiata sull’host di destinazione, questo avvisa l’host di origine che la migrazione è terminata. A questo punto, VMotion elimina definitivamente la macchina virtuale dall’host di origine.

Per poter effettuare la migrazione con VMotion, sono necessari una licenza per VMotion e una configurazione specifica.
Gli host gestiti sul cluster devono utilizzare lo storage condiviso. Lo storage condiviso è generalmente su una SAN, ma può anche essere implementato utilizzando lo storage condiviso iSCSI e NAS.
Gli host gestiti devono utilizzare i volumi VMFS condivisi o trovarsi nello storage NAS.
Inoltre, gli host di origine e destinazione devono avere un set di processori compatibili. Per la compatibilità con VMotion, è necessario che i processori dell’host di destinazione siano in grado di riavviare l’esecuzione utilizzando istruzioni equivalenti a quelle utilizzate dai processori dell’host di origine al momento della sospensione.
Benché le velocità del clock, le dimensioni della cache e il numero di core del processore possano variare, i processori devono essere dello stesso produttore (ossia Intel o AMD) e della stessa famiglia di processori (P3, P4 o Intel core).
VMotion prevede inoltre requisiti specifici per la rete.
Per effettuare la migrazione con VMotion, è necessario avere interfacce di rete configurate correttamente sugli host di origine e destinazione.
VMotion richiede una rete privata Gigabit Ethernet (GigE) tra tutti gli host abilitati per VMotion.
Ciascun host abilitato per VMotion deve avere un minimo di due schede di rete Ethernet, di cui almeno una GigE.
Per soddisfare i requisiti di compatibilità VMotion, è necessario verificare il file di swap della macchina virtuale sia accessibile all’host di destinazione.
Il file di swap delle macchine virtuali sugli host su cui sono in esecuzione ESX 3.0 ed ESX 3.0.1 è memorizzato insieme al file di configurazione della macchina virtuale. Queste macchine virtuali possono essere migrate con VMotion solo se l’host di destinazione è in grado di accedere al volume VMFS dove è ubicato il file di swap.
È possibile configurare gli host su cui è in esecuzione ESX 3.5 o ESXi 3.5 o una versione successiva in modo che memorizzino i file di swap in una di queste due posizioni: insieme al file di configurazione della macchina virtuale o nel datastore locale di file di swap specificato per l’host. Inoltre, è possibile anche impostare le singole macchine virtuali in modo che la posizione del file swap sia diversa da quella predefinita dell’host corrente.
Per informazioni più aggiornate sui requisiti per VMotion, consultare il documento Basic System Administration Guide (Guida di base all’amministrazione di sistema) per ESX e vSphere.

La procedura guidata Migrate Virtuale Machine (Migrazione di una macchina virtuale) fornisce istruzioni dettagliate su come migrare una macchina virtuale tra più host. Le opzioni del menu sono leggermente diverse, a seconda del fatto che si esegua una migrazione a freddo o con VMotion.
Per aprire la procedura guidata, selezionare la macchina virtuale da migrare dall’inventario. Fare clic con il pulsante destro del mouse sulla macchina virtuale, quindi selezionare Migrate (Migra) dal menu.
Scegliere il tipo di migrazione: Change host (Cambia host), Change datastore (Cambia datastore) o Change both host and datastore (Cambia host e datastore).
In questo esempio, la macchina virtuale viene spostata su un nuovo host.
Selezionare le opzioni desiderate nella procedura guidata e fare clic su Next (Avanti) per passare alla sezione successiva. Al termine della procedura guidata, rivedere le modifiche, quindi fare clic su Finish (Fine).
vCenter Server sposta la macchina virtuale sul nuovo host. La scheda Events (Eventi) visualizza i messaggi relativi agli eventi. I dati visualizzati nella scheda Summary (Riepilogo) mostrano lo stato e la condizione nel corso della migrazione. Se durante la migrazione si verificano errori, vengono ripristinati lo stato e la posizione originale della macchina virtuale.

Ref. secoforma

Per reinserire la macchina virtuale nell’inventario, è possibile utilizzare la procedura guidata New Virtual Machine (Nuova macchina virtuale). Dopo aver impostato una configurazione personalizzata, continuare la procedura guidata come se si stesse creando un nuova macchina virtuale. Nella pagina Select a Disk (Selezionare un disco) fare clic sull’opzione  “Use an existing virtual disk” (Usa disco virtuale esistente), ricercare il disco virtuale nel datastore e selezionarlo. Quindi completare i passaggi restanti della procedura guidata.

Attenzione:

Se si rimuove una macchina virtuale che non è stata rimossa dal datastore dell’host gestito da vCenter Server, è possibile reinserirla in vCenter Server utilizzando la seguente procedura:
Passaggio 1: visualizzare nell’inventario il datastore che contiene il file di configurazione della macchina virtuale (.vmx).   
Passaggio 2: selezionare il datastore.   
Passaggio 3: fare clic su Browse this Datastore (Esplora il datastore).   
Passaggio 4: cercare il file .vmx nell’elenco Folders (Cartelle). In questo esempio viene mostrata la cartella VM-Customer Support.
Passaggio 5: fare clic con il pulsante destro del mouse sul file .vmx, quindi selezionare Add to Inventory (Aggiungi a inventario).   
Passaggio 6: completare la procedura guidata Add to Inventory (Aggiungi a inventario), quindi fare clic su Finish (Fine).   

Ref. Secoforma

Ref. secoforma

vSphere Client funge da console di gestione per le macchine virtuali e da interfaccia di amministrazione per i server vCenter e gli host ESX.

Fare clic sul pulsante Avvia dimostrazione quando si è pronti per iniziare.
Per iniziare l’installazione, avviare l’hardware conforme a ESX 4.0 utilizzano il CD o DVD che contiene l’immagine ISO di ESX 4.0 RC2. Poiché l’hardware deve essere conforme a ESX 4.0, è indispensabile tener conto di vari fattori. Il problema più comune deriva dal fatto che l’hardware non dispone di una CPU a 64 bit. Se il programma di installazione di ESX rileva una CPU a 32 bit visualizza il messaggio "Your CPU does not support long mode" (La CPU non supporta la modalità estesa).
Quando si esegue l’avvio dal CD o DVD di ESX 4.0 inserito nell’unità ottica, il server inizia il processo di avvio e si apre la pagina in cui è possibile selezionare la modalità.

L’opzione predefinita è l’installazione con interfaccia utente grafica, che è anche quella che verrà utilizzata in questa dimostrazione.
Se non si preme alcun pulsante entro 1 minuto, il programma di installazione selezionerà la modalità grafica che verrà utilizzata in questa dimostrazione. Premere Invio. Il sistema si prepara all’installazione di ESX 4.0 e visualizza in sequenza una serie di messaggi.

Questa è la schermata iniziale. A questo punto l’installazione con interfaccia grafica è iniziata. Fare clic su “Next” (Avanti) per continuare l’installazione.
Viene visualizzata la pagina "End User License Agreement" (Contratto di licenza con l’utente finale).

È necessario accettare il contratto di licenza per installare il prodotto.  Leggere tutto il contratto di licenza prima di accettarlo.
Selezionare l’opzione “I accept the terms of the license agreement” (Accetto i termini del contratto di licenza) e fare clic su “Next” (Avanti) per continuare.
L’installazione caricherà i driver richiesti per l’hardware. Se il sistema necessita di driver personalizzati specifici, è possibile specificarli selezionando “Yes” (Sì) e facendo clic sul pulsante “Add” (Aggiungi). Dopo avere selezionato "No" per non utilizzare altri driver o averli aggiunti, è possibile continuare con l’installazione.
In questa dimostrazione, selezionare "No" e fare clic su “Next” (Avanti).
Viene visualizzato un messaggio di avviso. Il programma di installazione avverte che da questo momento in poi non sarà più possibile installare driver personalizzati. Se non si è certi se l’hardware richiede driver personalizzati o se i driver selezionati sono corretti, ignorare questo avviso e selezionare “Yes” (Sì) per continuare l’installazione.

Selezionare "Yes" (Sì) per continuare.

Il programma di installazione carica i driver selezionati in precedenza. Al termine dell’operazione, fare clic su “Next” (Avanti) per continuare.
Viene visualizzata la pagina "License" (Licenza), in cui è possibile inserire il numero di serie della licenza o selezionare l’opzione "Enter a serial number later" (Inserire il numero di serie in seguito). Se si seleziona “Enter a serial number later” (Inserire il numero di serie in seguito), l’host ESX si avvia in modalità di valutazione. Per usare tutte le funzionalità, è necessario convalidare la licenza per ESX Server tramite vCenter Server.

Selezionare l’opzione "Enter a serial number later" (Inserire il numero di serie in seguito) e fare clic su “Next” (Avanti) per continuare.
Viene visualizzata la pagina "Network configuration" (Configurazione della rete). Utilizzare il menu a discesa della scheda di rete per selezionare la scheda di rete che verrà utilizzata dal sistema ESX per le attività di sistema. Questa scheda di rete è diversa da quella utilizzata per le comunicazioni delle macchine virtuali o per l’accesso allo storage NFS iSCSI, perché è la scheda di gestione a cui si connette vSphere Client o vCenter Server. È anche possibile configurare le impostazioni VLAN per questa scheda. È consigliabile configurare un ID VLAN solo si è certi che la rete lo richiede. In caso di dubbi, rivolgersi all’amministratore della rete.
Nota: è possibile connettere ESX Server anche se non si configura correttamente la scheda di rete o se le impostazioni VLAN sono errate. Ciò si applica sia vSphere Client che a vCenter Server. Questo tipo di errore di configurazione può essere corretto tramite i comandi specifici della console di ESX Server. Tuttavia, poiché molti utenti preferiscono reinstallare ESX, è opportuno selezionare con attenzione la scheda di rete corretta.

In questa dimostrazione, selezionare la scheda integrata NC373i, accettare le impostazioni predefinite e fare clic su “Next” (Avanti) per continuare.
Viene visualizzata la schermata "Network configuration" (Configurazione della rete).

A questo punto è necessario configurare la rete, ossia specificare le impostazioni della configurazione della rete per la gestione del sistema. L’indirizzo e la configurazione selezionati verranno utilizzati da vSphere Client o vCenter Server per connettersi a questo server. Questa è anche la configurazione della rete che ESX utilizzerà per accedere ai servizi esterni.

Benché sia possibile utilizzare DHCP per assegnare queste impostazioni all’host ESX, non è consigliabile farlo a meno che non si utilizzino metodi, come le prenotazioni DHCP, per specificare esattamente quale indirizzo e configurazione devono essere inviati a un server ESX specifico. VMware consiglia vivamente di utilizzare un indirizzo IP statico per l’accesso.

Quindi, in questa dimostrazione imposteremo un indirizzo TCP/IP statico.
Per iniziare, selezionare l’opzione "Use the following network settings" (Utilizza le seguenti impostazioni di rete) e inserire le informazioni richieste, come l’indirizzo IP, la subnet mask, il gateway e i dati del server DNS.

È importante prestare particolare attenzione a due aspetti. Innanzitutto alle impostazioni DNS. DNS è molto utilizzato da molti sistemi e prodotti tra cui High Availability, Site Recovery Manager e dalle macchine Virtual Desktop. La configurazione del server DNS viene utilizzata anche per risolvere i nomi dei server esterni a cui si connette ESX Server, come i server NTP, iSCSI e NFS.
Il secondo aspetto a cui è necessario prestare particolare attenzione è il nome dell’host. Inserire il nome completo della macchina, indicando anche il dominio se richiesto. Questa opzione è disponibile solo se si utilizza un indirizzo IP statico.
Verificare che si tratti di un nome di dominio completo. In questo esempio, chiameremo il server ESX sc-seal07 sc-seal07.vmware.com. Nota: in questa dimostrazione sono stati utilizzati nomi come sc-seal07 o sc-seal07.vmware.com perché impiegati nella rete in cui è stata creata la dimostrazione. In altri ambienti, il nome dell’host ESX potrebbe essere diverso, a seconda degli standard usati per l’assegnazione dei nomi.

Per verificare le impostazioni delle rete, fare clic sul pulsante "Test these settings" (Verifica queste impostazioni).
Nota: se la verifica si conclude con un errore, è necessario correggere le impostazioni e riprovare fino a quando la verifica non si conclude con un risultato positivo.

La schermata Install media (Supporti di installazione) viene visualizzata se si preme F2 e si inserisce il comando bootstrap askmedia nella schermata di selezione della modalità. A questo punto è necessario selezionare l’origine dell’immagine ISO di ESX. Ciò è utile se il pacchetto di installazione di ESX è ubicato su un host remoto. Sono disponibili varie opzioni:
Specify CD-ROM/DVD or USB media (Specifica il CD-ROM/DVD o supporto USB): è possibile selezionare un unità CD-/DV-ROM diversa da quella in cui è inserito il DVD di installazione di ESX.

Specify a network file system (NFS) server and a directory path (Specifica un server NFS e il percorso della directory)

Specify an HTTP or HTTPS URL (Specifica un URL HTTP o HTTPS)

Specify a file server (FTP) location (Specifica una posizione FTP)
Poiché l’installazione è stata avviata direttamente dal supporto ottico di ESX 4.0, selezionare l’opzione Specify CD-ROM/DVD or USB media (Specifica il CD-ROM/DVD o supporto USB) e fare clic su “Next” (Avanti) per continuare.
Viene visualizzata la pagina Setup Type (Tipo di installazione).
È possibile scegliere il tipo di configurazione per l’installazione. Ci sono due tipi di configurazioni disponibili.

Se si seleziona "Standard", ESX selezionerà la prima partizione dell’unità SCSI e la utilizzerà per l’installazione.

Se si seleziona "Advanced" (Avanzate), è possibile scegliere la partizione esatta in cui installare ESX. Il tipo di configurazione Advanced (Avanzata) fornisce anche opzioni per la configurazione dei datastore e del boot loader delle VM.
Per iniziare l’installazione, selezionare la configurazione "Standard".
Viene visualizzata la schermata "ESX storage device" (Dispositivo di storage ESX). A questo punto è possibile specificare dove installare il sistema operativo ESX. La pagina elenca i dispositivi di storage disponibili e lo spazio su disco.
Il programma di installazione di ESX fornisce un’unica procedura di installazione sia per i dischi locali che per i dischi di storage in rete. È estremamente importante scegliere l’opzione corretta durante la selezione dell’unità di destinazione.
Scegliere il dispositivo di storage locale e fare clic su "Next" (Avanti).
Se la posizione di destinazione contiene partizioni, viene visualizzato un avviso relativo alla possibile perdita di dati. Se si è certi che la partizione selezionata sia vuota, fare clic su "OK".

A questo punto è necessario configurare i fusi orari. Per impostazione predefinita è possibile impostarli graficamente selezionando la posizione approssimativa sulla cartina geografica. Selezionare il fuso orario degli USA/Pacifico e fare clic su "OK".
Fare clic su "Next" (Avanti) per continuare.

Ora, impostiamo la data e l’ora. L’ora può essere impostata in due modi: automaticamente e manualmente. Se ESX Server ha accesso a un server NTP, è possibile specificarlo selezionando “Automatically“ (Automaticamente) e inserendo il dominio completo o l’indirizzo IP del server NTP.

Se si sceglie di impostare manualmente l’ora, questa verrà sincronizzata dal clock dell’hardware di ESX Server. I clock dell’hardware del computer sono spesso imprecisi e sono sempre indietro rispetto all’ora reale. Per questo motivo è preferibile impostare l’ora automaticamente tramite un server NTP. Alcuni sistemi possono essere ubicati in reti isolate e non avere accesso al server NTP.
In questo caso il sistema è isolato, quindi l’ora deve essere impostata manualmente. Impostare manualmente l’ora e la data e fare clic su “Next” (Avanti).
Viene visualizzata la schermata Set Root Password (Imposta password root).
L’ultimo passaggio consiste nel configurare il primo account amministratore di ESX. Il nome predefinito di questo account è "root".   Inserire una password root.
ESX Server richiede che la password root sia costituita da almeno sei caratteri. Questa password deve essere naturalmente conforme alle convenzioni degli standard aziendali in uso. Il metodo migliore consiste nello scegliere password complesse costituite da lettere maiuscole e minuscole, caratteri speciali e numeri. Inserire e confermare la password root.

In questa schermata è possibile anche aggiungere altri account utente facendo clic sul pulsante "Add" (Aggiungi). Inserire il nuovo nome utente e la password. Ripetere la procedura per tutti gli account utente da aggiungere e fare clic su OK al termine dell’operazione.

In questa fase gli account utente sono facoltativi e possono essere inseriti anche successivamente. Nota: questi account utente sono account di ESX non di vCenter Server.
Fare clic su “Next” (Avanti) per passare al riepilogo finale.
Il programma di installazione visualizza un riepilogo di tutte le selezioni. Per apportare modifiche, è possibile tornare ai passaggi precedenti. È consigliabile scorrere le informazioni visualizzate nel riepilogo e confermarle prima di procedere con l’installazione.

Inoltre è buona prassi assicurarsi che il volume su cui è ubicato il Master Boot Record corrisponda al volume in cui verranno create le partizioni.
Al termine del controllo, fare clic su “Next” (Avanti).
L’installazione si avvia ed è possibile visualizzare l’avanzamento. Per la maggior parte dell’hardware, il processo richiede meno di trenta minuti.
Appena l’installazione è terminata, fare clic su “Next” (Avanti).
Viene visualizzata la schermata finale del programma di installazione di ESX 4.0, che contiene informazioni sull’indirizzo IP dell’host ESX e su come connettersi all’host di ESX tramite browser.

È possibile connettersi a ESX Server utilizzando un URL che contiene il suo indirizzo IP o nome host, visualizzati in questa schermata. Prenderne nota. Per riavviare il sistema, fare clic su " Finish" (Fine).

ref. vmweduc.com

Andy Rubin - attuale vice presidente per Mobile Platforms at Google - ha liquidato la questione con la seguente dichiarazione: “need different technology for different products,” il cui messaggio e chiarissimo. Android e Chrome OS hanno caratteristiche specifiche e uniche dedicate ai differenti ambiti di impiego.

Ipotizzando però smartphone sempre più evoluti e performanti non è poi tanto bizzarro ipotizzare una convergenza tra specifiche esigenze. A confermare questa ipotesi sarebbe stato lo stesso Sergey Brin - cofondatore di Google - che a margine di un evento ha dichiarato  “Android and Chrome will likely converge over time,” stando a quanto riportato da Cnet.com.

Non sono disponibili ulteriori dettagli utili a circostanziare questa affermazione, e tali elementi sarebbero sicuramente necessari per meglio capire il vero pensiero di Sergey Brin e su quali basi è stato formulato. In merito a Android installato sui netbook le prime implementazioni viste non ci hanno completamente convinto, infatti l’usabilità e la flessibilità vista non è paragonabile a quanto rilevabile sui molti smartphone dotati di tale sistema operativo. Proprio queste differenze di fondo confermerebbero l’attuale strategie nel portava avanti due progetti indipendenti, anche le parole di Sergey Brin non lasciano spazio a interpretazione.

A pochi giorni dalla presentazione di Google Chrome OS, e con la promessa di vedere sul mercato il nuovo sistema operativo, rimane ancora non del tutto chiara la roadmap di Google sul fronte Android e sul nuovo progetto Google Chrome OS. A creare confusione è proprio l’idea di fondo: sviluppare due sistemi operativi e mantenere i progetti su binari separati destinando un sistema operativo ai netbook e l’altro agli smartphone. Andy Rubin - attuale vice presidente per Mobile Platforms at Google - ha liquidato la questione con la seguente dichiarazione: “need different technology for different products,” il cui messaggio e chiarissimo. Android e Chrome OS hanno caratteristiche specifiche e uniche dedicate ai differenti ambiti di impiego. Ipotizzando però smartphone sempre più evoluti e performanti non è poi tanto bizzarro ipotizzare una convergenza tra specifiche esigenze. A confermare questa ipotesi sarebbe stato lo stesso Sergey Brin - cofondatore di Google - che a margine di un evento ha dichiarato  “Android and Chrome will likely converge over time,” stando a quanto riportato da Cnet.com. Non sono disponibili ulteriori dettagli utili a circostanziare questa affermazione, e tali elementi sarebbero sicuramente necessari per meglio capire il vero pensiero di Sergey Brin e su quali basi è stato formulato. In merito a Android installato sui netbook le prime implementazioni viste non ci hanno completamente convinto, infatti l’usabilità e la flessibilità vista non è paragonabile a quanto rilevabile sui molti smartphone dotati di tale sistema operativo. Proprio queste differenze di fondo confermerebbero l’attuale strategie nel portava avanti due progetti indipendenti, anche le parole di Sergey Brin non lasciano spazio a interpretazione.

A pochi giorni dalla presentazione di Google Chrome OS, e con la promessa di vedere sul mercato il nuovo sistema operativo, rimane ancora non del tutto chiara la roadmap di Google sul fronte Android e sul nuovo progetto Google Chrome OS. A creare confusione è proprio l’idea di fondo: sviluppare due sistemi operativi e mantenere i progetti su binari separati destinando un sistema operativo ai netbook e l’altro agli smartphone. Andy Rubin - attuale vice presidente per Mobile Platforms at Google - ha liquidato la questione con la seguente dichiarazione: “need different technology for different products,” il cui messaggio e chiarissimo. Android e Chrome OS hanno caratteristiche specifiche e uniche dedicate ai differenti ambiti di impiego. Ipotizzando però smartphone sempre più evoluti e performanti non è poi tanto bizzarro ipotizzare una convergenza tra specifiche esigenze. A confermare questa ipotesi sarebbe stato lo stesso Sergey Brin - cofondatore di Google - che a margine di un evento ha dichiarato  “Android and Chrome will likely converge over time,” stando a quanto riportato da Cnet.com. Non sono disponibili ulteriori dettagli utili a circostanziare questa affermazione, e tali elementi sarebbero sicuramente necessari per meglio capire il vero pensiero di Sergey Brin e su quali basi è stato formulato. In merito a Android installato sui netbook le prime implementazioni viste non ci hanno completamente convinto, infatti l’usabilità e la flessibilità vista non è paragonabile a quanto rilevabile sui molti smartphone dotati di tale sistema operativo. Proprio queste differenze di fondo confermerebbero l’attuale strategie nel portava avanti due progetti indipendenti, anche le parole di Sergey Brin non lasciano spazio a interpretazione.

A pochi giorni dalla presentazione di Google Chrome OS, e con la promessa di vedere sul mercato il nuovo sistema operativo, rimane ancora non del tutto chiara la roadmap di Google sul fronte Android e sul nuovo progetto Google Chrome OS. A creare confusione è proprio l’idea di fondo: sviluppare due sistemi operativi e mantenere i progetti su binari separati destinando un sistema operativo ai netbook e l’altro agli smartphone.

Andy Rubin - attuale vice presidente per Mobile Platforms at Google - ha liquidato la questione con la seguente dichiarazione: “need different technology for different products,” il cui messaggio e chiarissimo. Android e Chrome OS hanno caratteristiche specifiche e uniche dedicate ai differenti ambiti di impiego.

Ipotizzando però smartphone sempre più evoluti e performanti non è poi tanto bizzarro ipotizzare una convergenza tra specifiche esigenze. A confermare questa ipotesi sarebbe stato lo stesso Sergey Brin - cofondatore di Google - che a margine di un evento ha dichiarato  “Android and Chrome will likely converge over time,” stando a quanto riportato da Cnet.com.

Non sono disponibili ulteriori dettagli utili a circostanziare questa affermazione, e tali elementi sarebbero sicuramente necessari per meglio capire il vero pensiero di Sergey Brin e su quali basi è stato formulato. In merito a Android installato sui netbook le prime implementazioni viste non ci hanno completamente convinto, infatti l’usabilità e la flessibilità vista non è paragonabile a quanto rilevabile sui molti smartphone dotati di tale sistema operativo. Proprio queste differenze di fondo confermerebbero l’attuale strategie nel portava avanti due progetti indipendenti, anche le parole di Sergey Brin non lasciano spazio a interpretazione.

Internet Ref. google.com

When attempting to upgrade ESX 4.0 to ESX 4.0 Update 1 (U1), you may experience these symptoms:

• Upgrade operation may fail or hang and can result in an incomplete installation
• Upon reboot, the host that was being upgraded may be left in an inconsistent state and may display a purple diagnostic screen with the following error:
  COS Panic: Int3 @ mp_register_ioapic

Purpose

ESX 4.0 U1 includes an upgrade to glibc version 5.3 which implements a change in locking mechanism compared to glibc version 5.2 alreay installed with ESX 4.0. If rpm command is run during the installation of ESX 4.0 U1, a dead lock may be placed on rpmdb. See RedHat PR 463921.

As a result, upgrading ESX 4.0 to 4.0 U1 can fail or time out and leave the host in an unusable state.

While this issue is not hardware vendor specific, this has been reported to occur on HP Proliant systems if Insight Management Agents are already installed and running on the host being upgraded. Investigations into this issue revealed that Insight Management Agents run rpm command on a regular basis which triggers the deadlock during the U1 installation. This can also occur on any system from other vendors if you happen to manually run the rpm command, e.g. rpm -qa, while Update 1 installation is in progress.
Note: VMware esxupdate tool can be used standalone and is also used by VMware Update Manager and VMware Host Update Utility.

Resolution

Who is affected

1. Customers using VMware vSphere 4 upgrading to ESX 4.0 U1 on HP Proliant systems with a supported version of HP Insight Management Agents running.

2. Customers running rpm command on systems from any vendor while upgrading to ESX 4.0 U1.

This affects any of the following upgrading scenarios:

• Upgrade using Update Manager
• Upgrade using esxupdate
• Upgrade using vSphere Host Update Utility

Note: ESXi is not affected.

Note: If you want to install the update, you must download the update manually. The update is no longer available for automatic download in Update Manager and the vSphere Update Utility. You can find the update on the VMware Downloads site and copy the download to your local depot as needed.

Solution

To avoid this issue, do both of the following:

1. Do not run rpm command on any host while Update 1 installation is in progress

2. If Update 1 will be installed  on an HP Proliant Server, disable HP Insight Management Agents running on the ESX 4.0.0 host prior to installing Update 1

HP Insight Management Agents can be stopped using the following sequence of commands:

• service hpsmhd stop
• service hp-snmp-agents stop
• service hp-health stop

HP management agents will be automatically restarted after the upgarde is complete and the system is rebooted.

If you meet one or both conditions listed above under “Who is affected” section and you already ran Update 1 installation but have not rebooted the host yet, do not reboot the ESX host and contact VMware Technical Support for assistance. For more information, see How to Submit a Support Request.

WARNING: Rebooting the host means the host may need to be reinstalled because it is not recoverable after a reboot.

WARNING: If you have virtual machines running on local storage, they may not be retained if you reinstall ESX 4.0 as a result of this issue. Contact VMware Support for assistance before reinstalling.

Ref. http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1016070

LASTPRUNEDate     11/30/2009 10:53:45
MOUNTWait     Yes
SUBDir     Yes
REPlace     Yes
NOTESInipath e:\Program files (x86)\IBM\Lotus\Domino
LOGPRUne     60
BUFFers     3
BUFFERSIze     1024
LANGuage     ENU
DATEformat     1
NUMberformat     1
TIMEformat     1

Il file dsm.opt ( Folder \tivoli\tsm\domino )

*======================================================================*
*                                                                      *
* IBM Tivoli Storage Manager for Mail                                  *
* Data Protection for Lotus Domino                                     *
*                                                                      *
*                                                                      *
*======================================================================*

COMMMethod        TCPip
TCPPort           1500
TCPServeraddress  192.168.0.1
TCPWindowsize     63
TCPBuffSize       32
*quiet
resourceutilization 5
NODename          TDP_DOM

PASSWORDAccess    Generate

*SCHEDMODE             Polling
SCHEDLOGRetention     14
SCHEDMODE             Prompted
TCPCLIENTADDRESS 192.168.0.55
*TCPCLIENTPORT         1502

COMPRESSIon       NO
COMPRESSAlways    NO

*
EXCLUDE log.nsf
EXCLUDE mail.box

Attenzione , in fase di ultimazione dell’installazione vanno inseriti le chiavi , ossia va inserita nella folder “ domino “ il file *.lic.

IN FASE DI INSTALLAZIONE DELLA MACCHINA, VA PRIMA INSTALLATO IL BACLIENT E SUCCESSIVAMENTE INSTALLATO IL TDP ( FILE .EXE ). Procedura che preferisco. Al termine dell’installazione , crea il file scheduler per avviare il tcp comunication tra la macchina server TSM e il server di posta dove si è fatta l’installazione, facendo in mododi puntare al “ dsm.opt “ presente nella cartella domino della nuova installazione –> tivoli\tsm\domino

Ref. SECOFORMA.