rsicilia's Posts

Al di la del fatto che probabilmente la configurazione che hai scelto è ottimizzabile provo a risponderti: 1. In un ambiente mono-server condividere una NIC tra rete di management e rete VMs non ha particolari impatti. 2. Nel dialogo tra Switch e ESXi ti converrà probabilmente creare dei TRUNK verso un unico VirtualSwitch usando più NIC in uplink (ha poco senso associare una NIC ad una VLAN). In questo modo potrai creare dei PortGroup sul tui vSwitch corrispondendi alle VLAN dei tuoi switch (ho un po' banalizzato, se ti servono chiarimenti approfondiamo). 3. Devi fare questo esercizio di design: schematizza la rete in virtù delle VLAN a prescindere dagli apparati fisici che installerai, una volta che hai realizzato il giro delle reti fai il disegno tecnico definendo interconnessioni fisiche e configurazione delle porte. Spero di esserti stato utile Ciao -- Rocco Sicilia http://www.roccosicilia.it

Non ho esperienza specifica con HP (lavoro quasi esclusivamente su Cisco) ma il concetto di base è sempre quello: devi dare priorità al traffico di un set specifico di porte o di VLAN, nel tuo caso saranno quelle relative al traffico tra hosts e storage. Qui trovi info specifiche per i tuoi apparati: ftp://ftp.hp.com/pub/networking/software/2810-AdvTrafficMgmt-July2007-59914733.pdf. Ciao! -- Rocco Sicilia http://www.roccosicilia.it

Personalmente apprezzo la separazione dei ruoli delle reti, manterrei quindi le 4 VLAN. Ovviamente la cosa deve avere un senso, nel tuo caso potresti valutare delle policy di QoS per le VLAN che dialogano con lo storage. -- Rocco Sicilia http://www.roccosicilia.it

No, provo a spiegarmi meglio. Purtroppo non so come hai intenzione di configurare lo storage quindi faccio delle ipotesi. Supponendo di voler metter in visibilità lo storage con le VLAN 30 e 40 collegherei l'interfaccia 1 dello storage al pSwitch1 e l'interfaccia 2 al pSwitch2 entrambe configurate in TRUNK tagged per le VLAN 30 e 40. In questo modo i tuoi hosts potranno "vedere" lo storage, sulle VLAN scelte, anche in caso di fault di uno dei pSwitch. -- Rocco Sicilia http://www.roccosicilia.it

Ciao, credo che la cosa migliore sia collegarli con una porta per switch con entrambe le porte in TRUNK su tutte le VLAN di tuo interesse. In questo modo ci guadagni in affidabilità del sistema. In questa configurazione devi indagare sulle possibilità che ti offre il tuo storage per comprendere come utilizzare al meglio le tue NIC. -- Rocco Sicilia http://www.roccosicilia.it

sasab ha scritto: perdonami se non ho ben capito, fai riferimento al valore in millisecondi piuttosto che in MHz ? grazie. Esatto, mi riferisco al "tempo di attesa" (chiamiamolo così per semplificare) a cui i processi sono sottoposti. Se molto elevato si manifesta con lentezza del sistema. -- Rocco Sicilia http://www.roccosicilia.it

La procedura di avvio automatizzato delle VMs sugli host prescinde dalle logiche di clustering. La cosa più semplice credo sia scegliere arbitrariamente l'host di avvio, eventualmente bilanciando un po' il carico sugli host. Una volta avviato l'intero sistema ci penserà DRS a sistemare le cose (se lo hai). Ciao -- Rocco Sicilia http://www.roccosicilia.it

Ciao Andrea, esistono diverse integrazioni per raggiungere il tuo obbiettivo. Ti suggerisco questa lettura specifica per sistemi APC (ormai ex-APC): How to configure ESXi to shutdown using an APC SmartUPS (with lamw scripts) -- Rocco Sicilia http://www.roccosicilia.it/

Incredibile, un giocatore di UO (ho partecipato allo sviluppo di RunUO anni fa). Come ti ha giustamente detto Francesco utilizzando una connessione internet il server di UO ti identifica attraverso l'IP pubblico della tua connessione. Esistono diversi servizi VPN proxy che fungono da "ponte" tra la tua connessione internet ed il server di UO così da apparire con due account differenti. Altro metodo abbastanza immediato, ma preparati a molta LAG con uno dei due account, è transitare dalla rete Tor installando un Tor Client sulla virtual machine. Ciao! -- Rocco Sicilia

Ciao, ho trovato questa nota sulle procedure di converzione: VMware vCenter Converter Standalone Release Notes. Circa a metà documento trovi due note in relazione alla caso "In case of a dual-boot machine conversion" e la seconda è proprio inerente XP. Fammi sapere, sono curioso -- Rocco Sicilia

Innanzi tutto ringrazio entrambi per aver riportato il vostro punto di vista. ldelloca: sono estremamente d'accordo sul "bagno di sangue"... Anche io vengo da vCloud e sapere che per i VSPP resterà usabile mi fa tirare un mezzo sospiro di sollievo... resta il tema dei clienti con le classiche licenze perpetue. Il mio interesse per OpenStack è abbastanza datato ma solo di recente ho trovato il tempo di dedicarmici seriamente per capirne le effettive potenzialità e l'usabilità... e ammetto che la scintilla è stata la community VMware/OpenStack (https://communities.vmware.com/community/vmtn/openstack). E' un tema di riflessione... sicuramente bisogna iniziare a guardare seriamente vCAC per chi, come il sottoscritto, ha piacere a restare sulle soluzione di VMware, ma l'idea dell'integrazione con strumenti esterni (OpenStack è solo un esempio, ne esistono anche altri purtroppo molto acerbi) mi affascina soprattutto in virtù delle potenzialità che offre: nuove integrazioni, VDC multi hypervisor, diversi livelli di servizio (e di costi), ecc. -- Rocco Sicilia

Ciao Luca, grazie anche a te per il tuo punto di vista. Anche io sono attualmente molto legato alle ML ma comincio ad avere difficoltà di gestione principalmente legate al quantitativo di email che ricevo ed all'incredibile incapacità di molti utenti nell'utilizzo del campo "Oggetto" Ho quindi iniziato a guardare qualche soluzione che permetta di gestire test e comunicazioni in modo centralizzato ed auto-referenziato... ce ne sono diverse e SocialCast mi è sembrato abbastanza completo (in virtù delle mie poche esigenze) e semplice. Ciao! -- Rocco Sicilia

Ciao Francesco, grazie per il feedback! Nelle tue prove hai avuto modo di lavorare anche in team o non sei riuscito a coinvolgere altre persone? Mi interessa per comprendere se lo strumento può tornare utile come accentratore delle comunicazioni inerenti ad un progetto. -- Rocco Sicilia