La virtualització imbricada ha passat de ser una raresa de laboratori a convertir-se en una peça clau per muntar entorns complexos de proves, formació, desenvolupament i fins i tot certs escenaris al núvol públic. Poder executar màquines virtuals dins d'altres màquines virtuals obre un ventall enorme de possibilitats, des de muntar un mini CPD al teu portàtil fins a aixecar un campus de pràctiques complet a Azure o provar noves versions d'hipervisors a AWS sense arruïnar-te.
En aquest article baixarem a terra què és exactament la virtualització imbricada, com s'implementa a VMware, Hyper-V (Azure) i AWS EC2, quins requisits té, els seus principals casos dús reals, implicacions de rendiment, xarxes, llicenciament i bones pràctiques. La idea és que, en acabar de llegir, tinguis una visió molt completa i pràctica sobre quan t'interessa fer-la servir, com muntar-la i quines limitacions et trobaràs.
Què és la virtualització imbricada
Quan parlem de virtualització imbricada ens referim a la capacitat de executar un hipervisor com a màquina virtual dins d'un altre hipervisor que corre sobre maquinari físic, i alhora poder crear VMs dins aquest hipervisor convidat. És a dir, una VM dins d'una altra VM, amb diverses capes de virtualització una a sobre de l'altra.
En aquest context es fan servir diversos termes que convé tenir clars per no embolicar-se: l'hipervisor que s'executa directament sobre el servidor físic és el hipervisor host, mentre que l'hipervisor que instal·lem dins d'una màquina virtual se sol anomenar hipervisor convidat. Les VMs que corren directament sobre l'amfitrió físic són els anomenats hostes externs i les que s'executen dins d'aquest hipervisor convidat són els hostes interns o màquines virtuals imbricades.
Des del punt de vista tècnic, l'hipervisor convidat es creu que parla amb maquinari físic real, però en realitat està treballant contra un maquinari virtualitzat que us presenta l'hipervisor host. Si tens prou recursos, pots fins i tot encadenar més nivells (capa 4, capa 5, etc.), encara que el rendiment i la gestió es compliquen força ia la pràctica poques vegades es passa de dos o tres nivells.
Virtualització assistida per maquinari i requisits bàsics
Perquè la virtualització imbricada funcioni de forma mitjanament decent és imprescindible comptar amb virtualització assistida per maquinari (Intel VT-x, AMD-V o equivalents). Aquestes extensions permeten que l'hipervisor gestioni les transicions de context i les instruccions sensibles de manera molt més eficient que amb tècniques antigues com ara la traducció binària o la paravirtualització.
A la pràctica això implica que t'has d'assegurar que la CPU del servidor físic suporta aquestes extensions i que estan habilitades a la BIOS/UEFI. A més, l'hipervisor host ha de tenir la capacitat d'exposar aquestes extensions de virtualització al sistema operatiu convidat perquè l'hipervisor que corre com a VM pugui crear màquines virtuals de 64 bits i aprofitar l'acceleració per maquinari.
Un altre requisit important en entorns VMware és el nivell de maquinari virtual de la VM que allotjarà l'hipervisor convidat. Per poder habilitar la virtualització imbricada es requereix, com a mínim, la versió de maquinari 9 de la màquina virtual. A partir d´aquí, versions més modernes de Workstation, Player, Fusion i ESXi incorporen suport explícit per virtualitzar les extensions de CPU dins de les VMs.
Hipervisors i compatibilitats
La virtualització imbricada està disponible tant en hipervisors de tipus 1 (bare metall) com en hipervisors de tipus 2. A l'ecosistema VMware, ESXi és el clàssic hipervisor de tipus 1, mentre que Workstation, Player i Fusion són hipervisors de tipus 2 que s'instal·len sobre un sistema operatiu amfitrió.
En aquests productes es pot executar com a VM un altre ESXi, o fins i tot hipervisors de tercers com Microsoft Hyper-V o VirtualBox, sempre que l'hipervisor host permeti virtualitzar la HV (Hardware Virtualization) cap a dins. A grans trets, les combinacions suportades de forma tècnica serien:
- ESXi com a VM a VMware Workstation, Player o Fusion.
- ESXi com a VM a ESXi (entorn completament niat dins del propi stack VMware).
- ESXi com a VM en hipervisors de tercers (per exemple, sobre Hyper-V).
- Hipervisors no VMware com VM a ESXi, Workstation, Player o Fusion, sempre que siguin capaços d'aprofitar virtualització per maquinari.
A Hyper-V, la virtualització imbricada s'aprofita sobretot en contextos com Serveis Azure Lab, on es permet habilitar Hyper-V dins d'una VM de laboratori per crear al mateix temps màquines virtuals imbricades. I a AWS, l'arribada del suport oficial de virtualització imbricada a EC2 estàndard (no només instàncies bar metall) ha suposat un salt important per a molts entorns de test i desenvolupament.
Suport i restriccions oficials a VMware
Encara que a la pràctica la virtualització imbricada funciona molt bé en VMware, és important tenir en compte l'aspecte de suport oficial. VMware no contempla les VMs imbricades com una configuració suportada per a entorns de producció, la qual cosa es tradueix que, si obris un cas amb suport i la incidència està relacionada amb un entorn imbricat, és molt probable que no et donin cobertura.
La gran excepció a l'ecosistema VMware és l'ús del vSAN Witness Appliance, una màquina virtual ESXi imbricada que actua com a testimoni en arquitectures de vSAN Stretched Clusters. En aquest cas VMware sí que reconeix i documenta expressament aquest ús, en formar part de l'arquitectura oficial del producte.
Hi ha un altre escenari rellevant: la seguretat basada en virtualització (VBS) de Microsoft a VMs Windows. Des de vSphere 6.7, VMware suporta habilitar VBS dins de màquines virtuals Windows, cosa que a la pràctica suposa executar Hyper-V i certes funcions d'aïllament per virtualització dins d'una VM. Aquest cas està clarament documentat i sí que entra al paraigua de suport si compleixes els requisits de versió i configuració.
Llicenciament en entorns niats
Quan s'instal·len ESXi, vCenter o altres components de vSphere com a màquines virtuals per muntar un entorn imbricat, cal tenir present que el llicenciament és exactament el mateix que si s'instal·lessin a servidors físics. Cada instància d'ESXi, encara que sigui virtual, requereix la seva llicència o, si no, es pot utilitzar l'edició gratuïta o versions de prova per a entorns de laboratori.
Això s'aplica tant si desplegues ESXi imbricats sobre VMware com si els executes com a VM en hipervisors de tercers. Una manera habitual d'optimitzar llicències de CPU en aquests laboratoris és jugar amb el número de cors per socket assignats a la VM ESXi (paràmetre cpuid.coresPerSocket), sempre que les condicions de llicència ho permetin i respectis els límits de l'edició contractada.
Casos reals d'ús de virtualització imbricada a VMware
El gran atractiu de la virtualització imbricada és que et permet muntar entorns molt complexos sobre un únic host físic sense necessitat de desplegar racks de servidors, cabines demmagatzematge o switches dedicats. Alguns dels usos més habituals a VMware són especialment clars.
Laboratoris de formació i autoaprenentatge
Potser el cas més típic és el dels laboratoris de formació. Podeu desplegar diverses màquines virtuals ESXi, un vCenter Server i una VM per a emmagatzematge compartit (NAS virtual, vSAN o similar) sobre un únic host físic i reproduir gairebé al complet un entorn vSphere de producció: clústers, HA, DRS, Storage DRS, vMotion, etc.
Aquest enfocament és perfecte tant perquè un administrador es munti un laboratori domèstic al vostre PC o servidor de casa, com per impartir formació interna en una empresa. El fet que tot corri imbricat simplifica molt les proves: si un alumne trenca un host ESXi virtual o les VMs imbricades, només cal restaurar la VM ESXi externa des d'una còpia de seguretat per deixar-ho tot com estava.
Desenvolupament de solucions per a vSphere
Els equips que desenvolupen aplicacions o integracions específiques per a VMware (plugins, eines de backup, automatització, orquestració, etc.) solen necessitar entorns repetibles on aixecar versions concretes d'ESXi, vCenter i diferents configuracions de xarxa i emmagatzematge.
Gràcies a la virtualització imbricada poden desplegar hiper-ràpid múltiples entorns de prova, amb combinacions de versions, clústers i polítiques diferents, sense necessitat de disposar d'un gran parc de servidors físics ni de cabines costoses. S'arrenca l'entorn, es fa la prova, es destrueix o es clona segons convingui tot sobre un mateix hipervisor host.
Proves, actualitzacions i demos
Un altre ús molt potent és el de les proves de noves versions d'hipervisors o de canvis darquitectura. Abans d'actualitzar ESXi als hosts físics de producció o d'introduir una nova solució d'emmagatzematge, molts administradors munten l'escenari imbricat, simulen l'actualització i validen que tot funciona com s'espera.
De la mateixa manera, els equips comercials i prevenda solen utilitzar entorns vSphere imbricats per fer donem en viu a clients: aixequen diversos ESXi, un vCenter, un servidor d'emmagatzematge virtual i algunes VMs, tot dins una única màquina física de laboratori o fins i tot un portàtil potent, i poden mostrar funcionalitats com ara vMotion, HA, DRS o SRM sense dependre d'una sala tècnica completa.
Entorns mixts i núvols públics
La virtualització imbricada també s'aprofita perquè proveïdors de serveis gestionats puguin allotjar VMware sobre núvols públics o sobre plataformes heterogènies. Un exemple pràctic és desplegar un ESXi virtual sobre un amfitrió de núvol públic i allotjar-hi les VMs d'un client que ja treballa amb VMware, mantenint les seves eines i procediments.
A més, la possibilitat de fer còpia de seguretat d'entorns imbricats de diverses maneres (recolzant la VM que conté l'hipervisor convidat o les VMs imbricades individualment) ofereix molta flexibilitat de protecció de dades en aquests escenaris híbrids.
Rendiment de les màquines virtuals imbricades
A nivell de rendiment cal ser realista: cada capa addicional de virtualització introdueix overhead. A VMware, per cada VM en execució existeix un procés al host ESXi que consumeix RAM i CPU. Si dins d'una d'aquestes VMs estàs executant un ESXi amb diverses VMs imbricades, en realitat estàs acumulant diverses capes de processos, canvis de context i planificació sobre els mateixos nuclis físics.
A la pràctica, les VMs imbricades solen anar més lentes que les VMs normals. La magnitud de l'impacte depèn de factors com el rendiment del processador físic, la quantitat de memòria disponible, el tipus d'emmagatzematge i, sobretot, el nombre de nivells d'nidament i VM simultànies. Per a càrrega lleugera de laboratori és perfectament manejable, però per producció exigent no sol ser la millor opció.
Eines VMware específiques per a ESXi imbricat
Quan instal·les ESXi dins una màquina virtual, també és important comptar amb Eines de VMware per a aquest ESXi virtualitzat. Es tracta del conjunt de drivers i serveis que permet a l'hipervisor host comunicar-se millor amb la VM convidada i millorar-ne la gestió.
En el cas d'ESXi imbricat, VMware Tools proporciona funcionalitats com la visualització de la IP i l'hostname de l'ESXi virtual des del client vSphere, la possibilitat de apagar o reiniciar ordenadament l'ESXi imbricat des de la consola de gestió i l'execució de scripts quan canvia el vostre estat d'alimentació, a més de suport per a operacions dins de la VM a través de la Guest Operations API.
En versions antigues d'ESXi 5.x, calia instal·lar aquestes eines manualment mitjançant un paquet VIB. A partir de vSphere 6.0, les eines necessàries ja vénen integrades a ESXi, de manera que quan instal·les ESXi en una VM de manera estàndard, VMware Tools apareix directament com a presents i en execució, simplificant molt l'administració diària.
Xarxa i polítiques de seguretat en entorns imbricats VMware
El pla de xarxa és un dels punts que més maldecaps dóna en muntar un entorn ESXi imbricat. Per defecte, els switches virtuals d'ESXi no es van dissenyar pensant en hipervisors dins de VMs, així que cal ajustar certes polítiques de seguretat perquè les VMs imbricades puguin comunicar-se correctament amb l'exterior.
En un host ESXi físic que allotjarà hipervisors niats cal modificar el vSwitch (o el grup de ports corresponent) habilitant el manera promíscuapermetent canvis de direcció MAC i acceptant trames amb MAC d'origen falsificada (Forged Transmits). Si es deixen aquests paràmetres en el valor per defecte (Reject), el switch virtual descarta el trànsit que prové de les VM imbricades en no coincidir la MAC efectiva amb la de la NIC virtual de l'ESXi convidat.
Mode promiscu i el seu impacte
El mode promiscu és una política de seguretat que fa que una interfície de xarxa rebi totes les trames L2 que passen pel vSwitch, no només les adreçades a la seva pròpia MAC. Se sol utilitzar per a monitorització de xarxa, anàlisi de trànsit i, en el nostre cas, perquè l'hipervisor niat pugui veure el trànsit dels seus VMs internes.
En activar el mode promiscu en un vSwitch o en un port group, el comportament s'assembla més al d'un hub: es reenvia tot el trànsit a aquesta interfície. Això facilita que l'ESXi virtual aprengui i gestioni les MAC de les VMs imbricades, però a canvi redueix el rendiment de xarxa, cosa que es nota especialment si les càrregues són molt intensives en trànsit.
Canvis de MAC i transmissions falsificades
Per defecte, un vSwitch estàndard a ESXi no permet que una VM canvieu la vostra adreça MAC respecte a la configurada al fitxer VMX, com a mesura de seguretat davant d'atacs d'enverinament ARP i suplantació d'identitat. De la mateixa manera, es bloquegen les trames sortints el camp MAC d'origen de les quals no coincideix amb la direcció MAC efectiva de la VM, considerant-les transmissions falsificades (Forged Transmits).
En un escenari imbricat, les VMs internes solen tenir MAC diferents de la de l'ESXi convidat. Si no s'ajusten aquestes polítiques a Acceptar, el switch virtual de l'amfitrió físic considerarà que les trames que surten de l'ESXi virtual amb MAC diferents són sospitoses i les descartarà, trencant la connectivitat de les VMs imbricades amb la resta de la xarxa.
A partir de vSphere 6.7, els Distributed Virtual Switch (VDS) incorporen opcions de aprenentatge d'adreces MAC mitjançant l'opció macManagementPolicy, cosa que permet reduir la necessitat de tirar de la manera promiscu i oferir un comportament més semblant al d'un switch físic tradicional en entorns niats.
Passos clau per muntar un entorn ESXi imbricat
Si el portem a la pràctica, el desplegament típic d'un entorn ESXi imbricat sobre un host ESXi físic passa per una sèrie de passos relativament estàndard, encara que amb alguns matisos crítics perquè tot funcioni bé.
En primer lloc, es crea una màquina virtual que actuarà com a host ESXi. A l'assistent s'escull un nivell de compatibilitat de maquinari adequat (per exemple, ESXi 6.5 o posterior), se selecciona com a sistema operatiu convidat “VMware ESXi” i, a la part de maquinari, s'assignen almenys 2 vCPU, 8 GB de RAM o més i un disc virtual suficient (mínim 32 GB per a ESXi 7).
El punt clau és marcar l'opció de exposar virtualització assistida per maquinari al sistema operatiu convidat. Si no es fa, durant la instal·lació d'ESXi a la VM apareixerà un avís indicant que la virtualització per maquinari no està suportada o no està activada a la CPU, i no serà possible arrencar VMs imbricades dins aquest ESXi virtual.
Un cop creada la VM, es munta la imatge ISO d'instal·lació d'ESXi des d'un datastore i es procedeix a instal·lar l'hipervisor en aquesta màquina virtual com si fos un servidor físic: es formateja el disc, es configura la xarxa de gestió amb una IP i nom de host i es comprova que es pot accedir al Client d'amfitrió de VMware via navegador.
Emmagatzematge i datastors a ESXi imbricat
Amb ESXi 7.x, l'esquema de partició ha canviat davant de versions anteriors. En discs petits (per sota de 128 GB) es crea una partició VMFSL destinada a dades del propi sistema (coredump, eines, scratch, etc.) i potser no quedi espai per crear un datastore VMFS addicional on allotjar VMs imbricades.
Per això és molt habitual afegir un o diversos discos virtuals addicionals a la VM ESXi convidada, apagant primer la màquina, editant els ajustaments i creant nous discos amb aprovisionament fi (per exemple de 30 GB, 50 GB o més segons necessitats). Després, des del Host Client de l'ESXi imbricat es detecta aquest nou disc i es crea un datastore VMFS (normalment VMFS 6) per emmagatzemar les VMs internes.
Muntatge d'ISO i creació de VMs imbricades
Per instal·lar sistemes operatius a les VMs imbricades dins de l'ESXi convidat, es pot optar per dos enfocaments principals a l'hora de utilitzar les imatges ISO d'instal·lació:
D'una banda, pugeu les ISOs directament al datastore de l'ESXi imbricat i seleccioneu-les des d'aquí en crear les VMs internes. Aquest enfocament és simple però consumeix espai demmagatzematge dins del propi entorn imbricat. D'altra banda, muntar la ISO a la unitat de CD/DVD de la VM ESXi convidada des d'un datastore de l'amfitrió físic i, dins de l'ESXi virtual, configurar la unitat de CD/DVD de l'VM imbricada com a “Dispositiu host”, aprofitant el passthrough.
Aquest segon mètode sol ser preferible perquè permet centralitzar les ISOs en un únic datastore al host físic, estalvia espai al datastore de l'ESXi convidat i proporciona un lleuger millor rendiment daccés a mitjans. Un cop muntada la ISO, el procés de creació de la VM imbricada és similar al de qualsevol altra VM: es defineix nom, tipus de sistema operatiu convidat (Windows, Linux, etc.), recursos (CPU, RAM, disc) i s'arrenca la instal·lació.
Després d'instal·lar el sistema operatiu a la VM imbricada, és crucial afegir Eines de VMware dins daquesta VM per optimitzar rendiment de xarxa, vídeo i operacions dapagada i reinici. Depenent de la distribució d'ESXi utilitzada, les imatges ISO de les tools poden venir integrades o cal descarregar-les des del portal de VMware.
Clonat i replicació de hosts ESXi imbricats
Quan s'ha configurat un ESXi imbricat amb la versió desitjada, xarxa, datastore i alguna VM interna, el normal és voler clonar aquesta VM per disposar de diversos hosts ESXi virtuals idèntics, per exemple per formar un clúster de laboratori amb vCenter.
Abans de començar a clonar, convé fer alguns ajustaments dins de l'ESXi convidat original: habilitar que el VMkernel segueixi la MAC del maquinari virtual amb el paràmetre adequat a ESXCLI, i eliminar el UUID del sistema del fitxer /etc/vmware/esx.conf perquè, en arrencar el clon, es generi un nou identificador únic. Després de clonar, en encendre cada ESXi virtual caldrà canviar-li nom de host, IPs i qualsevol altra configuració que hagi de ser diferent.
Virtualització imbricada a Azure Lab Services (Hyper-V)
Azure Lab Services ofereix una manera molt còmoda de lliurar laboratoris complets a estudiants o usuaris interns mitjançant màquines virtuals de laboratori. Aquí la virtualització imbricada es recolza en Hyper-V com a hipervisor dins de la VM de plantilla. La idea és que des d'aquesta VM de plantilla s'habiliten les característiques de Hyper-V, es creen les VMs imbricades necessàries i, en publicar el laboratori, cada usuari rep la seva pròpia còpia d'aquesta plantilla amb tot ja muntat.
En aquest escenari, la virtualització imbricada només està disponible a VMs de laboratori basades en Windows, encara que dins Hyper-V es poden executar tant convidats Windows com Linux. Si el sistema operatiu de la plantilla és Windows Server, sol ser necessari configurar una xarxa NAT dins de la VM de laboratori perquè les VMs imbricades puguin comunicar-se entre si i sortir a Internet.
En configurar aquests laboratoris, cal tenir en compte diversos aspectes pràctics: si es creen comptes d'usuari sense privilegis d'administrador, és imprescindible afegir-los al grup “Administradors de Hyper-V" perquè puguin iniciar i aturar VMs. A més, les VHDX de les VMs imbricades han d'estar en rutes accessibles per a aquest usuari i, per estalviar espai en disc, es recomana utilitzar el format VHDX dinàmic en lloc de discos plans grans.
Quant a la capacitat de còmput, les mides de VM pensades per a virtualització imbricada en Azure (per exemple, Standard_D4s_v4 i Standard_D8s_v4) es basen en processadors Intel Xeon Platinum de tercera generació. Atès que en aturar i encendre VMs a Azure el processador subjacent pot variar dins de la mateixa família, s'aconsella habilitar el mode de compatibilitat de processador a les VMs imbricades de Hyper-V per minimitzar problemes de migració entre diferents hosts físics.
Un altre punt crític és configurar les VMs de Hyper-V perquè s'apaguin de manera ordenada quan la VM de laboratori s'apaga, normalment usant el cmdlet Set-VM per definir lacció de detenció automàtica i evitar corrupció de dades. I, com sempre, cal planificar bé memòria i nombre de vCPU per VM imbricada perquè el rendiment general sigui acceptable.
Hi ha també limitacions importants: no totes les mides de VM d'Azure suporten virtualització imbricada, les VMs imbricades no tenen accés directe a recursos d'Azure com els DNS de la VNet i només se suporta Hyper-V com a tecnologia de virtualització, quedant fora del suport altres solucions que requereixin extensions de maquinari com KVM o VMware dins aquesta capa.
Virtualització imbricada a AWS EC2
Fins fa poc, si volies virtualització imbricada a AWS estaves pràcticament obligat a anar-te'n a instàncies bar metall, amb accés directe al maquinari però a un cost molt superior i amb menys flexibilitat. L'anunci de suport oficial de virtualització imbricada en instàncies EC2 virtuals estàndard ha canviat el panorama del tot.
L'actualització, reflectida per exemple en versions recents del SDK d'AWS per a Go, habilita la possibilitat d'executar hipervisors convidats i VMs imbricades dins instàncies EC2 que no són bar metall, sempre que pertanyin a famílies compatibles (normalment instàncies amb CPU Intel VT-x o AMD-V de les sèries M, C, R, etc.). Això obre la porta al fet que startups i equips de desenvolupament munten laboratoris complexos, plataformes de CI/CD avançades o entorns d'orquestració de VMs sense sortir del pressupost.
En aquest context, els casos dús més freqüents inclouen pipelins de testing que reprodueixen arquitectures de producció completes (diferents sistemes operatius, capes de xarxa, tallafocs, etc.), plataformes de formació tècnica que donen a cada alumne un mini CPD dins una EC2 o el desenvolupament d'eines cloud-native que necessiten gestionar VMs com a part de la seva funcionalitat (per exemple, solucions de backup, seguretat o automatització).
Des del punt de vista econòmic, el suport de virtualització imbricada a EC2 estàndard pot suposar reduccions importants de cost davant de bar metall, de l'ordre del 60-70 % en molts escenaris de laboratori. A més, es guanya a elasticitat: es poden combinar instàncies sota demanda amb Spot, escalar cap amunt o avall segons les necessitats de prova i aprovisionar entorns en segons davant dels temps habituals de bar metall.
Això no obstant, també aquí cal tenir present que cada capa de virtualització afegeix overhead. Les VMs imbricades a EC2 tendeixen a patir una penalització de rendiment d'entre un 10-20% davant d'una VM no imbricada equivalent, per la qual cosa el seu lloc natural són els entorns de desenvolupament, proves, PoC i labs, mentre que per a producció crítica convé avaluar amb calma si compensa aquesta pèrdua de rendiment.
Per a l'ecosistema de startups a Llatinoamèrica i altres mercats sensibles al cost del núvol, aquesta possibilitat és especialment rellevant: empreses de ciberseguretat poden muntar laboratoris de malware multicapes al núvol sense pagar bar metall, equips de DevOps poden replicar topologies de producció en staging amb un cost contingut i proveïdors SaaS poden preparar donem complexes per a clients amb arquitectures reals sense desplegar.
Finalment, la integració amb l'SDK d'AWS per a Go i altres SDKs permet automatitzar la gestió d'aquests entorns imbricats, incloent-hi la verificació de compatibilitat d'instàncies, l'activació de capacitats de virtualització i l'orquestració del cicle de vida de les VM dins les EC2 a través de pipelins de La infraestructura com a codi.
La virtualització imbricada s'ha consolidat com una eina molt versàtil per laboratoriitzar, provar i ensenyar infraestructures complexes sense necessitat de grans inversions en maquinari. Des d'escenaris de formació amb ESXi niat i laboratoris Hyper-V a Azure fins a plataformes de testing avançades a AWS EC2, el patró es repeteix: un ús intel·ligent d'aquesta tecnologia permet guanyar flexibilitat, reduir costos i accelerar el cicle de proves, sempre que se'n respectin els límits en rendiment, suport i llicenciament i es planifiquin ben xarxes, seguretat.
