shadow di una sessione VMware View

Pubblicato il da
Risposta

Per potersi connettere (via vSphere console) ad una sessione VMware View (PCOIP) è necessario utilizzare su  una group policy chiamata “Enable access to PCoIP session from a vSphere console”. I passi per abilitarla sono:

  • Per Windows 7 bisogna utilizzare  Hardware versione 8. Per  Windows XP o Vista è possibile utilizzare qualsiasi versione hardware.
  • Creare  una nuova Group Policy Object (GPO)
  • Aggiungere il file  “pcoip.adm” alla Computer Configuration ( Il file lo si trova nel VMware View Connection server nel folder “C:\Program Files\VMware\VMware View\Server\extras\GroupPolicyFiles”)
  • Abilitare la policy  “Enable access to PCoIP session from a vSphere console” nelle impostazioni di tipo Computer Configuration
  • Assegnare la GPO alla OU dove risiedono i  VMware View desktops
  • Riavviare i VMware View desktops

 

DB Oracle in VMware

Pubblicato il da
Risposta

Uno dei dubbi che spesso assillano i clienti VMware è relativo alla virtualizzazione del DB Oracle. In particolare non è ben chiaro se Oracle installato in una VM VMware è supportato o meno da Oracle stessa. Per chiarire ogni dubbio in proposito diamo un’occhiata al pdf Virtualizing Business-Critical Applications on vSphere. In questo documento vengono analizzati gli aspetti di performances,  licensing,  supporto e le best pratices per la virtualizzazione di: Exchange, SQL, SAP, Sharepoint, Java, Hadoop e naturalmente Oracle. Per quanto riguarda il supporto di quest’ultimo il doc cita la nota 249212.1, pubblicata sul  MyOracleSupport (che copio qui sotto), in cui si dice che a fronte di problemi su un DB Oracle virtualizzato in ambiente VMware, Oracle potrebbe richiedere al clienbte di replicare la issue su un hardware fisico se questa issue non è conosciuta dal supporto Oracle. In questo caso VMware ha una Total Ownership Policy con cui dichiare di prendersi carico della issue e di risolverla esaudendo tutte le richieste del supporto Oracle.

 

 

 

Swap to host cache

Pubblicato il da
Risposta

Una delle features di  vSphere 5 è la SWAP TO HOST CACHE: può essere attivata solo nel caso in cui abbiamo dello storage di tipo SSD. Attivandola, sul datastore  scelto, verranno creati diversi files con estensione vswp da 1GB l’uno. Se ci troveremo in condizioni in cui l’hypervisor  sarà costretto a swappare pagine di memoria su disco, prima di utilizzare i ‘classici’  files vswp, utilizzerà questo spazio SSD più veloce . La swap cache viene condivisa da tutte le VM che girano sull’host. riducendo il decremento di performance delle VM. Quando la host cache sarà piena, lo swapping procederà sui tradizionali files vswp.

VMware View Storage Accelerator

Pubblicato il da
Risposta

Con la versione 5.1 di VMware View è stata introdotta una nuova feature: la View Storage Accelerator (o Host Caching):  permette di ottimizzare il carico sullo storage, abilitando una cache in RAM contenete  i blocchi comuni ad ogni VM, questi blocchi verranno letti dalla cache, sgravando lo storage di parecchie IOPS e migliorando notevolmente le perfomances dei desktop virtuali soprattutto nel momento del boot. View Storage Accelerator fa leva su una feature di vsphere 5.0 chiamata content-based read cache (CBRC), il cui modulo principale (CRBC VSCSI filter) si connette ad un VMDK facendone l’hashing ed il caching. L’ attività di hashing viene fatta sulle VM spente e consiste nel classificare tutti i blocchi (4K) dei boot VMDK generandone un identificatore (hash) per ogni blocco univoco,  e nel creare un file (-digest.vmdk) contenete tutte le hashes che rappresentano i blocchi. L’attività di caching viene fatta quando una VM viene accesa:per ogni blocco letto su disco ne viene caricata la hash nella RAM dell’host (in un area chiamata ‘VMDK metadata cache’ o ‘digest cache’ o ‘digest in-memory copy’) ed una copia del blocco  esso viene salvato nella in un RAM buffer (shared block cache) ed utilizzato dalla VM. Successivamente quando un’altra VM vorrà leggere un blocco identico, il sistema troverà (nella digest cache) l’identificatore di quel blocco ed il blocco verrà letto dalla shared block cache e non più dallo storage. Quando la VM farà una write, gli identificatori in RAM (digest in-memory copy’) dei blocchi scritti verranno invalidati, e la scrittura avverrà su disco. Il digest file viene rinfrescato (con i dati della VMDK metadata cache) ad intervalli ben specifici, impostati durante l’implementazione. Maggiori informazioni le potete trovare nel Technical Paper View Storage Accelerator in VMware® View™ 5.1 da cui sono tratti questi 2 flow esplicativi:

 


Desktop doesn’t refresh automatically in Windows 7

Pubblicato il da
Risposta

Per qualche giorno il mio win7 ha manifestato un problema piuttosto fastidioso: il desktop non si rinfrescava automaticamente, di conseguenza ogni volta che cancellavo un’icona,  essa rimaneva visibile sul desktop finché non premevo il tasto F5 (refresh).Con una ricerca su google mi sono reso conto di essere vittima  un problema piuttosto comune provocato da diverse cause e risolvibile con diverse soluzioni. Nel mio caso è bastato ricostruire la Cache delle icone cancellando il file C:\Users\mbalbiani\AppData\Local\IconCache.db. Dopo un reboot il problema è perfettamente risolto.

view persona management group policy setup

Pubblicato il da
Risposta

Con View Persona Management, possiamo configurare un profilo utente che viene sincronizzato dinamicamente con un repository centralizzato, in modo di permettere agli utenti di ottenere sempre lo stesso profilo ogni volta che si connettono ad un desktop virtuale. Per configurare questa feature, è necessario avere una licenza View Premier e configurane le Group policy. Ecco i passi necessari alla configurazione:

  1. - creare una share di rete con i diritti in scrittura per gli utenti che dovranno utilizzare la feature (I.E. \\server.domain.com\VPRepository\)
  2. - installare il view Agent con l’opzione Persona Management sulle VM parent o template che verranno usate per la creazione del desktop pool
  3. - Aggiungere il ADM Template file alla Active Directory e applicare la group policy alla OU che contains the desktops in the pool.
  4. - copiare dal view connection server il file <install_directory>\VMware\VMwareView\Server\extras\GroupPolicyFiles\ViewPM.adm in una cartella del Active Directory server
  5. - creare una OU per i desktop che useranno Persona Managemente (I.E: sul Active Directory server, selezionare Start > All Programs > Administrative Tools > Active Directory Users and Computers, cliccare col tasto destro sul dominio e selezionare New > Organizational Unit, scrivere un nome per la OU e cliccare OK
  6. - Sul Active Directory server, aprire la Group Policy Management Console (Start > Administrative Tools > Group Policy Management)
  7. - Nel pannello di sinistra, selezionare la OU che contiene/conterrà i view desktops e col tasto destro selezionare Create a GPO and and Link it Here.
  8. - digitare un nome per la GPO (I.E: ViewPersona)
  9. - selezinare la GPO creata e col tastro destro selezionare Edit
  10. - sul pannello di sinistra espandere Computer Configuration / Administrative Templates e cliccando col destro selezionare Add/Remove Templates
  11. - cliccare Add e selezionate il file ViewPM.adm che avete copiato precedentemente in una cartella del server
  12. - cliccare close e nel pannello di sinistra, sotto Classic Administrative Templates, apparirà Vmware View Agent Configuration > Persona Management
  13. - Selezionandolo, si potranno configurare le varie impostazioni della policy, per un test iniziale basta impostare
  14. Roaming & Syncronization > Manage User Persona = Enabled
  15. Roaming & Syncronization > persona repository location = la share di rete che avete creato in precedenza (I.E. \\server.domain.com\VPRepository\)
  16. Per tutte le altre impostazioni, vi raccomando di leggere il paragrafo View Persona Management Group Policy Settings nel manuale VMware View Administration

Ora non dovete fare altro che creare un desktop pool avendo cura di inserire nella Organizational Unit le relative VM. Vedrete che il profilo degli utenti che utilizzeranno quel pool sarà salvato nella cartella condivisa e verrà utilizzato dallo stesso utente su ogni VM a cui si loggerà.

vsphere 5.1 web client: nascondere la “getting started” tab

Pubblicato il da
Risposta

Con vSphere 5,1 il client via web diventa la gui di riferimento, per poterlo utilizzare basta installare il vSphere Web Client server  su un sistema Windows oppure avviare il servizio già presente sul vCenter Server Appliance. Poi con un browser basta connettersi allla URL https://client-hostname:9443/vsphere-client (la porta 9443 può essere modificata durante l’installazione del Web Client server). Per rimuovere la “getting started” tab che appare ogni volta che clicchiamo su un oggetto dell’inventario, basta cliccare sul menu “help” e selezionare “Hide all Getting started pages”

vcloud director 1.5.1: creazione del db SQL

Pubblicato il da
Risposta

Per creare un DB SQL utilizzabile con vcloud director 1.5 bisogna:

  • installare un SQL supportato (la matrice di compatibilità la trovate qui) su una macchina windows, specificando “MIXED MODE authentication” durante l’installazione
  • modificare l’utente con cui parte il servizio “SQL Server” da “NETWORK SERVICE” a “LOCAL SYSTEM ACCOUNT”
  • da un cmd prompt lanciare SQLCMD -S nome_server\nome_db
  • lanciare alcuni scripts che trovate qui sotto
  • dopo aver lanciato gli scripts, tramite SQL CONFIGURATION MANAGER, bisogna abilitare la connessione TCP/IP per il DB appena creato
  • se state utilizzando un SQL EXPRESS, è necessario abilitare ed avviare il servizio SQL SERVER BROWSER

Ecco i 4 script da lanciare con SQLCMD, il primo serve a creare l’istanza SQL, il secondo per impostare il “transaction isolation level” il terzo per creare gli utenti e l’ultimo per assegnare le permission agli utenti appena creati:

USE [master]
GO
CREATE DATABASE [vcloud] ON PRIMARY
(NAME = N’vcloud’, FILENAME = N’C:\vcloud.mdf’, SIZE = 100MB, FILEGROWTH = 10% )
LOG ON
(NAME = N’vcdb_log’, FILENAME = N’C:\vcloud.ldf’, SIZE = 1MB, FILEGROWTH = 10%)
COLLATE Latin1_General_CS_AS
GO

USE [vcloud]
GO
ALTER DATABASE [vcloud]
SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
ALTER DATABASE [vcloud]
SET ALLOW_SNAPSHOT_ISOLATION ON;
ALTER DATABASE [vcloud]
SET READ_COMMITTED_SNAPSHOT ON WITH NO_WAIT;
ALTER DATABASE [vcloud] SET MULTI_USER;
GO

USE [vcloud]
GO
CREATE LOGIN [vcloud] WITH PASSWORD = ‘vcloudpass’, DEFAULT_DATABASE =[vcloud],
DEFAULT_LANGUAGE =[us_english], CHECK_POLICY=OFF
GO
CREATE USER [vcloud] for LOGIN [vcloud]
GO

USE [vcloud]
GO
sp_addrolemember [db_owner], [vcloud]
GO

vsphere 5.1 doc ufficiale

Pubblicato il da
Risposta

Come sicuramente saprete durante il VMworld di San Francisco è stata annunciata la versione 5.1 di vSphere ( e di vCloud Director). Su tutti i blog, le notizie si rincorrono, i feed reeder continuano a sfornare artricoli circa le novità. Io mi limito a mettervi qualche link circa la doc ufficiale prodotta da VMware:

What’s New in VMware vSphere 5.1 – VMware vCenter Server

What’s New in VMware vSphere 5.1

What’s New in VMware vSphere 5.1 – Performance

Introduction to VMware vSphere Data Protection

What’s New in VMware vSphere 5.1 – Storage

Introduction to VMware vSphere Replication

What’s New in VMware vSphere 5.1 – Platform

What’s New in VMware vSphere 5.1 – Networking

VMware vSphere 5.1 vMotion Architecture, Performance and Best Practices

What’s new in VMware vSphere Storage Appliance

What’s new in vCloud Director 5.1

HA heartbeat datastores

Pubblicato il da
Risposta

Nella versione 5.0 di vSphere il prodotto HA è stato interamente riscritto. Una delle novità più interessanti è l’utilizzo dello storage come verifica dello stato di un host: nel momento in cui l’host master non riceve gli heartbeat da un host slave attraverso la management network, vengono utilizzati gli ‘heartbeat datstores’ per verificare l’effettivo stato dello slave e delle sue  VM.

All’interno  degli   ’heartbeat datstores’  esiste la cartella /.vSphere-HA, in essa sono contenuti alcuni files necessari al meccanismo del datastore heartbeating:

Il file host-<number>-hb determina  la host availability: ne viene creato uno per host e ogni host acceso lo tiene in uso esclusivo (locked). Il file host-<number>-poweron determina la virtual machine availability: ne viene creato uno per host e contiene la lista delle macchine accese su quel host. In tutti i datastores (compresi quelli di heartbeat) esiste il file  protectedlist che contiene il path delle VM protette da un master (macchine accese), il file viene aggiornato dal master su input del vCenter e viene utilizzato esclusivamente (locked)  dal master. Viene utilizzato da un nuovo master, eletto dopo il fallimento di un master precedente, per determinare l’elenco delle VM protette.

Quando uno slave smette di comunicare col master attraverso la rete, il master verifica se il file host-<number>-hb è locked, se non lo è l’host viene dichiarato caduto e il master riavvia le macchine virtuali che stavano su quell’host.

Se uno slave smette di comunicare col master attraverso la rete ed il master verifica la presenza del lock sul file host-<number>-hb, il master intuisce che  quell’host è isolato o partizionato ed inizia a monitorarne il relativo  host-<number>-poweron. Lo slave isolato scrive un bit all’interno del proprio   host-<number>-poweron in modo che il master possa avere una conferma dello  stato di isolamento, poi l’host isolato verifica se esiste un master che ha in carico le proprie vm, verificando se il file protectedlist è in uso (locked)  da un master, e, se lo è, eseguirà l’operazione specificata nel parametro isolation response, se l’azione consiste nello spegnimento della VM, lo slave toglierà qualla macchina dal  file host-<number>-poweron e scriverà un per-virtual machine file in una “poweredoff” directory, il master si accorgerà di questo cambio di stato così e riavvierà la VM.