Hoi effettuato seguendo passo passo il kb di VMware, il tutto senza grossi intoppi..bhe qualcuno piccolo si!
Sicuramente il peggiore è stato questo, in pratica il server vCenter si stoppava dopo pochi secondi di esecuzione, dopo circa un paio di giorni di utilizzo.
Dopo un breve sguardo all’event viewer si capiva che il problema stava nel SQL Server, nel mio caso l’Express, “Transaction log for database VIM_VCDB is full” quindi come risolvere?
Abbastanza semplice, usate il Management Studio Express, cliccate sul database VIM_VCDB con il destro, proprietà, sotto opzioni “Recovery Model” selzionate simple (nella versione italiana credo si chiami modello di recupero -> minimo).
Questo effettuerà lo shrink del Transaction Log, pertantò il vCenter sarà riavviabile senza problemi.
VMware consiglia di lasciare a simple (o minimo) questo valore.
Come tutti saprete ESXi non ha la service console, ma di fatto è possibile ancora collegarsi da remoto tramite SSH (nonchè usare SCP per trasferire files), ovviamente non esiste nessuna possibilità di farlo tramite vClient, ma tramite una “porta di servizio”.
Niente di più semplice
1. Dalla console di ESXi premere ALT+F1 per accedere alla console
2. Digitare “unsupported” (al buio) e premere invio. A video non comparirà nulla.
3. Se avete digitato il comando correttamente, vi comparirà una console denominata “Tech Support Mode” e vi verrà richiesta la password dell’utente root
4. Editare il file /etc/inetd.conf attraverso vi
5. Cercate la linea che inizia con “#ssh” e rimuovete il # iniziale. Salvare il file con :wq
6. Eseguite ps | grep inetd e controllate il pid del processo inetd. Se ad esempio il valore dovesse essere 1979, eseguite kill -HUP 1979 per riavviare inetd e di conseguenza ssh.
Ovviamente questa opzione “non è supportata” da VMware e potete usarla anche con ESX 3.5 Update 2,3,4,5
Dato che nella futura major release ESX scomparirà in favore del solo ESXi, mi sono detto..proviamolo!
Quindi ho fatto fuori un server con il vecchio ESX 3.5 e ci ho installato ESXi 4.0, aggiornato poi alla Update 2.
Ovviamente è molto più veloce, perchè la classica installazione Linux RedHat è sostituita dalla snella BusyBox, ma apparte ciò a me interessava inserirlo nel mio cluster vSphere, niente di più facile…o quasi.
Infatti collegango ESXi insieme a degli ESX potrete avere questo errore
HA agent on <esxhostname> in cluster <clustername> in <datacenter> has an error Incompatible HA Network:
Consider using the Advanced Cluster Settings das.allowNetwork to control network usage
Questo perchè a partire dal VirtualCenter 2.5 Update 2, due opzioni avanzate sono state aggiunte per permettere un maggiore controllo sulle reti utilizzate per la comunicazione di cluster. Queste due impostazioni avanzate permettono una maggiore flessibilità nel controllo e l’utilizzo delle reti di VMware HA, che i nodi abbiano reti compatibili.
Un’opzione, che non tratteremo ora, è das.allowVmotionNetworks mentre quella che interessa adesso è das.allowNetwork[...]
In pratica la rete di gestione in ESX si chiama tipicamente Service Console, mentre in ESXi Managment Network, quindi elevando ESXi a nodo del cluster otteniamo l’errore e per toglierlo semplicemente facciamo click con il tasto destro sul cluster, Enable VMware HA, click su VMware HA e poi Advanced options.
Qui scrivete das.allowNetwork0 Service Console e das.allowedNetwork1 managmnet Network, come in figura.
I massimi valori ammissibili sono da 0 a 10.
Fatto ciò potrete tranquillamente procedere alla riconfigurazione del cluster HA.
VMware Server 2, la soluzione di virtualizzazione gratuita di VMware, è usata soprattutto per ambienti di test o per piccole installazioni, ma rimane il fatto che è plausibile voler effettuare anche i backup delle macchine virtuali che girano su questo server.
Senza avvalerci delle finezze di business continuity offerte da vSphere, possiamo fare il backup di tali vms spegnendole, salvando il contenuto via rete tramite Robocopy e riattivando poi le vms, tutto questo tramite uno script che interagisca con l’sdk di VMware Server 2.
Ecco un semplice fa funzionale esempio
REM === Stop Virtual Machine ====
“c:\Program Files\VMWare\VMware Server\vmrun” -T server -h https://VMServer1.local:8333/sdk -u administrator -p password stop “[standard] VM1/vm1.vmx” soft
REM ==== Copy Virtual Machine to Backup drive ===
net use r: \\BackupServer\BACKUP\VirtualMachines\VM1 /user:domain.local\administrator password
robocopy “C:\Virtual Machines\VM1″ r: /mir /w:0 /r:0
net use r: /delREM === Start Virtual Machine ====
“c:\Program Files\VMWare\VMware Server\vmrun” -T server -h https://VMServer1.local:8333/sdk -u administrator -p password start “[standard] VM1/vm1.vmx”
Questo script può essere eseguito tramite le operazioni pianificate, quanto basta per salvaguardare le nostre vms di test!
Oggi, in virtù della mia SnS attiva sulla versione 6.5, mi è arrivata da VMware la licenza, con la possibilità di scaricare, la versione Workstation 7.
Questa versione è molto interessante perchè oltre a supportare pienamente Windows 7, supporta anche l’installazione senza accorgimenti particolari di VMware vSphere (esx 4.0) , ovviamente solo per fare dei test o eseguire delle demo, ma già questo è molto interessante per provare features che altrimenti avrebbero richiesto discreto hardware necessario, anche solo per effettuare delle prove.
Altre novità interessanti sono migliorato comparto grafico (funziona Aero Glass), la possibilità d’importare la XP MODE di Wndows 7, creare macchine con 4 processori logici e molto altro ancora.
A breve una prova sul campo, installerò il tutto sul mio Windows 7 Pro!
Questo problema mi stava facendo scervellare!
Nella nostra VM basata su Ubuntu e Asterisk 1.4.22 non c’era verso di trovare come far funzionare il BLF su dei GXP 2010, cosa tra l’altro da sempre usata.
Funzionava solo per l’hold delle chiamate, ma per il resto l’estensione digitando
core show hints
tutti i telefoni risultavano in idle anche durante una chiamata.
Ebbene dopo svariate ricerche ho trovato che per asterisk 1.4 e 1.6 ci sono bisogno di parametri aggiuntivi, rispetto alle releases precedenti, per far fuzionare totalmente i blf, ovvero
[general]
notifyringing = yes
notifyhold = yes
limitonpeers = yes
in sip.conf e per ogni estensione, dobbiamo impostare il call-limit, ad esempio 1 per i telefoni mono linea oppure più alta per i multi linea, come ad esempio i GXP-2010, sempre se volete gestire più chimate in ingresso con tali telefoni.
A questo punto vedremo lo stato libero, sta suonando, in attesa, occupato, che nei GXP è rispettivamente verde, rosso lampeggiante veloce, rosso lampeggiante lento, rosso fisso
Allora innanzittutto questo è un problema, ma un problema sultuario e poco rilevante, in quanto di solito (mi auguro!) VMware Server 2, seppur ottimo, è usato in piccoli ambienti e non troppo “mission critical”.
Finito il cappello introduttivo, capita che alle volte collegandosi alla User Interface (ui) web, Firefox, Explorer ed altri browser rimangano fermi su Loading…, nessun altro segno di vita ma solo un errore
vmtn is not defined
Line: 130
sembra che il management service si sia incriccato, quindi non rimane che riavviarlo.
/etc/init.d/vmware-mgmt stop
pkill -9 vmware-hostd
Tante volte l’immagini contano più delle parole, pubblicherò una serie di video del VMware World 2009.
In breve, PCoIP è un protocollo che permette di mantenere “l’esperienza” del desktop, grafica, applicazioni e USB nella virtualizzazione dei desktop.
Previous Entries
Categories
Tag Cloud
Blog RSS
Comments RSS
Last 50 Posts
Back
Void 
Life 
Earth 
Wind 
Water 
Fire