ldelloca's Accepted Solutions

No, i file indicati sono relativi al vCenter agent, non c'entra con l'esecuzione delle VM in locale. Anche quando si riavviano i management services le VM continuano ad essere eseguite. Per il supporto, fai prima a telefonare a VMware e far verificare. Luca.

Ciao, avevo capito che i dischi sono logici, tranquillo, altrimenti i conteggi degli hard disk non sarebbero tornati. Chiamali volumi così siamo tutti a posto riguardo le preoccupazioni di corruzione, di qualsiasi componente (sia esso il disco, i raid, le partition table o i dati ospitati) ti proteggi con i backup, non ci sono altre soluzioni. Una corruzione del dato non la correggi nemmeno con 20 dischi di parità o mille partizioni separate, si corrompe e basta. Vai coi Backup. Per WS -> ESXi, registri in WS il server ESXi e ci puoi inviare le vm che crei localmente con WS, fa lui tutto in automatico. Per le prestazioni del "nested" ESXi, o vESXi, si hai ovviamente una perdita di performance rispetto all'installazione sul fisico, di quanto però dipende unicamente dall'hardware che possiedi (occhio che ti serve una cpu che supporti le estensioni VT-d nel caso di Intel, con anche l'ulteriore estensione EPT), e dall'evitare di eseguire troppi processi e programmi mentre WS fa girare il server ESXi. E' comunque una soluzione pensata per fare tests, laboratori, o usi sporadici come appunto import/export di VM. Luca

Un'altro motivo può essere che il disco sia IDE e non SCSI, se così fosse ci sono dei metodi per trasformarlo da uno all'altro, ci avevo scritto un articolo : http://www.virtualtothecore.com/?p=3385 Ciao, Luca.

Ciao, in generale si, il vincolo principale è il conteggio dei socket che viene fatto dal Guest OS, non solo per vincoli di licenza ma anche di limiti hardware supportati. Puoi iniziare a leggere qualcosa qui: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1010184 dove vedi ad esempio come passare molti core a un Windows 2003 che per limite gestirebbe solo 4 cpu, ovvero 4 socket. Ci sono poi anche altri problemi come ad esempio la gestione dei nodi NUMA da parte delle cpu multicore, trovi moltissimi articoli a riguardo, riassumere il tutto qui verrebbe molto lungo. C'è ad esempio un post di Frank Denneman di qualche anno fa molto ben fatto: http://frankdenneman.nl/2010/09/13/esx-4-1-numa-scheduling/ anche se è riferito a vSphere 4.1 , la spiegazione di come funziona un sistema numa è ancora valida. Ciao, Luca.

Ciao, potrebbe essere se oltre ai 16 TB che stai caricando, su quello stesso server hai altre VM i cui dischi, sommati tutti insieme, vanno oltre i 25TB. Puoi fare una controprova (se possiedi vmotion) a lasciare solo la nuova VM su quel nodo e provare ad aggiungere nuovamente i dischi. In ogni caso, segui il consiglio di Francesco, che approvo: togli i multi-extent, e fai un unico datastore, con il VMFS 5 non hai problemi di dimensioni dato che il limite è 64TB, quindi non vedo la necessità di complicarsi la vita con gli extent (hai uno storage che non può creare una LUN univoca da 22 Tb?). Ma più di tutto, su questo datastore crei i vari vmdk, però come ti ho detto da 1.98 TB, non da 2. Farli da 2 TB esatti crea problemi, perchè come ti abbiamo detto la dimensione massima consentita è 2TB - 512Byte, ma questo numero in TB non puoi esprimerlo quando crei il nuovo disco. Prova a fare tutti dischi da 1.98 TB e dimmi se cosi si avvia. Luca.

@tinto: Va tutto liscio perchè CentOS non usa il kernel 3.5 come Ubuntu.... Ho letto in giro di gente con gli stessi problemi di mancata compilazione di alcuni moduli usando il 3.5, puoi provare ad usare il kernel 3.4 ad esempio? Pare sia meno problematico in queste situazioni. Ciao, Luca.

Ciao, un ottimo documento da cui partire è questo: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1001805 In generale, se posso uso sempre la vmxnet3, che garantisce prestazioni migliori e un carico inferiore sulle cpu degli host. Al crescere delle virtual machine il risparmio complessivo inizia ad essere consistente. Ci sono alcuni casi documentati di incompatibilità e problemi (ad esempio nella clonazione delle VM 2008 R2, risolte da patch microsoft nella VM) e in quei casi puoi usare la E1000, che garantisce la massima compatibilità. Ciao, Luca.

Ciao Tinto, onestamente non ho mai sentito di problemi coi RamDisk che consumano precocemente la memoria su cui girano. Come dici tu, anche a me è sempre apparso come un problema più relativo ai dischi SSD e celle NAND in genere. In caso, i miei dubbi e successivi ragionamenti su quale possa essere la configurazione migliore, sarebbero relativi al fatto che sto eseguendo il programma su un area disco volatile e non persistente, quindi dovrò ben studiare come gestire i crash improvvisi e le perdite di dati. Ci sono casi in cui i DB vengono caricati a partire da un'unità non-volatile, e poi salvati nuovamente li, e quindi al limite si perde l'output di un singolo periodo di computazione; altrimenti bisogna studiarsi ovviamente e opportunamente le commit dei dati. PS: ho realizzato in passato delle VM linux per gli stessi motivi, quasi sempre robacce Java/Glassfish che distruggevano i dischi a causa di un eccessivo IO. Controlla a proposito anche "come" è fatto il db, a volte due semplici indici nei posti giusti riducono enormemente l'IO. Ciao, Luca.

Ciao, anche se l'errore non è esattamente identico, potresti verificare questo articolo della kb VMware, in particolare per la parte relativa ai datastore già presenti (anche se giustamente indichi che è un server nuovo): http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2037192 http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1008886 In particolare la parte di check delle partizioni. Da un controllo dei log almeno si può evidenziare l'errore specifico. Luca.

Ciao, guardando qui: http://www.vmware.com/resources/compatibility/detail.php?deviceCategory=io&productid=20594&deviceCategory=io&partner=46&keyword=82576&page=1&display_interval=10&sortColumn=Partner&sortOrder=Asc pare che almeno i driver della versione 2.1.11.1 siano già integrati nel cd-rom di installazione di ESXi 5.1, come puoi notare dal trovare a fianco alla versione la dicitura "inbox". Quindi non dovresti avere problemi nel fare l'upgrade almeno a 5.1, probabilmente update manager ti farà rimuovere i driver vib prima di procedere all'upgrade, essendo esterni sulla 4.0. Ciao, Luca.

Ciao, nel kit che indichi vSphere Replication è compreso nella licenza, e può sicuramente essere usato per il DR di tutte le VM, vCenter compreso. Ci sono alcune limitazioni da considerare, prima su tutte il modo migliore per configurare la replica in un ambiente con singolo vCenter: tipicamente VR prevederebbe due distinti vCenter, ma c'è modo di fare anche con un solo vCenter, e anche con un solo host volendo: http://pubs.vmware.com/vsphere-51/index.jsp?topic=%2Fcom.vmware.vsphere.replication_admin.doc%2FGUID-50985A20-8622-4269-94E3-7558A4ACB478.html la possibilità di proteggere vCenter con backup e replica è sicuramente uno dei motivi fondamentali per virtualizzare vCenter stesso. Ciao, Luca.

Il teaming e failover sono nella stessa configurazione, lo trovi nell'ultimo tab delle proprietà del vswitch. In ogni caso, il PortID è quello configurato per default nel primo vswitch che ESXi ti crea, devi solo aggiungergli le altre schede di rete (volendo direttamente in installazione quando configuri la management network, selezioni tutte le schede presenti). Il dubbio per il prendere 8 schede di rete è la dimensione della tua rete, veramente 6 VM da sole ti producono più di 4 Gbit di traffico??? Lo vedo difficile, altrimenti non avresti un singolo server con storage locale… Luca.

Beh, allora non è proprio l'ultima, c'è un ultimo giro di patch del 7 Marzo che porta il build number a 7 cifre!!! Per il tuo problema, mi è capitato qualche volta, raramente a dire il vero; solitamente senza pensarci troppo riavvio il management agent del singolo ESXi. Ho visto in giro diverse persone segnalare il problema ma mai la soluzione o il motivo di questo comportamento. A livello di firmware sui server ESXi sei aggiornato? Ciao, Luca.

Ciao, ho appena risposto a un argomento praticamente uguale in un altro thread, ti invito a leggere li, e in generale a verificare altri thread di questo forum. Ci sono numerosi post relativi al supporto USB di ESXi. La risposta rapidissima è: Si, può capitare che un disco si veda e uno no, il supporto non è 100%. Il disco che non si vede è formattato NTFS? Ci sono problemi noti a passare un disco NTFS a una VM via usb. Ciao, Luca.

Il mouse e la seriale non vengono passati in passthrough alla VM ospitata, è questa la differenza! relativamente alla periferica DTT, e in generale al supporto USB su vsphere, lo scrivo qui anche per altri che aprono altri thread appositi o che leggeranno in futuro, perchè è sempre lo stesso discorso: il supporto USB di ESXi è molto limitato, e il comportamento varia da periferica a periferica. Quasi sicuramente la tua periferica non è supportata, quindi ogni comportamento non ottimale è da mettere in conto, e l'unica è fare dei tests per verificare il comportamento all'atto pratico. So che è brutale, ma tant'è... Gli unici due documenti ufficiali cui si può fare riferimento sono questi: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1022290 http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=1021345

Ciao, il suggerimento di Veeam è dato dal fatto che non è presente uno storage condiviso e le VM risiedono sul server. La funzione di replica di Veeam permetterebbe di creare copie automatiche schedulate di tutte le VM anche sul server secondario. In caso di problemi al server primario sarebbe sufficiente accendere le repliche. Inoltre la parte backup permette di salvare le VM su un nas esterno, dato che le repliche hanno dei limiti che impediscono di usarle come backup appunto... Quindi con un budget minimo si potrebbe offrire un'ottima protezione anche senza una san condivisa. Ciao, Luca.

Ciao, io sinceramente non vedo il problema. Delle tre CPU che ti han chiesto, le prime due sono semplicemente stra-vecchie e fuori produzione, specie lo Xeon DP (dual processor). Quindi, dato che delle tre la più recente e in produzione è un E5, prendi un server con queste cpu a bordo e sei a posto con tutti i tre requisiti. Parti dal presupposto che la CPU oramai non è praticamente mai un collo di bottiglia, e qualsiasi processore moderno ti offre tanta potenza di calcolo. Se pensi di avere dei colli di bottiglia sulla CPU, è perchè stai per andare ad usarla per attività molto verticali come calcolo paralleo, rendering, business intelligence, ma a quel punto è una cosa che sai a priori. Per la valutazione, tu assumi che tutte le 3 VM vengano eseguite sempre al 100% delle capacità computazionali richieste. In realtà i valori sono di picco, e la media di utilizzo di una CPU è invece molto più bassa (rasente il nullo in molti casi), ragion per cui un "semplice" six core è in grado di soddisfare le richieste che hai posto. Anche per il discorso feature, o gli sviluppatori del software fanno chiamate dirette ad alcune funzioni hardware della CPU, cosa oramai scomparsa da anni, oppure il software è scritto per un generale processore X86, e quindi ogni cpu intel o amd va bene. Ciao, Luca.

Perdonami, ma se devi dimensionare correttamente un nuovo sistema virtualizzato e migrarci sopra dei server fisici tramite P2V, senza una misura precisa dei carichi di lavoro degli attuali server fisici, i rischi di sbagliare il progetto sono alti, così come quelli di sovradimensionare eccessivamente il sistema (con quindi un esborso di soldi eccessivo) proprio per la paura di sottodimensionarlo. Hai almeno preventivaro di realizzare un piccolo cluster con almeno 2 server? Visto che chiedevi se ipoteticamente ci starebbe tutto su un unico server, la risposta "teorica" è si (pensando a macchine con 4 socket e fino a 2Tb di ram che esistono in commercio, si fa stare quasi tutto oramai su un solo server), ma il dubbio è: sei sicuro? Stai per spostato quelli che prima erano tanti server separati, che si rompevano o si bloccavano uno alla volta, tutti su un unico server. Per quanto carrozzato e ridondato, metti che si rompa? Che fai? A questo punto devi fare un dimensionamento di tipo N+1 tipico dei cluster. Se ci sta tutto su un server, ne prendi 2. Se il computo totale ti da 2 server, ne prendi 3 e cosi via. Ciao, Luca.

Ciao, direi che la tua idea ha senso, se la VM ha un I/O troppo elevato per riuscire a farne la storage vmotion in tempi umani. Fossimo in altre condizioni le alternative sarebbero poche, ma essendo parte di un DAG permette di essere spenta, io quindi andrei per la tua soluzione. Non l'ho mai fatto su un DAG (perchè poi metterla su dischi locali o in fisico??? Vabbeh avrai i tuoi motivi) ma ad esempio su un DFS a volte è stato più comodo rifare da zero uno dei nodi e far rifare la sync a Windows, il concetto di fondo è lo stesso. Anche perchè la mole di dati da spostare alla fine è la medesima, che tu lo faccia via svmotion oppure tramite resync una volta avviato il nuovo server poco cambia alla fine. Oltretutto sovraccarichi meno il cluster vSphere, che potrebbe servirti durante la migrazione per avviare altre vmotion o svmotion più importanti e delicate. Ciao, Luca.