Tres niveles de (in) dependencia de Multicast en VXLAN

Continuando  con la temática del protocolo VXLAN, en ésta ocasión trataré lo que ha solido citarse como la principal barrera para su adopción: el requisito de Multicast y la carga operacional que implica su administración y la complejidad de la implementación.

Para VMware y Cisco, dos de los principales impulsores de VXLAN no ha sido desconocido éste tema y han hecho diferentes actualizaciones a la línea de productos para ofrecer tunelamiento VXLAN en diferentes sabores con respecto al requisito de multicast. He identificado tres variantes hasta ahora, que pasaré a describir:

1. vCloud Networking & Security: barato como un cachorrito

Si una organización tiene acceso a vCloud Suite en edición Standard, ya tiene en su bolsillo el licenciamiento para vCNS. Con éste producto es posible crear una completa implementación de VXLAN que incluso pueda ser consumida como redes organizacionales por tenants de vCloud Director. Sin embargo aquí es completamente necesaria la presencia de Multicast en la red física, aspecto que se debe tener en cuenta a la hora de evaluar la solución y su costo operacional.

2. Cisco Nexus 1000V: viviendo al filo del RFC

A comienzos de 2013, Cisco anunció la implementación de al menos dos nuevos mecanismos en el switch Cisco Nexus 1000V que harían posible implementar VXLAN sin el requisitio de Multicast:

a. Nexus 1000V puede crear múltiples réplicas de cada paquete y enviar cada réplica a un VTEP en la red usando sólamente Unicast. Esta opción claramente dista de ser escalable pues en un entorno masivo se producirá algo similar a una “tormenta” Unicast.

b. Hacer uso del VSM (Virtual Supervisor Module) que hace parte de la implementación de Nexus 1000V para que actúe efectivamente como un plano de control distribuyendo la información de direcciones MAC de máquinas virtuales a los VEM (Virtual Ethernet Module) presentes en la red. Esto, aunque efectivo, contradice lo que establece el RFC de VXLAN con respecto a que el protocolo no debe depender de un plano de control ni entidad alguna de administración centralizada. Cisco lo sabe pero, el cliente siempre tiene la razón 😉

VMware NSX: el auge del plano de control distribuido

Durante el VMworld US 2014, el Dr. Bruce Davie compartió conceptos avanzados y el futuro de NSX en la sesión NET1674.

Allí detalló el uso de VXLAN como protocolo de tunelamiento para NSX y, con respecto a lo que nos ocupa, la manera en que NSX habilta el uso de OVSDB (Open vSwitch Database) como el protocolo a través del cual distribuye la tabla de direcciones MAC de las Máquinas virtuales a lo largo de los switches físicos que soporten el protocolo y que hagan parte de la infraestructura sobre la cual tiene alcance el NSX Controller.

OVSDB es un protocolo de administración cliente-servidor que busca dar acceso programático a la base de datos OVSDB que contiene la información de cómo opera la conmutación del Open vSwitch con datos como, por ejemplo, la tabla de direcciones MAC de las MVs del entorno.

El mecanismo principal con el cual NSX crea redes virtuales (llámense segmentos, virtual wires, túneles,etc) es VXLAN que en este caso, y dado que la tarea de distribución y actualización de direcciones MAC la asume el protocolo OVSDB, solo requiere la presencia del protocolo IP como transporte o underlay eliminando así el requerimiento de multicast en la red física.

Sin embargo, no todas las organizaciones van a poder abrazar éste enfoque pues surge un nuevo requerimiento quizá más etéreo que el de multicast: switches físicos que soporten OVSDB. Actualmente existe oferta al respecto por parte de fabricantes como Juniper o Arista y aparentemente Open vSwitch ha llegado para quedarse, que es lo que se desprende de su adopción no solo por parte de los grandes fabricantes sino de la iniciativa OpenDayLight de Linux Foundation, que busca establecer un marco de referencia para el avance de SDN como un programa abierto e interoperable (el mundo empieza a reaccionar contra la proliferación del vendor lock-in, o eso esperaría).

Saludos!

Advertisements

VXLAN: conceptos, funcionamiento e implementación (2/2)

Ha pasado un buen tiempo desde que publiqué la primera parte de esta entrada y bueno, ya es hora de continuar.

Entre más aprendo sobre el tema, más difícil se hace comprimir todo en un post. En ésta ocasión cubriré la implementación de VXLAN en un entorno VMware vSphere y algunos de los siguientes temas serán tratados en entradas posteriores:

A. VXLAN y el requisito de multicast: tres niveles diferentes de (in)dependencia de Multicast

B. vCNS Edge como un eficiente y costo-efectivo gateway VXLAN

C. Un día en la vida de una trama VXLAN

Sin más, entremos en materia.

Configuración de VXLAN en un entorno vSphere

Para preparar un clúster para VXLAN se deben cumplir los siguientes prerrequisitos:

A. Una VLAN aprovisionada en la red física. Esta se usará para la comunicación entre VTEPs

B.Todos los host del clúster deben estar unidos a un distributed Virtual Switch

C. La red física debe soportar el paso de paquetes con tamaño mínimo de 1600 bytes sin requerir fragmentación

El procedimiento se lleva a cabo desde la interfaz de vCNS Manager con los siguientes pasos:

1. Dirigirse a Datacenters > Network Virtualization > Preparation

2. Dar clic en Edit…

vxlan21

3. Seleccionar un cluster y asociarlo con el respective dVS y VLAN ID que se haya obtenido previamente:

vxlan22

4. En la siguiente pantalla, seleccionar la política de Teaming de los uplinks o interfaces de red en el dVS. Está soportado Etherchannel, Link Aggregation Group o Static Failover, éste último es el que selecciono en el laboratorio pues no cuento con una implementación que soporte los demás métodos en la red física.

vxlan23

El resultado de los procesos anteriores luciría algo mejor que lo siguiente:

vxlan24

La solución al inconveniente anterior en gran parte, consiste en asignar las IPs a las vmknic creadas por VXLAN en cada host ó configurar un DHCP server en la VLAN que usuarán los VTEP.

Ahora se configurarán los rangos del grupo Multicas tasi como de los VNI que se usarán en la implementación. Para ello los pasos continúan de ésta manera:

5. Dar clic en “Segment ID” > “Edit…”

vxlan25

Es necesario que se configure la misma cantidad de VNI o “Segment IDs” que de IPs multicast en el grupo, cada segmento VXLAN llevará asociada una IP del grupo Multicast.

Los pasos siguientes aplican si el entorno de implementación no es administrador por vCloud Director (en caso que lo fuere, en éste punto el Provider vDC ya estaría listo para hacer uso de redes VXLAN). El post de @punchingclouds brinda mayores luces al respecto.

6. Dirigirse al link de “Network scopes” y crear un scope con el clúster previamente preparado:

vxlan267. En este punto se puede iniciar con la creación de redes, segmentos o VXLAN virtual wires (los nombres son equivalentes) que en vCenter se verán como portgroups del dVS a los cuales se pueden conectar máquinas virtuales de la manera tradicional. La creación de redes se lleva a cabo en el link “Networks”:

vxlan27

8. Finalmente en la pestaña “Edges” se puede aprovisionar una instancia de vCNS Edge que sirva como Gateway para las MVs conectadas a un VXLAN virtual wire y que puedan salir al “mundo exterior” para comunicarse con servicios en Internet o con equipos físicos en VLANs tradicionales.

Profundizaré en ello en un post posterior.

Gracias!

VXLAN: conceptos, funcionamiento e implementación (1/2)

Por estos días VXLAN parece cada vez más estar en boca de todos los que siguen el mercado de la virtualización de redes. Por un lado el Internet Engineering Task Force  (IETF) aprobó hace cerca de tres semanas pasar la tecnología VXLAN del estado borrador o draft a ser un protocolo reconocido por un RFC, lo que provee una base más sólida para su consolidación.

Por otra parte, el creciente auge de la suite de SDN de VMware: NSX ha llevado a partners como Juniper Networks, Arista Networks, entre otros; a ofrecer dispositivos capaces de integrarse con NSX usando como protocolo overlay a VXLAN, por sus capacidades y su flexibilidad en cuanto a requerimientos de infraestructura.

Esta es la motivación para ésta serie de 2 entradas que, dedos cruzados, se convertirán en más publicaciones sobre el avance de NSX como plataforma para SDN.

Entremos en materia.

VXLAN: ¿qué es?

Es un protocolo de superposición de redes (overlay networks) definido por el RFC 7348 que el IETF aprobó hace algunas semanas, y que hace uso del protocolo IP como la base sobre la cual implementa segmentos LAN similares a las VLAN, pero con un esquema diferente de encapsulación que eleva considerablemente el número de redes que es posible transportar, a la vez que aprovecha la ubicuidad y alcance geográfico de IP para agregar flexibilidad y extensibilidad a la implementación de redes L2.

¿Por qué VXLAN?

Uno de los desafíos a los que se enfrentan actualmente los arquitectos de red en el centro de datos moderno, consiste en las limitaciones del omnipresente Spanning Tree Protocol que es casi el mecanismo de-facto que las organizaciones implementan para evitar los loops en capa 2, sin embargo STP inevitablemente deja múltiples links sin uso por lo que en la escala masiva de los datacenter para la nube, esto significa un enorme costo de inversión en puertos que finalmente no se pueden usar.

Por otro lado y a diferencia de protocolos de capa 3 como IP, las redes de capa 2 tienen poca movilidad fuera del datacenter y ciertamente la carga operacional para extenderlos o activar dominios capa 2 en un sitio alterno reduce las opciones para la implementación efectiva de requerimientos como Disaster Recovery de cargas de trabajo virtualizadas hacia un datacenter alterno, manteniendo todas las propiedades de conectividad del sitio principal de forma automatizada.

Por si fuera poco, el mecanismo tradicional de aislamiento de red en capa 2 que son las VLANs, definen el VLAN ID como un atributo numérico de 12 bits, limitando el número de redes posibles a 4094. Por muchos años pareció lejana la posibilidad de alcanzar este límite, pero en el datacenter actual con múltiples tenants consumiendo servicios de conectividad y a la vez creando sus propias redes y servicios, éste límite rápidamente se ha convertido en un obstáculo a la vista para la escalabilidad del centro de datos.

Figura 1. VXLAN agrega un ID de 24 bits antes de transportar el paquete por la red IP. En el destino se lleva a cabo la desencapsulación.

VXLAN surge, pues, como una propuesta conjunta de fabricantes como VMware, Cisco, RedHat, Arista, entre otros; para convertirse en el mecanismo que efectivamente extienda la funcionalidad de las VLAN tanto en escala como en alcance. En escala pues su identificador de red, definido como VNI (VXLAN Network Identifier o Segment ID) es de 24 bits de longitud con lo que se alcanza un máximo de 16 millones de redes que pueden converger en una misma implementación VXLAN.

La extensión del alcance de las VLAN la logra VXLAN al valerse del protocolo IP, tan ampliamente implementado y con diversos mecanismos de movilidad, como medio de transporte para las redes L2 que viajan encapsuladas. Es por esto que a VXLAN también se le incluye en la categoría de tecnologías o protocolos de tunelamiento.

Componentes

La siguiente es una lista de componentes necesarios para una implementación de VLXAN en un entorno VMware:

A. VTEP (VXLAN Tunnel Endpoint): es la entidad que origina y/o termina túneles VXLAN. Se implementa en cada host ESXi y se compone a su vez de los siguientes módulos:

  1. Módulo vmkernel: hace parte del distributed Virtual Switch (dVS) y se instala como un vib en el hipervisor. Actúa como plano de datos al mantener las tablas de enrutamiento así como se encarga de la encapsulación y desencapsulación de paquetes
  2. Adaptador vmknic: se instala uno en cada host cuando el clúster se prepara para VXLAN. Se encarga de transportar el tráfico de control de VXLAN. Actúa en parte como control plane al alimentar la información de rutas visible en la red IP y alimentarla a la tabla mantenida por el plano de datos en el módulo vmkernel de VXLAN.
  3. Port group VXLAN: incluye la información tradicional de los portgroups dVS de vSphere, y se crea un portgroup automáticamente por cada red ó segmento VXLAN implementado.

B. vCNS Manager: este es el verdadero plano de administración o management plane, pues ofrece la gestión centralizada de los segmentos VXLAN así como de las interfaces vmknic y los clústers en cuyos hosts se ha instalado el VTEP. No administra el tráfico como tal, pero si mantiene el estado actual de la implementación VXLAN dentro de un vCenter.

C. vCNS Gateway: es un appliance que ofrece servicios de conectividad y seguridad avanzados y que es implementado y administrado por vCNS Manager. Se trata de un componente realmente especial dentro de la arquitectura de VMware VXLAN pues tiene la capacidad de dar salida a las MVs conectadas a los segmentos VXLAN hacia el “mundo exterior” con funcionalidades de NAT, Firewall perimetral, DHCP, DNS Relay, VPN, entre otras y es una alternativa para la eterna pregunta acerca de cómo terminar segmentos o túneles VXLAN en dispositivos físicos. Esto será materia de otra entrada, pero quedémonos con que el vCNS Gateway es efectivamente el puente entre redes VXLAN y servicios externos de conectividad.

vxlan_componentes
Figura 2. Arquitectura simplificada de implementación de VMware VXLAN

En la próxima entrada veremos los mecanismos bajo los cuales opera VXLAN así como los pasos prácticos para la implementación del protocolo en un entorno VMware.

Saludos!

VCAP-CIA Objetivo 1.1 o el misterio del logging de vCloud Director

Contar con los mecanismos para indagar en el pasado y rastrear eventos ó comportamientos de un sistema computacional es uno de los requisitos principales para contar con una infraestructura tecnológica administrable, escalable y que facilite el cumplimiento de regulaciones en el ámbito de seguridad de la información.

En el caso de VMware vCloud Director y su componente de seguridad y conectividad vCloud Networking & Security existen diferentes métodos por los cuales se pueden recolectar registros de actividad así como niveles de detalle de esos registros ó logs.

Dominar éste tema es el objetivo 1.1 del examen de certificación VMware Certified Advanced Professional – Cloud Infrastructure Administration, mejor conocido como VCAP-CIA; y lo trataremos con detalle en éste post.

Logging en vCloud Director
vCloud recolecta dos tipos de log: audit log que es el registro de actividades en el espacio de usuario así como eventos de los servicios que componen a vCloud.  Entre otros, estos eventos incluyen inicios de sesión, operaciones sobre vApps, orgvDCs y estado del servicio. El otro tipo de log es el diagnostic log que reporta el estado de los diferentes componentes del servicio vCloud Director y tiene varios niveles de detalle, cuya selección debe obedecer al caso de uso que se busque evaluar (clic para ver más sobre los niveles de logging). En todo caso, los audit logs por defecto se almacenan en la base de datos por 90 días y al ingresar la IP o nombre de un servidor syslog en el menú de instalación de vCloud,  se está dando la instrucción de re dirigir el audit log a ese servidor syslog en que se podrá manejar una retención mayor.

¿Qué es log4j y que papel cumple?

Es un interceptor de logs para aplicaciones Java y se denomina así por no insertar mínimas declaraciones de logging en las aplicaciones (en éste caso vCloud Director) e interceptar el contenido para alojarlo en ubicación externa (que desde el punto de vista de la aplicación, puede ser el almacenamiento local).

Con respecto a vCloud Director, cumple la función de procesar los diagnostic logs y habilitar el envío de éstos a ubicación centralizada (syslog). También administra los diferentes niveles de detalle que los diagnostic logs pueden registrar.

Logging en vShield Manager

vShield Manager es el plano de control que lleva a cabo la implementación de los appliance sobre los que corren módulos como vShield Edge, vShield Edge o Endpoint. Sin embargo vSM no interactúa directamente con el tráfico de red o las reglas de seguridad como si lo hacen los módulos mencionados, sino que mantiene el inventario de la ubicación, propiedad (a qué tenant pertenece) y características de los módulos desplegados en el entorno.

Quizá atribuìdo a esa función de mera supervisión que cumple vSM, es que la única opción de logging corresponde a un sólo servidor syslog a donde vSM enviará los logs tipo audit:

Syslog para vShield Manager

Métodos de captura de logs

 

1. Local

Caso de uso: retención de audit logs por máximo 90 días, espacio NFS para almacenamiento de diagnostic logs.

Este es el método de recolección de log que por defecto usa vCloud Director en caso que no se especifique ningún servidor syslog. En éste caso los logs audit y diagnostic se almacenan en $VCLUD_HOME/logs en el almacenamiento de cada vCloud cell.

Se pueden modificar las siguientes opciones para los diagnostic logs alojados localmente:

  • Nivel de detalle (ver VMware KB # 1026815)

 

¿Cómo hacerlo?

A. Iniciar sesión en la celda vCloud

B. Editar el archivo $VCLOUD_HOME/etc/log4j.properties:

blog51

C.  Siguiendo la KB 1026815 ubicar las líneas

# Root logger log4j.rootLogger=ERROR, vcloud.system.debug, vcloud.system.info

y

log4j.appender.vcloud.system.debug.threshold=DEBUG

Una vez se haya elegido un nivel de logging, se debe editar en éstas dos líneas fijándolas en el mismo nivel de detalle. Por ejemplo, si eligiera el nivel “TRACE”, que trae el mayor detalle, las líneas finalmente se verían así:

Root logger log4j.rootLogger=TRACE, vcloud.system.debug, vcloud.system.info

log4j.appender.vcloud.system.debug.threshold=TRACE

D. Guardar los cambios y reiniciar el servicio vCloud Director
Nivel de retención y tamaño de archivos de log

 

¿Cómo hacerlo?

A. Editar el archivo $VCLOUD_HOME/etc/log4j.properties

B. Editar las líneas log4j.appender.vcloud.system.debug.MaxFileSize y log4j.appender.vcloud.system.debug.MaxBackupIndex fijando el tamaño máximo de los archivos de log y el número máximo de archivos a retener, respectivamente.

C. Guardar cambios en el archivo

D. No se requiere reiniciar el servicio vCloud Director

 

2. Local redireccionado

Consiste en usar el servicio rsyslog corriendo en el sistema operativo (RHEL o CentOS) en el que corre vCloud Director, para atrapar los logs que vienen de la aplicación y redirigirlos a uno o más servidores syslog remotos.  Debido a que syslog es un protocolo UDP y que por tanto carece de métodos de retransmisión en caso de pérdida de paquetes, es recomendable tener múltiples servidores syslog habilitados para captura de logs remotos.

¿Cómo hacerlo?

A. Instalar el paquete “rsyslog” en la celda vCloud (en caso que no esté ya instalado)

yum install rsyslog -y

B. Modificar el archivo $VCLOUD_HOME/etc/global.properties editando la línea

audit.syslog.host = 127.0.0.1

En éste punto, si solo se requiere redireccionar audit logs se procedería al paso D, si se busca redirigir también diagnostic logs, el procedimiento continúa en el punto C:

C. Editar el archivo $VCLOUD_HOME/etc/log4j.properties y agregar las líneas que indica la VMware KB # 2004564 especificando el servidor syslog local en la línea:

log4j.appender.vcloud.system.syslog.syslogHost=127.0.0.1

Los siguientes pasos consisten en habilitar a rsyslog para que reciba logs de la aplicación y los envíe a syslog remotos:

D.  Editar el archivo /etc/rsyslog.conf descomentando las siguientes líneas:

$ModLoad Imudp

$UDPServerRun 514

E. En el extremo inferior de ése mismo archivo, agregar la dirección IP de los syslog a los que se enviarán los logs:

*.*  @@server1

*.*  @@server2

..

F.  Guardar cambios en el archivo y reiniciar el servicio rsyslog:

service rsyslog restart

En éste punto ya empezarán a recogerse logs en el servidor o servidores syslog que se haya especificado.
3. Directamente centralizado

Finalmente, éste método provee envío directo de audit y diagnostic logs a un y solo un servidor syslog remoto que puede ser TCP o UDP.

¿Cómo hacerlo?

Envío de audit logs:

  1.  Modificar el archivo $VCLOUD_HOME/etc/global.properties editando la línea

audit.syslog.host = IP_SYSLOG_REMOTO

para que refleje la IP del syslog server.

2. Reiniciar el servicio vmware-vcd

Envío de diagnostic logs:

A. Editar el archivo $VCLOUD_HOME/etc/log4j.properties y agregar las líneas que indica la VMware KB # 2004564 especificando el servidor syslog local en la línea:

log4j.appender.vcloud.system.syslog.syslogHost=IP_SYSLOG_REMOTO

B.  Reiniciar el servicio vmware-vcd

Otros recursos

Recomendado Sesión 192 del Podcast de Packetpushers.net : “Logging design and best practices

http://packetpushers.net/show-192-logging-design-best-practices/

PDTA: Sé que este es un post largo y puede resultar confuso el tema, si se generan dudas no dude en escribirlas en los comentarios; pronto estarán publicados los slides y la grabación del podcast vBrownBag LATAM en el que traté este tema con un lab en vivo.

Saludos!

 

 

Problema con script de instalación automatizada de componentes para vCAC IaaS : rápida solución

VMware vCloud Automation Center IaaS es el motor de automatización para el aprovisionamiento de Infraestructura como Servicio (por defecto para VMware vSphere);  extensible a otras plataformas de virtualización.

La instalación de éste módulo requiere una considerable cantidad de prerequisitos de software cuya habilitación manual no sólo es tediosa sino una práctica anacrónica en éstos tiempos.

El buen Brian Graff (@vTagion) ha escrito y publicado un script muy útil que automatiza la habilitación de features/roles/reglas/etc que requiere vCAC IaaS para una exitosa instalación.

Sin embargo,  en algunas ocasiones al tratar de instalar en Windows Server 2012, la ejecución del script puede fallar en completarse arrojando el siguiente mensaje de error:

Add-WindowsFeature :  The source files could not be downloaded

La solución consiste en editar el script (archivo .ps1) y buscar las líneas que contengan el texto:

“Add-WindowsFeature”

y agregar al final el parámetro:

-source:e:\sources\sxs

Donde E: corresponde a la unidad en que esté montado el medio de instalación de Windows Server 2012.

Luego de agregar ése parámetro en cada lugar del script donde se invoque Add-WindowsFeature y guardar los cambios, la ejecución del script se completa con éxito.

Antes de ejecutar el script:

blog3_1

Ejecución del script:

blog3_2Re verificación de prerequisitos desde el instalador:

blog3_3Saludos!

Clúster de ESXi 5.5 no publica Storage Policies a vCloud Director 5.5.1

Para habilitar un aprovisionamiento automatizado y que cumpla con los Acuerdos de Nivel de Servicio en términos de ubicación de máquinas virtuales para un entorno administrado por VMware vCloud Director, se deben cumplir los siguientes pre-requisitos:

1. Licenciamiento vSphere Enterprise Plus

2. Servicio VMware Profile Driven Storage ejecutándose en el vCenter Server

3. Clústers con Storage Policies habilitado y licenciados

4. Storage capabilities creados y asignados a datastores

5. Storage profiles creados y con storage capabilities asignadas

Sin embargo con todas éstas etapas completadas con éxito y en un entorno que ha sido migrado de vSphere+vCloud 5.1 a 5.5 los pasos anteriores pueden no ser suficientes desde el punto de vista de vCloud Director 5.5

En vSphere 5.5 los Storage capabilities definidos por usuario se consideran legacy para dar paso al auge definitivo de las Storage Policies definidas ya sea por Tags de vCenter o por capacidades de almacenamiento descubiertas a través de VAAI. Lo anterior por supuesto tiene mucho sentido toda vez que la capa de storage de vSphere se centra cada vez más en los metadatos para sentar las bases del almacenamiento de objetos que es VMware VSAN.

vCloud Director 5.5 tiene compatibilidad reversa con los perfiles de almacenamiento definidos por usuario que vienen de vSphere 5 o superiores. Sin embargo para nuevos clúster ESXi (o Provider Virtual Datacenters en la jerga de vCloud) los perfiles (o Directivas) deben crearse siguiendo ésta secuencia:

1. Crear una nueva categoría de Tags en vSphere Web Client, que sea sólo aplicable a Datastores o Datastore Clústers:

Creación de una nueva categoría en vSphere Web Client

Creación de una nueva categoría en vSphere Web Client

Debido a que un datastore (objeto) sólo opera con unas prestaciones determinadas a la vez,  se selecciona una cardinalidad de una sola etiqueta por objeto.

2. Crear una etiqueta por cada tipo de almacenamiento presente en un entorno sin acceso a descubrimiento de capacidades por VAAI. Asociar esas etiquetas a la categoría previamente creada:

Etiquetas

3. Asignar las etiquetas a cada datastore (ya sea manualmente o mejor aún: usando PowerCLI :

Asignar etiqueta a datastore

4. Crear una nueva Storage Policy (o editar un Storage Profile existente) para tomar como Rule Set el Tag recién creado:

Nueva Storage Policy

blog2_5blog2_6Al finalizar el asistente se listarán los datastores a los que se haya asignado la etiqueta:

blog2_7

5. Dirigirse a vCloud Director > Gestionar y Supervisar > vCenters. Dar clic derecho sobre el vCenter sobre el que se hayan asigando las nuevas Storage Policies y seleccionar “Actualizar directivas de almacenamiento”:

blog2_8

6. Dirigirse al Provider vDC que corresponde al clúster en que se configuraron las Storage Policies y seleccionar la pestaña “Directivas de Almacenamiento”, allí se agregarán las directivas recientemente creadas:

blog2_9