Questo post è disponibile anche in: Inglese

Reading Time: 8 minutes

Realizzare un laboratorio per un ambiente VMware vCloud è sicuramente interessante per incrementare la propria esperienza e capacità, ma soprattutto è pressoché necessario se si vuole pensare di affrontare l’esame VCAP-CIA. Come ogni lab può essere realizzato con VM nested su piattaforma ESXi o su un sistema basato su Workstation. Vi sono pregi e difetti per ogni soluzione che non voglio affrontare dettagliatamente in questo post.

Probabilmente costruire l’ambiente sarà più semplice se già si possiede un server (o un PC carrozzato) con ESXi per il proprio lab. Sarà anche più scalabile, ma con un ambiente basato su ESXi 5.1 vi saranno dei possibili problemi di compatibilità con hardware vecchio.

L’ambiente basato su VMware Workstation è sicuramente più portabile, ma ovviamente servono abbastanza risorse. Vi è poi una complicazione in più se pensate di sfruttare il vCloud Director sotto forma di virtual appliance.

Un lab basilare su vCloud richiede almeno un vCenter Server (anche in versione virtual appliance), un ESXi (anche in versione virtuale), un vCloud Director cell node e un vShield Manager.

Da notare che vCloud Director è disponibile in due forme differenti:

  • Versione installabile: richiede ufficialmente una RHEL 5 o 6, ma funziona bene (benché non supportato) anche su una CentOS 5 o 6.
  • Versione sotto forma di virtual appliance: non disponibile nei download canonici, ma facilmente ottenibile richiedendo la versione evaluation (notare che saranno forniti anche dei codici per 60 gg); è importante però precisare che questa versione non è supportata in produzione.

Per la versione installabile, utile per fare anche un po’ di pratica con il deployment, l’importante è avere una distribuzione recente basata su RPM (meglio se RedHat o CentOS) e seguire i requisiti minimi che sono due schede di rete ed almeno 1 GB of RAM:

vCloudDirector51-RAM

Ma in questo caso dovrete prima preparare un DB supportato (Oracle o SQL) come pure generarvi le chiavi per le connessioni SSL.

Il vantaggio del virtual appliance è che è già preconfigurato con molto (gli manca giusto un server LDAP per fare qualche test sulle autorizzazioni) e soprattutto ha già un DB embedded compatibile (basato su Oracle XE, ma volendo funziona anche con un DB esterno). La curiosità è che l’appliance non è basato su RedHat o CentOS ma è il classico (almeno negli ultimi virtual appliance VMware) Suse Linux!

Il deploy del virtual appliance è veramente semplice (e sicuramente è il suo principale vantaggio): basta importare il file OVA ed impostare la configurazione desiderata. Tipicamente la scelta del DB interno sarà più naturale:

vCloudDirector OVF1 vCloudDirector OVF2

Il problema è che questo funziona bene solo se il deploy avviene su ESXi, nel caso di Workstation, le schermate precedenti non sono gestibili (devono poi diventare parametri dell’ambiente OVF), e il risultato è che l’appliance non riuscirà a partire con il seguente messaggio di errore:

vCloudDirector51-ApplianceError

L’errore è generato dallo script /etc/rc.d/rc3.d/S03vaos, in particolare alla riga:

sh /opt/vmware/etc/isv/firstboot

La causa è che il comando ovfenv (che legge le variabili dell’ambiente OVF) andrà in errore. In un ambiente che gira su vSphere, l’output che genera sarà simile a questo:

localhost:~ # ovfenv

[vami.DNS.vCloud_Director]=
[vami.gateway.vCloud_Director]=
[vami.ip0.vCloud_Director]=
[vami.ip1.vCloud_Director]=
[vami.netmask0.vCloud_Director]=
[vami.netmask1.vCloud_Director]=
[vcd.db.addr]=
[vcd.db.mssql.instance]=
[vcd.db.mssql.name]=MSSQLSERVER
[vcd.db.oracle.sid]=orcl
[vcd.db.password]=
[vcd.db.port]=
[vcd.db.type]=internal
[vcd.db.user]=
[vm.vmname]=vCloud_Director

Notare che anche copiando la macchina da ESXi a Workstation l’errore viene generato ugualmente. E soprattutto vi sono poi diversi altri controlli e quindi non è sufficiente rimpiazzare il comando ovfenv con uno script come questo:

localhost:/opt/vmware/bin # cat ovfenv
#!/bin/sh

cat << EOF
[vami.DNS.vCloud_Director]=
[vami.gateway.vCloud_Director]=
[vami.ip0.vCloud_Director]=
[vami.ip1.vCloud_Director]=
[vami.netmask0.vCloud_Director]=
[vami.netmask1.vCloud_Director]=
[vcd.db.addr]=
[vcd.db.mssql.instance]=
[vcd.db.mssql.name]=MSSQLSERVER
[vcd.db.oracle.sid]=orcl
[vcd.db.password]=
[vcd.db.port]=
[vcd.db.type]=internal
[vcd.db.user]=
[vm.vmname]=vCloud_Director
EOF

Morale, la soluzione più semplice per far andare il virtual appliance su Workstation è passare i parametri OVF attraverso uno ISO (come discusso nel precedente post). Nel caso si voglia usare il DB embedded e lasciare le schede di rete in DHCP (scelta ragionevole in un lab, considerando anche che Workstation è DHCP server per le reti NAT e Host only) la configurazione necessaria da mettere nel file ovf-env.xml sarà:

<?xml version="1.0" encoding="UTF-8"?>
<Environment
xmlns="http://schemas.dmtf.org/ovf/environment/1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:oe="http://schemas.dmtf.org/ovf/environment/1"
xmlns:ve="http://www.vmware.com/schema/ovfenv"
oe:id=""
ve:vCenterId="vm-25626">
<PlatformSection>
<Kind>VMware ESXi</Kind>
<Version>5.1.0</Version>
<Vendor>VMware, Inc.</Vendor>
<Locale>en</Locale>
</PlatformSection>
<PropertySection>
<Property oe:key="vami.DNS.vCloud_Director" oe:value=""/>
<Property oe:key="vami.gateway.vCloud_Director" oe:value=""/>
<Property oe:key="vami.ip0.vCloud_Director" oe:value=""/>
<Property oe:key="vami.ip1.vCloud_Director" oe:value=""/>
<Property oe:key="vami.netmask0.vCloud_Director" oe:value=""/>
<Property oe:key="vami.netmask1.vCloud_Director" oe:value=""/>
<Property oe:key="vcd.db.addr" oe:value=""/>
<Property oe:key="vcd.db.mssql.instance" oe:value=""/>
<Property oe:key="vcd.db.mssql.name" oe:value="MSSQLSERVER"/>
<Property oe:key="vcd.db.oracle.sid" oe:value="orcl"/>
<Property oe:key="vcd.db.password" oe:value=""/>
<Property oe:key="vcd.db.port" oe:value=""/>
<Property oe:key="vcd.db.type" oe:value="internal"/>
<Property oe:key="vcd.db.user" oe:value=""/>
<Property oe:key="vm.vmname" oe:value="vCloud_Director"/>
</PropertySection>
<ve:EthernetAdapterSection>
<ve:Adapter ve:mac="00:50:56:8b:4f:db" ve:network="vlan150-intranet" ve:unitNumber="7"/>
<ve:Adapter ve:mac="00:50:56:8b:0e:80" ve:network="vlan150-intranet" ve:unitNumber="8"/>
</ve:EthernetAdapterSection>
</Environment>

Questo file è poi da inserire in una ISO, o masterizzare su CD (ma non avrebbe molto senso). Volendo potete già scaricare la ISO pronta in questo zip file. Notare che dovrete aggiungere il virtual CD nell’hardware della VM.

A questo punto basta accendere per la prima volta l’appliance con la ISO connessa e aspettare l’autoconfigurazione. Ad onor del vero si fermerà nel punto relativo alla keyring chiedendo la relativa password (“passwd”)… curioso che questo non si verifichi quando viene importato in ESXi. In realtà pare basti aspettare un po’ e dovrebbe andare avanti da solo. Notare anche se se riducete troppo la memoria il DB embedded potrebbe non partire.

Alla fine rimane solo da completare la configurazione del vCloud Director usando il browser e puntando all’IP della management interface: in questo modo potrete creare un nuovo utente di admin e la sua password relativa. Notare che il wizard probabilmente sarà in italiano, questo perché vCloud Director (a differenza di vSphere) è localizzato in molte lingue e l’impostazione della lingua di visualizzazione viene definita dalle impostazioni del browser.

Per cambiare la lingua della GUI, senza cambiarla nel browser, vedere questo post. Per cambiare gli indirizzi IP fate invece riferimento alla KB 1028657 (Changing the IP address of the vCloud Director server). Per abilitare l’accesso a root tramite SSH, dovrete editare a mano il file /etc/ssh/sshd_config fine, modificare la riga PermitRootLogin line e riavviare il servizio.

Le password di default del virtual appliance sono:

  • vCD shell: root/vmware
  • Oracle XE instance: vcloud/VCloud
  • keyring password: passwd

Notare che la vCD cell ha come nome localhost.localdom name. Questo va comunque bene per un lab a singolo vCloud Director, ma può dare dei problemi nel caso di più server. In quel caso forse è meglio usare la versione installabile. Inoltre potrebbe dare problemi con le risoluzioni DNS… il consiglio è utilizzare solo gli indirizzi IP.

Ho anche realizzato un semplice video (in inglese, al momento) con i vari passi:

Andrea MauroAbout Andrea Mauro (2907 Posts)

Virtualization, Cloud and Storage Architect. Tech Field delegate. VMUG IT Co-Founder and board member. VMware VMTN Moderator and vExpert 2010-18. Dell TechCenter Rockstar 2014-15. Microsoft MVP 2014-16. Veeam Vanguard 2015-18. Nutanix NTC 2014-18. PernixPro 2014-16. Several certifications including: VCDX-DCV, VCP-DCV/DT/Cloud, VCAP-DCA/DCD/CIA/CID/DTA/DTD, MCSA, MCSE, MCITP, CCA, NPP.


Related Post:

Share