diff --git a/docs/udelartex/anexo/anexoQueens.tex b/docs/udelartex/anexo/anexoQueens.tex
index a1f0d2a33fdcdd6f2716c2a1a8ec646e00887008..44b216c8294698eb2b33b70bf1c0e046975a3871 100644
--- a/docs/udelartex/anexo/anexoQueens.tex
+++ b/docs/udelartex/anexo/anexoQueens.tex
@@ -1,25 +1,5 @@
 \chapter{InstalaciÃ³n versiÃ³n Queens}\label{anexoQueens}
-Queens es la dÃ©cimo sÃ©ptima versiÃ³n liberada por OpenStack. La misma fue publicada el 28 de febrero del 2018. Junto a Pike y Ocata (ambas anteriores) son las versiones actuales en estado de mantenimiento extendido para utilizar en ambientes de producciÃ³n.
-
-\section{DiseÃ±o de arquitectura}
-El diagrama de la figura \ref{diseÃ±o-arquitectura} presenta la arquitectura diseÃ±ada para la instalaciÃ³n de OpenStack Ansible. Al tratarse de un ambiente meramente de prueba, sÃ³lo se cuenta con un nodo de cada tipo definido previamente. En el mismo se puede apreciar que no se han utilizado VLANs ni bonds en las interfaces de los servidores, sino que se han agregado tantas interfaces fÃsicas como fueran necesarias. Se detallan tambiÃ©n las numeraciones IP a ser utilizadas en cada una de las redes necesarias y las asignaciones a los diferentes bridges de cada uno de los nodos. Cabe mencionar que la IP pÃºblica del balanceador de carga pertenece a la subred en la que se encuentra el servidor fÃsico sobre el cual se virtualizan todos los nodos, con el fin de tener acceso externo a la plataforma.
-
-\begin{figure}[H]
-	\centering
-	\includegraphics[width=1.0\columnwidth]{chap4/dis-arquitectura}
-	\caption{Arquitectura diseÃ±ada.}
-	\label{diseÃ±o-arquitectura}
-\end{figure}
-
-En la figura \ref{neutron3} se muestra la disposiciÃ³n de los componentes de red en la arquitectura utilizada en donde el nodo de control y red se colapsaron a uno solo.
-
-\begin{figure}[!h]
-	\centering
-	\includegraphics[width=0.6\columnwidth]{chap4/neutron3}
-	\caption{DisposiciÃ³n de componentes en Neutron. ExtraÃda de \cite{openstack-networking-book-4}.}
-	\label{neutron3}
-\end{figure}
-
+Queens es la dÃ©cimo sÃ©ptima versiÃ³n liberada por OpenStack. La misma fue publicada el 28 de febrero del 2018. Junto a Pike y Ocata (ambas anteriores) son las versiones actuales en estado de mantenimiento extendido para utilizar en ambientes de producciÃ³n. La arquitectura utilizada para este escenario es la detallada en la secciÃ³n \ref{sec:arquitectura-desarrollo}.
 % ------------------------------------------------------
 
 \section{PreparaciÃ³n de nodos}
diff --git a/docs/udelartex/anexo/anexoStein.tex b/docs/udelartex/anexo/anexoStein.tex
index f9389131c5b7fd6b00503b47e079b9083f29b15f..953903a256450bbd9e76d59c711f3eaae3fd908e 100644
--- a/docs/udelartex/anexo/anexoStein.tex
+++ b/docs/udelartex/anexo/anexoStein.tex
@@ -1,21 +1,7 @@
 \chapter{InstalaciÃ³n versiÃ³n Stein}\label{anexoStein}
 Stein es la dÃ©cimo novena versiÃ³n liberada por OpenStack. La misma fue publicada el 10 de abril del 2019. Junto a Train, liberada el 16 de octubre del 2019, son las versiones mÃ¡s recientes en estado estable para utilizar en ambientes de producciÃ³n.
 
-\section{DiseÃ±o de arquitectura}
-La arquitectura planteada para instalar OpenStack en su versiÃ³n Stein se muestra en la figura \ref{fig:stein:arquitectura} (ver en ApÃ©ndice \ref{apendice:imagenes} figura \ref{fig:stein:arquitectura:anexo}). Con esta arquitectura se intenta aproximar una instalaciÃ³n para utilizar en un ambiente de producciÃ³n, contando con varios nodos de almacenamiento y cÃ³mputo. A diferencia de la arquitectura empleada para la versiÃ³n Queens se utilizan VLANs para aislar el trÃ¡fico de datos de las redes tenant tipo VLAN o VXLAN sobre la interfaz eth2 de los nodos de infraestructura y cÃ³mputo. Para el trÃ¡fico de management y storage se dedican interfaces exclusivas en cada uno de los nodos del Datacenter. Al bridge br-mgmt ubicado en el servidor fÃsico renata y conectado a la interfaz fÃsica eno2 se conectan directamente la interfaz pÃºblica del balanceador de carga (nodo haproxy 01) por la cual llegarÃ¡n los pedidos de las redes externas y el Linux Bridge asociado al router en la red 10.0.40.0/24. En este Ãºltimo se realiza un NAT con la IP del servidor fÃsico para alcanzar redes externas. El router agregado pretende simular un TOR configurado para realizar tareas como: reenviar el trÃ¡fico originado por las instancias en OpenStack hacia redes externas, administrar los distintos rangos de VLANs utilizables para redes provider o dar soporte a redes de tipo flat. Nuevamente para cada subred utilizada por OSA se crea un Linux Bridge que emula el comportamiento de un switch que interconecta distintas interfaces de los nodos.
-
-En una arquitectura estÃ¡ndar de producciÃ³n, los Linux Bridges llamados management, storage y tenant, deberÃan ser switches fÃsicos, el router TOR fÃsico podrÃa actuar adicionalmente como un firewall y los nodos deberÃan tener 4 interfaces fÃsicas en donde utilizando bonding y VLANs se ganarÃa mayor disponibilidad de los servicios.
-
-	\begin{figure}[h!]
-	\centering
-	\includegraphics[width=1\columnwidth]{chap5/arquitectura}
-	\caption{Arquitectura diseÃ±ada para instalaciÃ³n Stein}
-	\label{fig:stein:arquitectura}
-	\end{figure}
-
-El ambiente de trabajo utilizado comparte la mayorÃa de las caracterÃsticas con el descrito en \ref{chap4:ambiente:trabajo} para la instalaciÃ³n de la versiÃ³n Queens. Los puntos en los que difiere tienen que ver con los elementos que son virtualizados con KVM y son detallados a continuaciÃ³n. En primer lugar las redes que anteriormente mantenÃan un NAT con el bridge br-mgmt del servidor renata, ahora son redes aisladas conectadas al router, el cual proporcionarÃ¡ la conexiÃ³n hasta el br-mgmt. AdemÃ¡s, se implementan 3 redes en lugar de 4, una para el management (plano de control), otra para el storage (plano de control) y la Ãºltima utilizada para el trÃ¡fico tenant (plano de datos). La segunda diferencia se presenta en el aumento de los recursos destinado a los nodos del Datacenter brindando soporte a una mayor cantidad de instancias, datos en almacenamiento permanente y recursos de red virtualizados.
-
-Por Ãºltimo, cabe destacar que se modifica el backend utilizado para el mÃ³dulo de almacenamiento Cinder. En este caso se hace uso de Ceph, mencionado en el marco teÃ³rico, el cual presenta muchas ventajas frente al utilizado por defecto LVM.
+Al bridge br-mgmt ubicado en el servidor fÃsico renata y conectado a la interfaz fÃsica eno2 se conectan directamente la interfaz pÃºblica del balanceador de carga (nodo haproxy 01) por la cual llegarÃ¡n los pedidos de las redes externas y el Linux Bridge asociado al router en la red 10.0.40.0/24. En este Ãºltimo se realiza un NAT con la IP del servidor fÃsico para alcanzar redes externas.
 
 \section{PreparaciÃ³n de nodos}\label{chap5:preparacion:nodos}
 PreparaciÃ³n de nodos
diff --git a/docs/udelartex/anexo/anexoVirtualizacionKVM.tex b/docs/udelartex/anexo/anexoVirtualizacionKVM.tex
new file mode 100644
index 0000000000000000000000000000000000000000..2a6f0285818e6bf620d702acaeba7e7df3f72a0f
--- /dev/null
+++ b/docs/udelartex/anexo/anexoVirtualizacionKVM.tex
@@ -0,0 +1,149 @@
+\chapter{VirtualizaciÃ³n con KVM}\label{anexo:virt-kvm}
+Para crear la arquitectura de nodos se utilizÃ³ el virtualizador KVM, debido a que es la tecnologÃa de virtualizaciÃ³n utilizada normalmente en los servidores del INCO. Con el fin de facilitar la interacciÃ³n con KVM a travÃ©s de una interfaz grÃ¡fica, se utilizÃ³ el programa virt-manager.
+
+\section{UtilizaciÃ³n virt-manager}
+\subsection{ConexiÃ³n remota}
+Dentro del virt-manager lo primero a realizar es configurar una nueva conexiÃ³n desde el menÃº Archivo -\textgreater AÃ±adir conexiÃ³n... de la siguiente forma:
+
+\begin{figure}[H]
+	\centering
+	\includegraphics[width=0.5\columnwidth]{chap4/virt-nueva-conexion}
+	\caption{Nueva conexiÃ³n en virt-manager.}
+	\label{virt-nueva-conexion}
+\end{figure}
+
+Como un host remoto estÃ¡ a dos conexiones SSH del servidor Renata, la configuraciÃ³n que se muestra en la figura X no serÃ¡ suficiente. Para el correcto funcionamiento se debe crear una regla de forwarding que envÃe todas las acciones realizadas por el virt-manager hacia el host lulu.fing.edu.uy el cual tiene acceso al servidor. Para lograr esto se debe ejecutar: 
+
+\begin{lstlisting}[gobble=0]
+ssh -L 5900:192.168.60.242:22 <usuario_fing>@lulu.fing.edu.uy
+\end{lstlisting}
+
+El nÃºmero de puerto utilizado puede ser cualquiera que no estÃ© siendo utilizado y no sea privilegiado.\\
+
+El orden adecuado para conectarse al servidor mediante virt-manager es:
+
+\begin{enumerate}
+	\item Crear la conexiÃ³n ssh indicada.
+	\item Iniciar virt-manager.
+	\item Inicializar la conexiÃ³n. En este paso se puede llegar a requerir la contraseÃ±a del usuario del servidor renata desde la consola que estÃ© ejecutando el manager.
+\end{enumerate}
+
+\subsection{CreaciÃ³n de una red}
+A continuaciÃ³n se presenta un paso a paso de como crear una red con la herramienta virt-manager.
+Se debe ir al menÃº Editar -\textgreater Detalles de la conexiÃ³n.
+Luego como se muestra en la imagen en la pestaÃ±a de redes virtuales seleccionar el icono (+).
+
+\begin{figure}[H]
+	\centering
+	\includegraphics[width=0.5\columnwidth]{chap4/virt-conf-red}
+	\caption{ConfiguraciÃ³n de redes virtuales en virt-manager.}
+	\label{virt-conf-red}
+\end{figure}
+
+Al presionar el botÃ³n para agregar un nueva red, desplegarÃ¡ en pantalla un wizard. Mediante el mismo se muestra la creaciÃ³n de una red NAT-Open a modo de ejemplo:
+
+\begin{enumerate}
+	\item Seleccionar el nombre de la red
+	\begin{figure}[H]
+		\centering
+		\includegraphics[width=0.5\columnwidth]{chap4/virt-red-1}
+		\label{virt-red-1}
+	\end{figure}
+	
+	\item Seleccionar la subred y el rango para el DHCP
+	\begin{figure}[H]
+		\centering
+		\includegraphics[width=0.5\columnwidth]{chap4/virt-red-2}
+		\label{virt-red-2}
+	\end{figure}	
+	
+	\item No habilitar direcciones IPv6
+	\begin{figure}[H]
+		\centering
+		\includegraphics[width=0.5\columnwidth]{chap4/virt-red-3}
+		\label{virt-red-3}
+	\end{figure}	
+	
+	\item Seleccionar el tipo de red virtual
+	\begin{figure}[H]
+		\centering
+		\includegraphics[width=0.5\columnwidth]{chap4/virt-red-4}
+		\label{virt-red-4}
+	\end{figure}		
+	
+\end{enumerate}
+
+\subsection{Crear nodo}
+Se detalla el paso a paso de cÃ³mo crear una instancia virtual.
+
+\begin{enumerate}
+	\item En el presente ejemplo se crea una VM suponiendo que se instalarÃ¡ el SO.
+	\begin{figure}[H]
+		\centering
+		\includegraphics[width=0.5\columnwidth]{chap4/virt-nodo-1}
+		\label{virt-nodo-1}
+	\end{figure}
+	
+	\item Seleccionar la imagen a utilizar y el tipo de SO. La misma deberÃ¡ estar en un directorio del servidor fÃsico.
+	\begin{figure}[H]
+		\centering
+		\includegraphics[width=1.0\columnwidth]{chap4/virt-nodo-2}
+		\label{virt-nodo-2}
+	\end{figure}
+	
+	\item Seleccionar RAM y CPUs.
+	\begin{figure}[H]
+		\centering
+		\includegraphics[width=0.5\columnwidth]{chap4/virt-nodo-3}
+		\label{virt-nodo-3}
+	\end{figure}
+	
+	\item Para el almacenamiento se deberÃ¡ crear un nuevo volumen de la siguiente forma:
+	\begin{enumerate}[label*=\arabic*.]
+		\item Elegir la segunda opciÃ³n y presionar Administrar.
+		\begin{figure}[H]
+			\centering
+			\includegraphics[width=0.5\columnwidth]{chap4/virt-nodo-4a}
+			\label{virt-nodo-4a}
+		\end{figure}
+		
+		\item Esto desplegarÃ¡ una ventana mostrando directorios del sistema de archivos de renata. Se puede elegir un volumen existente o crear uno nuevo con el botÃ³n (+).
+		\begin{figure}[H]
+			\centering
+			\includegraphics[width=1.0\columnwidth]{chap4/virt-nodo-4b}
+			\label{virt-nodo-4b}
+		\end{figure}
+		
+		\item Al crearlo se debe especificar el nombre, el tipo y la capacidad.
+		\begin{figure}[H]
+			\centering
+			\includegraphics[width=0.8\columnwidth]{chap4/virt-nodo-4c}
+			\label{virt-nodo-4c}
+		\end{figure}
+		
+	\end{enumerate}
+	
+	\item Luego se debe ingresar el nombre de la mÃ¡quina y seleccionar la red que conecta el host directamente al bridge del servidor fÃsico en lugar de la red NAT-Open para que el host tenga conexiÃ³n a internet durante la instalaciÃ³n y poder realizar las primeras configuraciones en el mismo.
+	\begin{figure}[H]
+		\centering
+		\includegraphics[width=0.6\columnwidth]{chap4/virt-nodo-5}
+		\label{virt-nodo-5}
+	\end{figure}
+	
+	\item Se debe verificar en la opciÃ³n IDE CDROM 1 que estÃ© correctamente asignada la imagen a utilizar para instalar el SO.
+	\begin{figure}[H]
+		\centering
+		\includegraphics[width=1.0\columnwidth]{chap4/virt-nodo-6}
+		\label{virt-nodo-6}
+	\end{figure}
+	
+	\item Verificar en las opciones de arranque que el IDE CDROM 1 estÃ© en primer lugar para que la mÃ¡quina inicie con la imagen seleccionada.
+	\begin{figure}[H]
+		\centering
+		\includegraphics[width=0.9\columnwidth]{chap4/virt-nodo-7}
+		\label{virt-nodo-7}
+	\end{figure}
+	
+	\item Finalmente al confirmar todos los cambios se lanzarÃ¡ la VM creada y se instalarÃ¡ el SO.
+	
+\end{enumerate}
\ No newline at end of file
diff --git a/docs/udelartex/apendice/apendice_A.tex b/docs/udelartex/apendice/apendice_A.tex
deleted file mode 100644
index d3eadbb67460622cf9e09a75698a97ab7124a920..0000000000000000000000000000000000000000
--- a/docs/udelartex/apendice/apendice_A.tex
+++ /dev/null
@@ -1,2 +0,0 @@
-\chapter{Datos procesados}
-
diff --git a/docs/udelartex/apendice/apendice_B.tex b/docs/udelartex/apendice/apendice_B.tex
deleted file mode 100644
index 81ee3bdf62179a0d47b25d8f0327e5d39f090f53..0000000000000000000000000000000000000000
--- a/docs/udelartex/apendice/apendice_B.tex
+++ /dev/null
@@ -1,10 +0,0 @@
-\chapter{ImÃ¡genes remasterizadas}\label{apendice:imagenes}
-
-
-\begin{figure}[h!]
-\centering
-\hspace*{-2.5cm}
-\includegraphics[width=1\paperwidth]{chap5/arquitectura}
-\caption{Arquitectura diseÃ±ada para instalaciÃ³n Stein}
-\label{fig:stein:arquitectura:anexo}
-\end{figure}
\ No newline at end of file
diff --git a/docs/udelartex/apendice/apendice_C.tex b/docs/udelartex/apendice/apendice_C.tex
deleted file mode 100644
index b092fbb67b4dd4666efae22802c2f6046d74c5a3..0000000000000000000000000000000000000000
--- a/docs/udelartex/apendice/apendice_C.tex
+++ /dev/null
@@ -1 +0,0 @@
-\chapter{Entrevistas desgrabadas}\label{Ape3}
diff --git a/docs/udelartex/apendice/imagenes.tex b/docs/udelartex/apendice/imagenes.tex
new file mode 100644
index 0000000000000000000000000000000000000000..a158a24c342383bfccdf58a1ef9dd8ddc58cc3e0
--- /dev/null
+++ b/docs/udelartex/apendice/imagenes.tex
@@ -0,0 +1,18 @@
+\chapter{ImÃ¡genes} \label{apendice:imagenes}
+
+\begin{figure}[h!]
+	\centering
+	\hspace*{-2.5cm}
+	\includegraphics[width=1\paperwidth]{chap4/dis-arquitectura}
+	\caption{Arquitectura diseÃ±ada para desarrollo}
+	\label{fig:arquitectura-anexo-desa}
+\end{figure}
+
+
+\begin{figure}[h!]
+\centering
+\hspace*{-2.5cm}
+\includegraphics[width=1\paperwidth]{chap5/arquitectura}
+\caption{Arquitectura diseÃ±ada para producciÃ³n}
+\label{fig:arquitectura-anexo-prod}
+\end{figure}
\ No newline at end of file
diff --git "a/docs/udelartex/capitulos/dise\303\261o.tex" "b/docs/udelartex/capitulos/dise\303\261o.tex"
index 8cf49f02d3296cb7c3dc5890ae693ec79e3feb95..ed0790e6d3c20f5d056d7843392efda3f0e06928 100644
--- "a/docs/udelartex/capitulos/dise\303\261o.tex"
+++ "b/docs/udelartex/capitulos/dise\303\261o.tex"
@@ -1,134 +1,28 @@
 \chapter{DiseÃ±o}
 
 \section{DiseÃ±o de arquitectura}
-Tendriamos que hablar en general, contando que la idea es que se instale en servidores fisicos, haciendo la correcpondencia de elementos virtualizados y fisicos y capaz que mencionar por arriba a las distintas arquitecturas que tenemos, refenciando a cada una en el anexo que estan.
+Los diseÃ±os que se presentan en esta secciÃ³n estÃ¡n orientados a ser utilizados con servidores y componentes de red fÃsicos. Debido a que no se cuenta con los suficientes recursos, todo el ambiente fÃsico serÃ¡ virtualizado dentro de un Ãºnico servidor detallado en la siguiente secciÃ³n. De aquÃ en mas cada uno de los nodos virtualizados del Datacenter serÃ¡ considerado como un nodo fÃsico, ademas los switches fÃsicos necesarios serÃ¡n emulados mediante Linux Bridges alojados en el servidor renata. Por Ãºltimo en el caso en que es necesario un router TOR se implemente mediante una VM que mantiene configurados los forwarding necesarios.
+A continuaciÃ³n se describen los ambientes de desarrollo y producciÃ³n que fueron empleados.
 
-\section{Ambiente de trabajo}\label{diseÃ±o:ambiente:trabajo}
-
-\subsection{Hardware utilizado}
-Para realizar la instalaciÃ³n de OpenStack se utilizÃ³ un servidor fÃsico (denominado renata) alojado en el Instituto de ComputaciÃ³n de la Facultad de IngenierÃa (INCO). El mismo cuenta con una amplia cantidad de recursos destacando sus 40 procesadores virtuales, 128 GB de RAM y 40 TB de disco duro. Se aloja en una red privada del INCO en donde para salir a Internet se debe pasar por un proxy, provocando algunas limitaciones que luego se mencionan.\\
-
-En el servidor fueron necesarias las siguientes configuraciones de red:
-\begin{enumerate}
-	\item CreaciÃ³n de un bridge el cual serÃ¡ utilizado por la interfaz fÃsica del servidor y por los distintos NAT que se deben crear con KVM para la arquitectura que se virtualiza.
-	Para esto se creo la interfaz br-mgmt con la siguiente configuraciÃ³n:
-	\lstinputlisting{chap4/renata/br-mgmt}
-	
-	\item En la interfaz eno2 la cual tenÃa configurada la IP del bridge quedÃ³ de la siguiente forma:
-	\lstinputlisting{chap4/renata/eno2}	
-\end{enumerate}
-
-\subsection{ConexiÃ³n remota hacia el servidor renata}
-Dado que el servidor se encuentra en una red privada del INCO, para conectarse al mismo de forma remota se deben establecer algunas conexiones SSH. A continuaciÃ³n se detallan las conexiones y comandos utilizados.
-
-\begin{figure}[!h]
-	\centering
-	\includegraphics[width=1.0\columnwidth]{chap4/acceso-renata}
-	\caption{Acceso remoto al servidor renata.}
-	\label{acceso-renata}
-\end{figure}
-
-\begin{enumerate}
-	\item Como el servidor se encuentra en una red privada del INCO solo se puede acceder desde un host que se encuentre en una red interna de la FING, por ej: lulu.fing.edu.uy. Para esto ejecutar:
-	\begin{lstlisting}
-	$ ssh usuario_fing@lulu.fing.edu.uy
-	\end{lstlisting}
-	
-	\item Desde el host lulu para conectarse al servidor renata se debe ejecutar: 
-	\begin{lstlisting}
-	$ ssh openstack@192.168.60.242
-	\end{lstlisting}
-\end{enumerate}
-
-\subsection{VirtualizaciÃ³n con KVM}
-Para crear la arquitectura de nodos se utilizÃ³ el virtualizador KVM, debido a que es la tecnologÃa de virtualizaciÃ³n utilizada normalmente en los servidores del INCO. Con el fin de facilitar la interacciÃ³n con KVM a travÃ©s de una interfaz grÃ¡fica, se utilizÃ³ el programa virt-manager.
-
-\subsubsection{UtilizaciÃ³n virt-manager}
-Dentro del virt-manager lo primero a realizar es configurar una nueva conexiÃ³n desde el menÃº Archivo -> AÃ±adir conexiÃ³n... de la siguiente forma:
-
-\begin{figure}[H]
-	\centering
-	\includegraphics[width=0.5\columnwidth]{chap4/virt-nueva-conexion}
-	\caption{Nueva conexiÃ³n en virt-manager.}
-	\label{virt-nueva-conexion}
-\end{figure}
-
-Como un host remoto estÃ¡ a dos conexiones SSH del servidor Renata, la configuraciÃ³n que se muestra en la figura X no serÃ¡ suficiente. Para el correcto funcionamiento se debe crear una regla de forwarding que envÃe todas las acciones realizadas por el virt-manager hacia el host lulu.fing.edu.uy el cual tiene acceso al servidor. Para lograr esto se debe ejecutar: 
-
-\begin{lstlisting}[gobble=0]
-ssh -L 5900:192.168.60.242:22 <usuario_fing>@lulu.fing.edu.uy
-\end{lstlisting}
+\subsection{Arquitectura desarrollo}\label{sec:arquitectura-desarrollo}
+El diagrama de la figura \ref{fig:arquitectura-desarrollo} (ver en ApÃ©ndice \ref{apendice:imagenes} figura \ref{fig:arquitectura-anexo-desa}) presenta la arquitectura diseÃ±ada para la instalaciÃ³n de OpenStack Ansible para un ambiente de desarrollo. Al tratarse de un escenario meramente de prueba, sÃ³lo se cuenta con un nodo de cada tipo definido previamente \ref{sec:tipos-nodos}. En el mismo se puede apreciar que no se han utilizado VLANs ni bonds en las interfaces de los servidores, sino que se han agregado tantas interfaces fÃsicas como fueran necesarias. Se detallan tambiÃ©n las numeraciones IP a ser utilizadas en cada una de las redes necesarias y las asignaciones a los diferentes bridges de cada uno de los nodos. Cabe mencionar que la IP pÃºblica del balanceador de carga pertenece a la subred en la que se encuentra el servidor fÃsico sobre el cual se virtualizan todos los nodos, con el fin de tener acceso externo a la plataforma. Por otro lado el backend de almacenamiento utilizado es LVM dado que no tiene relevancia utilizar una tecnologÃa mÃ¡s robusta.
 
-El nÃºmero de puerto utilizado puede ser cualquiera que no estÃ© siendo utilizado y no sea privilegiado.\\
-
-El orden adecuado para conectarse al servidor mediante virt-manager es:
-
-\begin{enumerate}
-	\item Crear la conexiÃ³n ssh indicada.
-	\item Iniciar virt-manager.
-	\item Inicializar la conexiÃ³n. En este paso se puede llegar a requerir la contraseÃ±a del usuario del servidor renata desde la consola que estÃ© ejecutando el manager.
-\end{enumerate}
-
-Lo siguiente a realizar es crear con KVM las redes virtuales que se natean al bridge br-mgmt del servidor fÃsico. Es necesario crear 4 redes, donde cada una se corresponde con las redes necesarias para el funcionamiento de OpenStack. Estas redes son:
+En este diseÃ±o se utilizan 4 redes necesarias para intercomunicar los planos de control y datos de los nodos del Datacenter y una red pÃºblica.
 
 \begin{itemize}
-	\item NAT-Open (Subred management 10.0.1.0/24).
-	\item NAT-Open-Storage (Subred storage 10.0.10.0/24).
-	\item NAT-Open-Vxlan (Subred VXLAN 10.0.2.0/24).
-	\item NAT-Open-Vlan (Subred VLAN 10.0.4.0/24).
+	\item Red de management en la subred 10.0.1.0/24.
+	\item Red de storage en la subred 10.0.10.0/24.
+	\item Red de VXLAN en la subred 10.0.2.0/24.
+	\item Red de VLAN en la subred 10.0.4.0/24.
+	\item Red pÃºblica en la subred 192.168.60.0/24.
 \end{itemize}
 
-Para crear estas redes se debe ir al menÃº Editar -> Detalles de la conexiÃ³n.
-Luego como se muestra en la imagen en la pestaÃ±a de redes virtuales seleccionar el icono (+).
-
-\begin{figure}[H]
-	\centering
-	\includegraphics[width=0.5\columnwidth]{chap4/virt-conf-red}
-	\caption{ConfiguraciÃ³n de redes virtuales en virt-manager.}
-	\label{virt-conf-red}
-\end{figure}
-
-Al presionar el botÃ³n para agregar un nueva red, desplegarÃ¡ en pantalla un wizard. A continuaciÃ³n se muestra el paso a paso de la creaciÃ³n de la red NAT-Open a modo de ejemplo:
-
-\begin{enumerate}
-	\item Seleccionar el nombre de la red
-	\begin{figure}[H]
-		\centering
-		\includegraphics[width=0.5\columnwidth]{chap4/virt-red-1}
-		\label{virt-red-1}
-	\end{figure}
-	
-	\item Seleccionar la subred y el rango para el DHCP
-	\begin{figure}[H]
-		\centering
-		\includegraphics[width=0.5\columnwidth]{chap4/virt-red-2}
-		\label{virt-red-2}
-	\end{figure}	
-	
-	\item No habilitar direcciones IPv6
-	\begin{figure}[H]
-		\centering
-		\includegraphics[width=0.5\columnwidth]{chap4/virt-red-3}
-		\label{virt-red-3}
-	\end{figure}	
-	
-	\item Seleccionar el tipo de red virtual
-	\begin{figure}[H]
-		\centering
-		\includegraphics[width=0.5\columnwidth]{chap4/virt-red-4}
-		\label{virt-red-4}
-	\end{figure}		
-	
-\end{enumerate}
-
-El mismo procedimiento se deberÃ¡ repetir con el resto de las redes listadas.\\
-
-Lo Ãºltimo que es necesario crear con KVM son las nodos virtuales que se utilizaron para instalar OpenStack. En la instalaciÃ³n realizada se utilizan 5 nodos con las especificaciones detalladas a continuaciÃ³n:
+En el diseÃ±o se utilizan 5 nodos con las especificaciones detalladas a continuaciÃ³n:
 
 \begin{itemize}
 	\item \textbf{Nodo deploy}:
 	\begin{itemize}
-		\item 1 interfaz en NAT-Open
+		\item 1 interfaz en red management
 		\item 2 CPUs
 		\item 200 GB de disco
 		\item 8 GB de RAM
@@ -136,7 +30,7 @@ Lo Ãºltimo que es necesario crear con KVM son las nodos virtuales que se utiliza
 	
 	\item \textbf{Nodo haproxy1}:
 	\begin{itemize}
-		\item 2 interfaces: una en NAT-Open y otra conectada al bridge br-mgmt de renata
+		\item 2 interfaces: una en red management y otra conectada a red pÃºblica
 		\item 4 CPUs
 		\item 200 GB de disco
 		\item 32 GB de RAM
@@ -144,7 +38,7 @@ Lo Ãºltimo que es necesario crear con KVM son las nodos virtuales que se utiliza
 	
 	\item \textbf{Nodo infra1}:
 	\begin{itemize}
-		\item 4 interfaces: una en cada NAT creada
+		\item 4 interfaces: una en cada red privada
 		\item 8 CPUs
 		\item 200 GB de disco
 		\item 32 GB de RAM
@@ -152,7 +46,7 @@ Lo Ãºltimo que es necesario crear con KVM son las nodos virtuales que se utiliza
 	
 	\item \textbf{Nodo compute1}:
 	\begin{itemize}
-		\item 4 interfaces: una en cada NAT creada
+		\item 4 interfaces: una en cada red privada
 		\item 8 CPUs
 		\item 200 GB de disco
 		\item 32 GB de RAM
@@ -160,7 +54,7 @@ Lo Ãºltimo que es necesario crear con KVM son las nodos virtuales que se utiliza
 	
 	\item \textbf{Nodo storage1}:
 	\begin{itemize}
-		\item 2 interfaces: una en NAT-Open y otra en NAT-Open-Storage
+		\item 2 interfaces: una en red management y otra en red storage
 		\item 4 CPUs
 		\item 2 discos: uno de 40 GB para el SO y otro de 200 GB para el volumen de cinder
 		\item 32 GB de RAM
@@ -168,78 +62,126 @@ Lo Ãºltimo que es necesario crear con KVM son las nodos virtuales que se utiliza
 	
 \end{itemize}
 
-A continuaciÃ³n se detalla paso a paso cÃ³mo crear el nodo deploy, el resto se realiza de forma anÃ¡loga salvando las diferencias de recursos e interfaces de red.
+\begin{figure}[H]
+	\centering
+	\includegraphics[width=1.0\columnwidth]{chap4/dis-arquitectura}
+	\caption{Arquitectura diseÃ±ada.}
+	\label{fig:arquitectura-desarrollo}
+\end{figure}
 
-\begin{enumerate}
-	\item En el presente ejemplo se crea una VM suponiendo que se instalarÃ¡ el SO.
-	\begin{figure}[H]
-		\centering
-		\includegraphics[width=0.5\columnwidth]{chap4/virt-nodo-1}
-		\label{virt-nodo-1}
-	\end{figure}
-	
-	\item Seleccionar la imagen a utilizar y el tipo de SO. La misma deberÃ¡ estar en un directorio del servidor fÃsico.
-	\begin{figure}[H]
-		\centering
-		\includegraphics[width=1.0\columnwidth]{chap4/virt-nodo-2}
-		\label{virt-nodo-2}
-	\end{figure}
+\subsection{Arquitectura producciÃ³n}\label{sec:arquitectura-produccion}
+La arquitectura planteada para instalar OpenStack en un ambiente de producciÃ³n se muestra en la figura \ref{fig:arquitectura-produccion} (ver en ApÃ©ndice \ref{apendice:imagenes} figura \ref{fig:arquitectura-anexo-prod}). Con esta arquitectura se intenta aproximar una instalaciÃ³n para utilizar en un ambiente de producciÃ³n, contando con varios nodos de almacenamiento y cÃ³mputo. A diferencia de la arquitectura empleada para desarrollo se utilizan VLANs para aislar el trÃ¡fico de datos de las redes tenant de tipo VLAN o VXLAN sobre la interfaz eth2 de los nodos de infraestructura y cÃ³mputo. Para el trÃ¡fico de management y storage se dedican interfaces exclusivas en cada uno de los nodos del Datacenter. El router agregado pretende simular un TOR configurado para realizar tareas como: reenviar el trÃ¡fico originado por las instancias en OpenStack hacia redes externas, administrar los distintos rangos de VLANs utilizables para redes provider o dar soporte a redes de tipo flat. Nuevamente para cada subred utilizada por OSA se crea un Linux Bridge que emula el comportamiento de un switch que interconecta distintas interfaces de los nodos. Por Ãºltimo, cabe destacar que se modifica el backend utilizado para el mÃ³dulo de almacenamiento Cinder. En este caso se hace uso de Ceph, mencionado en el marco teÃ³rico, el cual presenta muchas ventajas frente al utilizado por defecto LVM.
+En este diseÃ±o se utilizan 6 redes necesarias para intercomunicar los planos de control y datos de los nodos del Datacenter y una red pÃºblica.
+
+\begin{itemize}
+	\item Red de management en la subred 10.0.10.0/24.
+	\item Red de storage en la subred 10.0.20.0/24.
+	\item Red de tenant en la subred 10.0.30.0/24.
+	\item Red de overlay tenant en la subred 10.0.31.0/24.
+	\item Red de VLAN en la subred 10.0.100.0/24 con el VLAN ID 100.
+	\item Red pÃºblica en la subred 192.168.60.0/24.
+\end{itemize}
+
+En el diseÃ±o se utilizan 8 nodos con las especificaciones detalladas a continuaciÃ³n:
+
+\begin{itemize}
+	\item \textbf{Nodo deploy}:
+	\begin{itemize}
+		\item 1 interfaz en red management
+		\item 2 CPUs
+		\item 200 GB de disco
+		\item 8 GB de RAM
+	\end{itemize}
 	
-	\item Seleccionar RAM y CPUs.
-	\begin{figure}[H]
-		\centering
-		\includegraphics[width=0.5\columnwidth]{chap4/virt-nodo-3}
-		\label{virt-nodo-3}
-	\end{figure}
+	\item \textbf{Nodo haproxy1}:
+	\begin{itemize}
+		\item 2 interfaces: una en red management y otra conectada a red pÃºblica
+		\item 2 CPUs
+		\item 200 GB de disco
+		\item 16 GB de RAM
+	\end{itemize}
 	
-	\item Para el almacenamiento se deberÃ¡ crear un nuevo volumen de la siguiente forma:
-	\begin{enumerate}[label*=\arabic*.]
-		\item Elegir la segunda opciÃ³n y presionar Administrar.
-		\begin{figure}[H]
-			\centering
-			\includegraphics[width=0.5\columnwidth]{chap4/virt-nodo-4a}
-			\label{virt-nodo-4a}
-		\end{figure}
-		
-		\item Esto desplegarÃ¡ una ventana mostrando directorios del sistema de archivos de renata. Se puede elegir un volumen existente o crear uno nuevo con el botÃ³n (+).
-		\begin{figure}[H]
-			\centering
-			\includegraphics[width=1.0\columnwidth]{chap4/virt-nodo-4b}
-			\label{virt-nodo-4b}
-		\end{figure}
-		
-		\item Al crearlo se debe especificar el nombre, el tipo y la capacidad.
-		\begin{figure}[H]
-			\centering
-			\includegraphics[width=0.8\columnwidth]{chap4/virt-nodo-4c}
-			\label{virt-nodo-4c}
-		\end{figure}
-		
-	\end{enumerate}
+	\item \textbf{Nodo infra1}:
+	\begin{itemize}
+		\item 3 interfaces: en las redes de management, storage y tenant
+		\item 4 CPUs
+		\item 200 GB de disco
+		\item 32 GB de RAM
+	\end{itemize}
 	
-	\item Luego se debe ingresar el nombre de la mÃ¡quina y seleccionar la red que conecta el host directamente al bridge del servidor fÃsico en lugar de la red NAT-Open para que el host tenga conexiÃ³n a internet durante la instalaciÃ³n y poder realizar las primeras configuraciones en el mismo.
-	\begin{figure}[H]
-		\centering
-		\includegraphics[width=0.6\columnwidth]{chap4/virt-nodo-5}
-		\label{virt-nodo-5}
-	\end{figure}
+	\item \textbf{Nodo compute1 y compute2}:
+	\begin{itemize}
+		\item 3 interfaces: en las redes de management, storage y tenant
+		\item 8 CPUs
+		\item 200 GB de disco
+		\item 32 GB de RAM
+	\end{itemize}
 	
-	\item Se debe verificar en la opciÃ³n IDE CDROM 1 que estÃ© correctamente asignada la imagen a utilizar para instalar el SO.
-	\begin{figure}[H]
-		\centering
-		\includegraphics[width=1.0\columnwidth]{chap4/virt-nodo-6}
-		\label{virt-nodo-6}
-	\end{figure}
+	\item \textbf{Nodo storage1 y storage2}:
+	\begin{itemize}
+		\item 2 interfaces: una en red management y otra en red storage
+		\item 2 CPUs
+		\item 2 discos: uno de 200 GB para el SO y otro de 200 GB para el volumen de cinder
+		\item 16 GB de RAM
+	\end{itemize}
+
+	\item \textbf{Router}:
+	\begin{itemize}
+		\item 4 interfaces: en las redes de management, storage y tenant. Ademas una interfaz con acceso a la red pÃºblica.
+		\item 2 CPUs
+		\item 40 GB de disco
+		\item 8 GB de RAM
+	\end{itemize}
 	
-	\item Verificar en las opciones de arranque que el IDE CDROM 1 estÃ© en primer lugar para que la mÃ¡quina inicie con la imagen seleccionada.
-	\begin{figure}[H]
-		\centering
-		\includegraphics[width=0.9\columnwidth]{chap4/virt-nodo-7}
-		\label{virt-nodo-7}
-	\end{figure}
+\end{itemize}
+
+En una arquitectura estÃ¡ndar de producciÃ³n el router TOR fÃsico podrÃa actuar adicionalmente como un firewall y los nodos deberÃan tener 4 interfaces fÃsicas en donde utilizando bonding y VLANs se ganarÃa mayor disponibilidad de los servicios.
+
+\begin{figure}[h!]
+	\centering
+	\includegraphics[width=1\columnwidth]{chap5/arquitectura}
+	\caption{Arquitectura diseÃ±ada para instalaciÃ³n Stein}
+	\label{fig:arquitectura-produccion}
+\end{figure}
+
+\subsection{DistribuciÃ³n de los servicios}
+ESCRIBIR ALGUN VERSO
+
+\section{Ambiente de trabajo}\label{diseÃ±o:ambiente:trabajo}
+
+\subsection{Hardware utilizado}
+Para realizar la instalaciÃ³n de OpenStack se utilizÃ³ un servidor fÃsico (denominado renata) alojado en el Instituto de ComputaciÃ³n de la Facultad de IngenierÃa (INCO). El mismo cuenta con una amplia cantidad de recursos destacando sus 40 procesadores virtuales, 128 GB de RAM y 40 TB de disco duro. Se aloja en una red privada del INCO en donde para salir a Internet se debe pasar por un proxy, provocando algunas limitaciones que luego se mencionan.\\
+
+En el servidor fueron necesarias las siguientes configuraciones de red:
+\begin{enumerate}
+	\item CreaciÃ³n de un bridge el cual serÃ¡ utilizado por la interfaz fÃsica del servidor y por los distintos NAT que se deben crear con KVM para la arquitectura que se virtualiza.
+	Para esto se creo la interfaz br-mgmt con la siguiente configuraciÃ³n:
+	\lstinputlisting{chap4/renata/br-mgmt}
 	
-	\item Finalmente al confirmar todos los cambios se lanzarÃ¡ la VM creada y se instalarÃ¡ el SO.
+	\item En la interfaz eno2 la cual tenÃa configurada la IP del bridge quedÃ³ de la siguiente forma:
+	\lstinputlisting{chap4/renata/eno2}	
+\end{enumerate}
+
+\subsection{ConexiÃ³n remota hacia el servidor renata}
+Dado que el servidor se encuentra en una red privada del INCO, para conectarse al mismo de forma remota se deben establecer algunas conexiones SSH. A continuaciÃ³n se detallan las conexiones y comandos utilizados.
+
+\begin{figure}[!h]
+	\centering
+	\includegraphics[width=1.0\columnwidth]{chap4/acceso-renata}
+	\caption{Acceso remoto al servidor renata.}
+	\label{acceso-renata}
+\end{figure}
+
+\begin{enumerate}
+	\item Como el servidor se encuentra en una red privada del INCO solo se puede acceder desde un host que se encuentre en una red interna de la FING, por ej: lulu.fing.edu.uy. Para esto ejecutar:
+	\begin{lstlisting}
+	$ ssh usuario_fing@lulu.fing.edu.uy
+	\end{lstlisting}
 	
+	\item Desde el host lulu para conectarse al servidor renata se debe ejecutar: 
+	\begin{lstlisting}
+	$ ssh openstack@192.168.60.242
+	\end{lstlisting}
 \end{enumerate}
 
 \subsection{Especificaciones servidor renata}
@@ -280,96 +222,3 @@ Los nodos virtualizados en el servidor renata con la configuraciÃ³n por defecto
 	\label{internet-nodos}
 \end{figure}
 
-\section{EjecuciÃ³n de playbooks}
-Finalmente para instalar OpenStack con Ansible es necesario correr las playbooks principales del proyecto, las cuales se encuentran en el directorio \path{/opt/openstack-ansible/playbooks}.\\
-En primer lugar se ejecutan tres scripts para realizar un chequeo de sintaxis de la configuraciÃ³n preparada y los scripts a utilizar. Esto se realiza de la siguiente forma:
-
-\begin{lstlisting}
-$ openstack-ansible setup-hosts.yml --syntax-check
-$ openstack-ansible setup-infrastructure.yml --syntax-check
-$ openstack-ansible setup-openstack.yml --syntax-check
-\end{lstlisting}
-\vspace{8pt}
-En caso de no tener errores, se comienza la ejecuciÃ³n de las playbook en el orden que se describen:
-
-\subsubsection{setup-hosts.yml}
-Esta playbook se encarga de configurar todos los hosts descritos en el archivo \path{openstack_user_config.yml}. Con el siguiente comando se ejecuta la playbook:
-
-\begin{lstlisting}
-$ openstack-ansible -vvv setup-hosts.yml 2>&1 | tee /var/log/openstack/hostsXX.log
-\end{lstlisting}
-
-La opciÃ³n -vvv es para que la salida sea mÃ¡s verbosa y el final es para mostrar la salida del comando en la consola y almacenarla en un archivo de log.
-
-\subsubsection{install-haproxy.yml}
-La configuraciÃ³n de los balanceadores de carga es lo siguiente a realizar. Esto se puede realizar sin tener explÃcitamente los contenedores o servidores fÃsicos con los servicios instalados gracias a Ansible. OSA como se mencionÃ³ en la secciÃ³n del inventario, a partir de los archivos de configuraciÃ³n conoce exactamente cÃ³mo quedarÃ¡ instalado cada uno de los servicios de OpenStack, por ejemplo las IPs y puertos de cada servicio.
-Con el siguiente comando se ejecuta la playbook:
-
-\begin{lstlisting}
-$ openstack-ansible -vvv haproxy-install.yml 2>&1 | tee /var/log/openstack/haproxyXX.log
-\end{lstlisting}
-
-\subsubsection{setup-infrastructure.yml}
-En este paso demora un poco mÃ¡s que el primer setup y se encargarÃ¡ de construir todos los contenedores donde luego se instalarÃ¡n los servicios de OpenStack. Esta script ademÃ¡s se encarga de instalar los servicios de infraestructura como son RabbitMQ o Galera DB para luego ser configurados en la playbook final.
-Con el siguiente comando se ejecuta la playbook:
-
-\begin{lstlisting}
-$ openstack-ansible -vvv setup-infrastructure.yml 2>&1 | tee /var/log/openstack/infrastructureXX.log
-\end{lstlisting}
-
-\subsubsection{setup-openstack.yml}
-En este paso final es cuando se configuran todos los servicios, indicados en los archivos de configuraciÃ³n de OSA, de OpenStack. Esta playbook es la que demora mÃ¡s tiempo en su ejecuciÃ³n, en el orden de las horas.
-Con el siguiente comando se ejecuta la playbook:
-
-\begin{lstlisting}
-$ openstack-ansible -vvv setup-openstack.yml 2>&1 | tee /var/log/openstack/openstackXX.log
-\end{lstlisting}
-
-\section{VerificaciÃ³n}
-Luego de que la Ãºltima playbook haya terminado su ejecuciÃ³n sin error, debemos verificar que la instalaciÃ³n fue exitosa. Esto se realizarÃ¡ de forma manual siguiendo los pasos que se indican a continuaciÃ³n:
-
-\begin{enumerate}
-	\item Acceder al nodo de infra1 como usuario root.
-	
-	\item La instalaciÃ³n que realiza OSA crea contenedores de utilidad los cuales proveen de todas las herramientas desde la consola para utilizar OpenStack. En primer lugar se deben listar todos los containers del nodo fÃsico ejecutando:
-	\begin{lstlisting}
-	$ lxc-ls -f
-	\end{lstlisting}	
-	
-	\item El contenedor que se utiliza es el que tiene en su nombre la palabra utility, para acceder al mismo es necesario ejecutar el siguiente comando de lxc:
-	\begin{lstlisting}
-	$ lxc-attach -n <nombre_contenedor>
-	\end{lstlisting}	
-	
-	\item Para utilizar los servicios de OpenStack es necesario enviar las credenciales del usuario que invocarÃ¡ a las APIs de los servicios. Esto se debe al funcionamiento de OpenStack en donde cada llamada a una API debe ser validada por el mÃ³dulo de Keystone. Para evitar escribir las credenciales en cada comando, OSA genera un archivo llamado openrc para cargar la informaciÃ³n del usuario como variables de entorno. El archivo se carga con el siguiente comando:
-	\begin{lstlisting}
-	$ source openrc
-	\end{lstlisting}	
-	
-	\item Algunos comandos que se pueden ejecutar son:
-	\begin{itemize}
-		\item Para listar usuarios:
-		\begin{lstlisting}
-		$ openstack user list --os-cloud=default
-		\end{lstlisting}			
-		
-		\item Para listar servidores:
-		\begin{lstlisting}
-		$ openstack server list
-		\end{lstlisting}	
-		
-		\item Para listar redes:
-		\begin{lstlisting}
-		$ openstack network list
-		\end{lstlisting}	
-		
-		\item Para listar los agentes de red:
-		\begin{lstlisting}
-		$ openstack network agent list
-		\end{lstlisting}					
-		
-	\end{itemize}
-	
-	\item Por otro lado se puede verificar el dashboard de Horizon accediendo a la ip definida en \path{external_lb_vip_address} en el archivo \path{/etc/openstack_deploy/openstack_user_config.yml} en el puerto 443 dado que utiliza HTTPS. Para autenticarse como admin en necesaria la password que se encuentra definida en la opciÃ³n \path{keystone_auth_admin_password} del archivo \path{/etc/openstack_deploy/user_secrets.yml}.
-	
-\end{enumerate}
\ No newline at end of file
diff --git a/docs/udelartex/capitulos/openstack-ansible.tex b/docs/udelartex/capitulos/openstack-ansible.tex
new file mode 100644
index 0000000000000000000000000000000000000000..19f4465015a3ea090b5ba40c3be4ee9be37f3bf3
--- /dev/null
+++ b/docs/udelartex/capitulos/openstack-ansible.tex
@@ -0,0 +1,189 @@
+\chapter{OpenStack-Ansible}
+\section{Arquitectura}
+El mÃ©todo de instalaciÃ³n OSA emplea LXC para desplegar los servicios de OpenStack. AdemÃ¡s utiliza Linux bridges entre los contenedores y las interfaces fÃsicas o lÃ³gicas del host con el fin de proveer conectividad directa a nivel de capa 2. El aislamiento de cada contenedor se logra mediante la utilizaciÃ³n de namespaces, esto genera que se deban utilizar pares de interfaces virtuales (veth pairs) para tener conectividad entre los mismos. Esta implementaciÃ³n se puede ver en la imagen \ref{network-components}.
+
+\begin{figure}[h!]
+	\centering
+	\includegraphics[width=0.6\columnwidth]{chap3/network-components}
+	\caption{Componentes de red en Openstack. \cite{openstack-container-networking}.}
+	\label{network-components}
+\end{figure}
+
+\subsection{Arquitectura de red}
+OSA soporta mÃºltiples arquitecturas de red, las cuales se diferencian segÃºn sea para un ambiente de producciÃ³n o testing, cantidad de interfaces fÃsicas de los servidores o mÃ³dulos de openstack utilizados. Para los ambientes de producciÃ³n es comÃºn utilizar interfaces bondeadas mejorando la disponibilidad de los servicios. En general para segmentar el trÃ¡fico, tanto en los casos donde se realiza bonding o en donde hay interfaces simples, se utilizan VLANs asignando un ID para cada subred utilizada dentro de OpenStack. A continuaciÃ³n se describen las subredes empleadas por OSA para su funcionamiento:
+
+\subparagraph{Management Network}
+La red de administraciÃ³n o tambiÃ©n container network se encarga de proveer la administraciÃ³n y comunicaciÃ³n entre la infraestructura y los servicios de OpenStack en containers o en servidores fÃsicos. Para que todas las instancias tengan acceso a esta red, es necesario que todos los nodos host del datacenter cuenten con el bridge br-mgmt. A este Ãºltimo se le asocian las interfaces virtuales de cada contenedor y la lÃ³gica o fÃsica del host en cuestiÃ³n, asignadas a dicha red. Esta interfaz suele ser la primaria del nodo mediante la cual se accede por SSH.
+
+\subparagraph{Overlay Network}
+La red de superposiciÃ³n o tambiÃ©n tunnel network, provee conectividad entre los hosts virtualizados dentro de OpenStack encapsulando el trÃ¡fico con algÃºn protocolo de tunelizaciÃ³n como son VXLAN o GENEVE. La VLAN o interfaz utilizada para esta subred se asocia al bridge br-vxlan. Este bridge debe instanciarse en todos los nodos que manejen agentes del mÃ³dulo Neutron, tÃpicamente involucra los nodos de cÃ³mputo y/o red.
+
+\subparagraph{Storage Network}
+La red de almacenamiento provee acceso entre los backends de almacenamiento, tales como Block storage, y los servicios de Openstack, como Cinder o Glance. En este caso las interfaces o VLANs se asocian al bridge br-storage, que debe instanciarse en todos los nodos que alojan servicios de cÃ³mputo o almacenamiento.
+
+\subsubsection{Interfaces de red}
+Como se mencionÃ³ en OSA se pueden tener diversas configuraciones dependiendo de la cantidad de interfaces del host fÃsico, algunas de ellas se muestran en la figura \ref{interfaces}.
+
+\begin{figure}[h!]
+	\centering
+	\includegraphics[width=1.0\columnwidth]{chap3/interfaces}
+	\caption{Diagrama de mÃºltiples interfaces de red. ExtraÃda de \cite{openstack-networking-architecture}.}
+	\label{interfaces}
+\end{figure}
+
+En esta se utilizan dos interfaces simples, subdivididas mediante la implementaciÃ³n de VLANs que finalmente se asocian a los bridges mencionados anteriormente.
+
+\begin{figure}[h!]
+	\centering
+	\includegraphics[width=1.0\columnwidth]{chap3/bonded-interfaces}
+	\caption{Diagrama de bonds de mÃºltiples interfaces de red. ExtraÃda de \cite{openstack-networking-architecture}.}
+	\label{bonded-interfaces}
+\end{figure}
+
+En el segundo (figura \ref{bonded-interfaces}), se cuenta con cuatro interfaces (provenientes de dos tarjetas fÃsicas) que son bondeadas en forma cruzada para mejorar la disponibilidad y subdivididas mediante la implementaciÃ³n de VLANs para finalmente asociarlas a los bridges.
+
+En ambos casos, se resalta la separaciÃ³n de las redes tenant con las redes internas para el funcionamiento de OSA y la ausencia de veth pairs asociadas a los bridges debido a que no se visualizan servicios desplegados en contenedores. 
+
+En la figura \ref{containers-deploy} se presenta un diseÃ±o que ilustra servicios desplegados en contenedores y cÃ³mo varÃan las interconexiones de red para proveer conectividad.
+
+\begin{figure}[h!]
+	\centering
+	\includegraphics[width=1.0\columnwidth]{chap3/containers-deploy}
+	\caption{Despliegue de servicios OpenStack en contenedores. ExtraÃda de \cite{openstack-appendix-e}.}
+	\label{containers-deploy}
+\end{figure}
+
+Como se menciona anteriormente los contenedores que corren servicios de OpenStack requieren de interfaces virtuales para conectarse con los bridges del nodo fÃsico. AdemÃ¡s se puede observar cÃ³mo varÃan las conexiones necesarias a los distintos tipos de red, en funciÃ³n del tipo de agente que corre en el contenedor. Al utilizar contenedores, OSA crea automÃ¡ticamente una nueva red que se utilizarÃ¡ para la administraciÃ³n de los mismos (por ejemplo para descargar paquetes). Un punto a tener en cuenta es que Ansible para crear esta subred utiliza el rango 10.0.3.0/24.
+
+En la figura \ref{diagrama-openstack-1} se presenta el diagrama de una arquitectura modelo de OpenStack Ansible en un ambiente de producciÃ³n que involucra los conceptos mencionados en puntos anteriores.
+
+\begin{figure}[h!]
+	\centering
+	\includegraphics[width=1.0\columnwidth]{chap3/diagrama-openstack-1}
+	\caption{ExtraÃda de \cite{openstack-cookbook-book}}
+	\label{diagrama-openstack-1}
+\end{figure}
+
+\section{ConfiguraciÃ³n OSA}
+En esta secciÃ³n se presentan las configuraciones y conceptos mÃ¡s relevantes del nodo Deploy a tener en cuenta durante un despliegue de Openstack utilizando Ansible. Estas incluyen las convenciones de directorios empleadas, la configuraciÃ³n estÃ¡ndar y el significado del contenido de los archivos que deben ser modificados.
+
+\subsection{Convenciones}
+\begin{itemize}
+	\item El repositorio de OSA se clona generalmente en el directorio \path{/opt/openstack-ansible}.
+	\item Los roles de Ansible utilizados por defecto se encuentran en el directorio \path{/etc/ansible/roles} los cuales son generados a partir del archivo \path{/opt/openstack-ansible/ansible-role-requirements.yml} mediante la ejecuciÃ³n del \path{script bootstrap-ansible.sh}. 
+	\item Las configuraciones realizadas por el administrador son indicadas en el directorio \path{/etc/openstack_deploy}.
+\end{itemize}
+
+\subsection{Inventario}
+Define las especificaciones de los hosts y contenedores dentro del ambiente actual de OpenStack. Esta informaciÃ³n se encuentra en el archivo \path{/etc/openstack-ansible/openstack_inventory.json}, generado a partir de los host groups, containers groups y components indicados en:
+\begin{itemize}
+	\item La estructura por defecto almacenada en \path{/opt/openstack-ansible/inventory/env.d}
+	\item Lo configurado por el administrador dentro de \path{/etc/openstack_deploy/} en:
+	\begin{itemize}
+		\item El archivo \path{openstack_user_config.yml}
+		\item El directorio \path{conf.d/}
+		\item El directorio \path{env.d/}
+	\end{itemize}		 
+\end{itemize}
+
+Este archivo es considerado como referencia en cualquiera de los comandos asociados al despliegue de OSA por lo tanto nunca debe ser eliminado o modificado en un ambiente de producciÃ³n.
+
+Los components hacen referencia a los diferentes servicios que serÃ¡n instalados durante el despliegue de OpenStack, tanto en contenedores virtuales como directamente en los target host. Los containers groups agrupan estos components, determinando los potenciales contenedores a ser creados junto con sus especificaciones. 
+En las configuraciones realizadas en ambos directorios env.d/ se asocian los containers groups anteriores con los hosts groups, los cuales agrupan diversos target hosts. De esta forma se determina quÃ© servicio debe ser instalado en quÃ© target host.
+
+\subsection{openstack\_user\_config.yml}
+Es el principal archivo de configuraciÃ³n, creado por el operador de Openstack. Las especificaciones de cada secciÃ³n se detallan en \cite{openstack-user-config}.
+
+\section{EjecuciÃ³n de playbooks}
+Finalmente para instalar OpenStack con Ansible es necesario correr las playbooks principales del proyecto, las cuales se encuentran en el directorio \path{/opt/openstack-ansible/playbooks}.\\
+En primer lugar se ejecutan tres scripts para realizar un chequeo de sintaxis de la configuraciÃ³n preparada y los scripts a utilizar. Esto se realiza de la siguiente forma:
+
+\begin{lstlisting}
+$ openstack-ansible setup-hosts.yml --syntax-check
+$ openstack-ansible setup-infrastructure.yml --syntax-check
+$ openstack-ansible setup-openstack.yml --syntax-check
+\end{lstlisting}
+\vspace{8pt}
+En caso de no tener errores, se comienza la ejecuciÃ³n de las playbook en el orden que se describen:
+
+\subsection{setup-hosts.yml}
+Esta playbook se encarga de configurar todos los hosts descritos en el archivo \path{openstack_user_config.yml}. Con el siguiente comando se ejecuta la playbook:
+
+\begin{lstlisting}
+$ openstack-ansible -vvv setup-hosts.yml 2>&1 | tee /var/log/openstack/hostsXX.log
+\end{lstlisting}
+
+La opciÃ³n -vvv es para que la salida sea mÃ¡s verbosa y el final es para mostrar la salida del comando en la consola y almacenarla en un archivo de log.
+
+\subsection{install-haproxy.yml}
+La configuraciÃ³n de los balanceadores de carga es lo siguiente a realizar. Esto se puede realizar sin tener explÃcitamente los contenedores o servidores fÃsicos con los servicios instalados gracias a Ansible. OSA como se mencionÃ³ en la secciÃ³n del inventario, a partir de los archivos de configuraciÃ³n conoce exactamente cÃ³mo quedarÃ¡ instalado cada uno de los servicios de OpenStack, por ejemplo las IPs y puertos de cada servicio.
+Con el siguiente comando se ejecuta la playbook:
+
+\begin{lstlisting}
+$ openstack-ansible -vvv haproxy-install.yml 2>&1 | tee /var/log/openstack/haproxyXX.log
+\end{lstlisting}
+
+\subsection{setup-infrastructure.yml}
+En este paso demora un poco mÃ¡s que el primer setup y se encargarÃ¡ de construir todos los contenedores donde luego se instalarÃ¡n los servicios de OpenStack. Esta script ademÃ¡s se encarga de instalar los servicios de infraestructura como son RabbitMQ o Galera DB para luego ser configurados en la playbook final.
+Con el siguiente comando se ejecuta la playbook:
+
+\begin{lstlisting}
+$ openstack-ansible -vvv setup-infrastructure.yml 2>&1 | tee /var/log/openstack/infrastructureXX.log
+\end{lstlisting}
+
+\subsection{setup-openstack.yml}
+En este paso final es cuando se configuran todos los servicios, indicados en los archivos de configuraciÃ³n de OSA, de OpenStack. Esta playbook es la que demora mÃ¡s tiempo en su ejecuciÃ³n, en el orden de las horas.
+Con el siguiente comando se ejecuta la playbook:
+
+\begin{lstlisting}
+$ openstack-ansible -vvv setup-openstack.yml 2>&1 | tee /var/log/openstack/openstackXX.log
+\end{lstlisting}
+
+\section{VerificaciÃ³n}
+Luego de que la Ãºltima playbook haya terminado su ejecuciÃ³n sin error, debemos verificar que la instalaciÃ³n fue exitosa. Esto se realizarÃ¡ de forma manual siguiendo los pasos que se indican a continuaciÃ³n:
+
+\begin{enumerate}
+	\item Acceder al nodo de infra1 como usuario root.
+	
+	\item La instalaciÃ³n que realiza OSA crea contenedores de utilidad los cuales proveen de todas las herramientas desde la consola para utilizar OpenStack. En primer lugar se deben listar todos los containers del nodo fÃsico ejecutando:
+	\begin{lstlisting}
+	$ lxc-ls -f
+	\end{lstlisting}	
+	
+	\item El contenedor que se utiliza es el que tiene en su nombre la palabra utility, para acceder al mismo es necesario ejecutar el siguiente comando de lxc:
+	\begin{lstlisting}
+	$ lxc-attach -n <nombre_contenedor>
+	\end{lstlisting}	
+	
+	\item Para utilizar los servicios de OpenStack es necesario enviar las credenciales del usuario que invocarÃ¡ a las APIs de los servicios. Esto se debe al funcionamiento de OpenStack en donde cada llamada a una API debe ser validada por el mÃ³dulo de Keystone. Para evitar escribir las credenciales en cada comando, OSA genera un archivo llamado openrc para cargar la informaciÃ³n del usuario como variables de entorno. El archivo se carga con el siguiente comando:
+	\begin{lstlisting}
+	$ source openrc
+	\end{lstlisting}	
+	
+	\item Algunos comandos que se pueden ejecutar son:
+	\begin{itemize}
+		\item Para listar usuarios:
+		\begin{lstlisting}
+		$ openstack user list --os-cloud=default
+		\end{lstlisting}			
+		
+		\item Para listar servidores:
+		\begin{lstlisting}
+		$ openstack server list
+		\end{lstlisting}	
+		
+		\item Para listar redes:
+		\begin{lstlisting}
+		$ openstack network list
+		\end{lstlisting}	
+		
+		\item Para listar los agentes de red:
+		\begin{lstlisting}
+		$ openstack network agent list
+		\end{lstlisting}					
+		
+	\end{itemize}
+	
+	\item Por otro lado se puede verificar el dashboard de Horizon accediendo a la ip definida en \path{external_lb_vip_address} en el archivo \path{/etc/openstack_deploy/openstack_user_config.yml} en el puerto 443 dado que utiliza HTTPS. Para autenticarse como admin en necesaria la password que se encuentra definida en la opciÃ³n \path{keystone_auth_admin_password} del archivo \path{/etc/openstack_deploy/user_secrets.yml}.
+	
+\end{enumerate}
diff --git a/docs/udelartex/capitulos/openstack.tex b/docs/udelartex/capitulos/openstack.tex
index 03e9fcef579d8bbff50036bd038bd8c5efa77fa6..97439d11ed2486044edc08360bc093a570aed953 100644
--- a/docs/udelartex/capitulos/openstack.tex
+++ b/docs/udelartex/capitulos/openstack.tex
@@ -1,13 +1,13 @@
-\chapter{Openstack}
+\chapter{OpenStack}
 
 \section{Origen y definiciÃ³n}
-Openstack fue creado en los primeros meses del 2010. En ese momento Rackspace querÃa reescribir el cÃ³digo de infraestructura que corrÃa en sus servidores cloud y ademÃ¡s estaban considerando hacer open source el cÃ³digo cloud existente. En ese entonces, Anso Labs, quienes trabajaban para la NASA, publicaron el cÃ³digo beta para Nova, un proyecto basado en Python descrito como â€œcloud computing fabric controllerâ€. Dadas las semejanzas en las necesidades de ambas empresas, decidieron en unir fuerzas dando como resultado una base de Openstack.
+OpenStack fue creado en los primeros meses del 2010. En ese momento Rackspace querÃa reescribir el cÃ³digo de infraestructura que corrÃa en sus servidores cloud y ademÃ¡s estaban considerando hacer open source el cÃ³digo cloud existente. En ese entonces, Anso Labs, quienes trabajaban para la NASA, publicaron el cÃ³digo beta para Nova, un proyecto basado en Python descrito como â€œcloud computing fabric controllerâ€. Dadas las semejanzas en las necesidades de ambas empresas, decidieron en unir fuerzas dando como resultado una base de OpenStack.
 
 El primer Summit de diseÃ±o tuvo lugar en Austin, TX del 13 al 14 de julio de 2010, en donde participaron aproximadamente 25 compaÃ±Ãas: AMD, Autonomic Resources, Citrix, Cloud.com, Cloudkick, Cloudscaling, CloudSwitch, Dell, enStratus, FathomDB, Intel, iomart Group, Limelight, Nicira, NTT DATA, Opscode, PEER 1, Puppet Labs, RightScale, Riptano, Scalr, SoftLayer, Sonian, Spiceworks, Zenoss y Zuora. El proyecto fue oficialmente anunciado el 21 de julio de ese mismo aÃ±o.
 
-Originalmente la misiÃ³n de Openstack era â€œto produce the ubiquitous Open Source Cloud Computing platform that will meet the needs of public and private clouds regardless of size, by being simple to implement and massively scalableâ€. Luego en 2016 se actualizÃ³ la misma incluyendo interoperabilidad y mejor servicio a los usuarios finales. En septiembre de 2012, fue lanzada la fundaciÃ³n de Openstack como una instituciÃ³n independiente proporcionando recursos para proteger, potenciar y promover el software Openstack y la comunidad que lo rodea \cite{openstack-history}. Como es definido en el sitio de Openstack, \textsl{â€œes un sistema operativo en la nube que controla grandes grupos de recursos de computaciÃ³n, almacenamiento y redes a travÃ©s de un centro de datos, administrados y provisionados a travÃ©s de APIsâ€}\cite{openstack-software}.
+Originalmente la misiÃ³n de OpenStack era â€œto produce the ubiquitous Open Source Cloud Computing platform that will meet the needs of public and private clouds regardless of size, by being simple to implement and massively scalableâ€. Luego en 2016 se actualizÃ³ la misma incluyendo interoperabilidad y mejor servicio a los usuarios finales. En septiembre de 2012, fue lanzada la fundaciÃ³n de OpenStack como una instituciÃ³n independiente proporcionando recursos para proteger, potenciar y promover el software OpenStack y la comunidad que lo rodea \cite{openstack-history}. Como es definido en el sitio de OpenStack, \textsl{â€œes un sistema operativo en la nube que controla grandes grupos de recursos de computaciÃ³n, almacenamiento y redes a travÃ©s de un centro de datos, administrados y provisionados a travÃ©s de APIsâ€}\cite{openstack-software}.
 
-Openstack es un software open source gobernado por una fundaciÃ³n. Ser parte de la misma es gratis y estÃ¡ abierta a todo el mundo. El proyecto tiene una arquitectura modular, en donde cada instalaciÃ³n de Openstack tendrÃ¡ instalados y configurados los mÃ³dulos que se ajusten a las necesidades del caso. Dichos mÃ³dulos estÃ¡n implementados en Python. Seis de estos proyectos se denominan como mÃ³dulos core dado que se encargan de las funciones principales del cloud como son las conexiones de red, el almacenamiento, el servicio de identidad, servicios de imÃ¡genes y de cÃ³mputo. Permite construir nubes pÃºblicas y privadas ofreciendo principalmente servicios de infraestructura (IaaS) y en un grado menor, servicios de plataforma (PaaS).
+OpenStack es un software open source gobernado por una fundaciÃ³n. Ser parte de la misma es gratis y estÃ¡ abierta a todo el mundo. El proyecto tiene una arquitectura modular, en donde cada instalaciÃ³n de OpenStack tendrÃ¡ instalados y configurados los mÃ³dulos que se ajusten a las necesidades del caso. Dichos mÃ³dulos estÃ¡n implementados en Python. Seis de estos proyectos se denominan como mÃ³dulos core dado que se encargan de las funciones principales del cloud como son las conexiones de red, el almacenamiento, el servicio de identidad, servicios de imÃ¡genes y de cÃ³mputo. Permite construir nubes pÃºblicas y privadas ofreciendo principalmente servicios de infraestructura (IaaS) y en un grado menor, servicios de plataforma (PaaS).
 
 \section{MÃ³dulos Core}
 En esta secciÃ³n se describirÃ¡n los mÃ³dulos Nova, Neutron, Glance, Cinder, Keystone y Swift, llamados core, profundizando en los aspectos mÃ¡s importantes de cada uno. Conceptualmente los mÃ³dulos se relacionan de la siguiente forma:
@@ -19,10 +19,10 @@ En esta secciÃ³n se describirÃ¡n los mÃ³dulos Nova, Neutron, Glance, Cinder, Key
 	\label{modules}
 \end{figure}
 
-En \cite{openstack-design} se muestra un esquema de una arquitectura lÃ³gica estÃ¡ndar de Openstack, en donde se puede apreciar las interacciones internas entre los componentes de un proyecto, entre proyectos y entre agentes externos y Openstack.
+En \cite{openstack-design} se muestra un esquema de una arquitectura lÃ³gica estÃ¡ndar de OpenStack, en donde se puede apreciar las interacciones internas entre los componentes de un proyecto, entre proyectos y entre agentes externos y OpenStack.
 
 \subsection{Keystone}
-Keystone es el servicio de identidad que utiliza Openstack para la autenticaciÃ³n y autorizaciÃ³n. El mismo se organiza como un conjunto de servicios internos, que se exponen en uno o varios endpoints, listados a continuaciÃ³n:
+Keystone es el servicio de identidad que utiliza OpenStack para la autenticaciÃ³n y autorizaciÃ³n. El mismo se organiza como un conjunto de servicios internos, que se exponen en uno o varios endpoints, listados a continuaciÃ³n:
 
 \begin{figure}[h!]
 	\centering
@@ -39,8 +39,8 @@ Keystone es el servicio de identidad que utiliza Openstack para la autenticaciÃ³
 	\end{itemize}
 	\item El \textbf{servicio de recursos} provee informaciÃ³n sobre proyectos y dominios.
 	\begin{itemize}
-		\item Los proyectos representan la unidad base de propiedad en Openstack, debido a que todos los recursos deben pertenecer a un proyecto necesariamente. Los proyectos son Ãºnicos dentro de cada dominio.
-		\item Los dominios son grandes contenedores para los proyectos, grupos y usuarios. Por defecto Openstack crea el dominio â€œDefaultâ€. Dada la naturaleza de los dominios los mismos pueden ser utilizados para delegar la administraciÃ³n de los recursos.
+		\item Los proyectos representan la unidad base de propiedad en OpenStack, debido a que todos los recursos deben pertenecer a un proyecto necesariamente. Los proyectos son Ãºnicos dentro de cada dominio.
+		\item Los dominios son grandes contenedores para los proyectos, grupos y usuarios. Por defecto OpenStack crea el dominio â€œDefaultâ€. Dada la naturaleza de los dominios los mismos pueden ser utilizados para delegar la administraciÃ³n de los recursos.
 	\end{itemize}
 	\item El \textbf{servicio de asignaciÃ³n} provee informaciÃ³n sobre roles y asignaciones.
 	\begin{itemize}
@@ -54,7 +54,7 @@ Keystone es el servicio de identidad que utiliza Openstack para la autenticaciÃ³
 Las definiciones mencionadas fueron extraÃdas de \cite{openstack-keystone-architecture} y \cite{openstack-idm-book}.
 
 \subsection{Nova}
-Nova es el proyecto que se encarga de proveer una forma para provisionar instancias o servidores virtuales. El proyecto soporta la creacion de imagenes, servidores baremetal con la ayuda del proyecto ironic y un soporte limitado para el manejo de containers. Nova se compone por un conjunto de demonios que permiten ofrecer los servicios mencionados. Adicionalmente para poder desarrollar las funciones bÃ¡sicas, este mÃ³dulo requiere de los siguientes servicios core de openstack: keystone, glance, neutron y placement.
+Nova es el proyecto que se encarga de proveer una forma para provisionar instancias o servidores virtuales. El proyecto soporta la creaciÃ³n de imÃ¡genes, servidores baremetal con la ayuda del proyecto Ironic y un soporte limitado para el manejo de containers. Nova se compone por un conjunto de demonios que permiten ofrecer los servicios mencionados. Adicionalmente para poder desarrollar las funciones bÃ¡sicas, este mÃ³dulo requiere de los siguientes servicios core de OpenStack: Keystone, Glance, Neutron y placement.
 
 En la figura \ref{nova} se puede apreciar un esquema conceptual de los principales componentes de una instalaciÃ³n de nova estÃ¡ndar. 
 Un dato relevante sobre los componentes de nova es que pueden ser escalados horizontalmente, siendo independiente el grado de escalado para cada servicio.
@@ -76,25 +76,25 @@ Se encarga de recibir y responder las solicitudes HTTP y comunicarse con los otr
 Se encarga de decidir en quÃ© host de cÃ³mputo se aloja cada instancia. Para tomar estas decisiones existen diversos algoritmos que pueden ser configurados, siendo algunos ejemplos el algoritmo simple donde selecciona el host con menor carga actual, chance en donde se elige un nodo de forma randÃ³mica, entre otros. Esta tarea puede ser muy sencilla como es el caso del algoritmo random o muy complicada para los casos donde se requiera realizar un uso eficiente de los recursos \cite{openstack-deploying-book}.
 
 \subparagraph{Compute}
-El mÃ³dulo nova-compute es principalmente un demonio que se encarga de administrar la comunicaciÃ³n con el hypervisor y con las mÃ¡quinas virtuales. Esto lo lleva a cabo mediante las APIs del hipervisor. Algun ejemplos de APIs son: libvirt para KVM o QEMU, XenAPI para XenServer y VMwareAPI para VMware. Haciendo a un lado la complejidad del mÃ³dulo, bÃ¡sicamente el demonio acepta acciones de la cola de mensajes para luego realizar una serie de comandos contra la API del hipervisor. AdemÃ¡s se encarga de actualizar el estado de la base de datos \cite{openstack-compute-overview}.
+El mÃ³dulo nova-compute es principalmente un demonio que se encarga de administrar la comunicaciÃ³n con el hipervisor y con las mÃ¡quinas virtuales. Esto lo lleva a cabo mediante las APIs del hipervisor. AlgÃºn ejemplos de APIs son: libvirt para KVM o QEMU, XenAPI para XenServer y VMwareAPI para VMware. Haciendo a un lado la complejidad del mÃ³dulo, bÃ¡sicamente el demonio acepta acciones de la cola de mensajes para luego realizar una serie de comandos contra la API del hipervisor. AdemÃ¡s se encarga de actualizar el estado de la base de datos \cite{openstack-compute-overview}.
 
 \subparagraph{Conductor}
-En las primeras versiones de Openstack, todos los servicios del componente de cÃ³mputo tenÃan acceso directo a la base de datos hosteada en el nodo controlador. Esto presentaba dos grandes problemas: seguridad y performance. En lo que respecta a la seguridad, en el caso que un nodo de cÃ³mputo sea vea comprometido, el atacante tendrÃ¡ acceso a la base de datos de Openstack. Por el lado de la performance, las llamadas realizadas desde el nodo de cÃ³mputo soportan un Ãºnico hilo y son bloqueantes. Esto generaba un cuello de botella debido a no poder paralelizar las invocaciones.
+En las primeras versiones de OpenStack, todos los servicios del componente de cÃ³mputo tenÃan acceso directo a la base de datos hosteada en el nodo controlador. Esto presentaba dos grandes problemas: seguridad y rendimiento. En lo que respecta a la seguridad, en el caso que un nodo de cÃ³mputo sea vea comprometido, el atacante tendrÃ¡ acceso a la base de datos de OpenStack. Por el lado del rendimiento, las llamadas realizadas desde el nodo de cÃ³mputo soportan un Ãºnico hilo y son bloqueantes. Esto generaba un cuello de botella debido a no poder paralelizar las invocaciones.
 
-Para mejorar estos dos aspectos se introdujo el servicio nova-conductor el cual se presenta como una capa por encima del servicio de cÃ³mputo. Nova-compute en lugar de acceder directamente a la BD, delega la responsabilidad al servicio nova-conductor. En otras palabras este servicio actÃºa como un proxy para el servicio nova-compute.
+Para mejorar estos dos aspectos se introdujo el servicio nova-conductor el cual se presenta como una capa por encima del servicio de cÃ³mputo. Nova-compute en lugar de acceder directamente a la BD, delega la responsabilidad al servicio nova-conductor. En otras palabras este servicio actÃºa como un proxy para el nova-compute.
 
-El problema de seguridad se resuelve dado que los nodos de cÃ³mputo dejan de acceder directamente a la BD y el de performance se resuelve gracias a que el servicio de nova-conductor es no bloqueante, permitiendo realizar mÃºltiples invocaciones en paralelo \cite{openstack-control-plane}.
+El problema de seguridad se resuelve dado que los nodos de cÃ³mputo dejan de acceder directamente a la BD y el del rendimiento se resuelve gracias a que el servicio de nova-conductor es no bloqueante, permitiendo realizar mÃºltiples invocaciones en paralelo \cite{openstack-control-plane}.
 Por los motivos de su existencia, este servicio no se debe instalar en los nodos de cÃ³mputo. \cite{redhat-conductor}.
 
-AdemÃ¡s puede servir como un lugar donde centralizar y permitir administrar las operaciones que involucran al scheduler y el servicio de computo cÃ³mo construir, cambiar el tamaÃ±o o migrar instancias. Esto se realiza con el fin de separar las responsabilidades entre los servicios de nova. En \cite{redhat-conductor} se muestra un ejemplo de los beneficios que este cambio presenta.
+AdemÃ¡s puede servir como un lugar donde centralizar y permitir administrar las operaciones que involucran al scheduler y el servicio de computo, cÃ³mo construir, cambiar el tamaÃ±o o migrar instancias. Esto se realiza con el fin de separar las responsabilidades entre los servicios de nova. En \cite{redhat-conductor} se muestra un ejemplo de los beneficios que este cambio presenta.
 
 \subparagraph{Placement}
 Este servicio se presenta como una API REST que se encarga de realizar un seguimiento de los proveedores de recursos. Los recursos pueden ser de distintas clases. A modo de ejemplo un proveedor puede ser un nodo de cÃ³mputo o un pool de storage.
 
 \subsection{Neutron}
-Neutron es el proyecto encargado de proveer y administrar recursos de red en una nube creada con Openstack. Es un sistema escalable horizontalmente y diseÃ±ado para aÃ±adirle diversos plugins con el fin de proporcionar nuevas funcionalidades. Como otros servicios de Openstack, Neutron requiere una base de datos para persistir las configuraciones de los elementos de red. El servicio de red de Openstack permite crear desde redes y subredes hasta topologÃas de red avanzadas las cuales pueden contener firewalls, balanceadores, VPNs entre otros. 
+Neutron es el proyecto encargado de proveer y administrar recursos de red en una nube creada con OpenStack. Es un sistema escalable horizontalmente y diseÃ±ado para aÃ±adirle diversos plugins con el fin de proporcionar nuevas funcionalidades. Como otros servicios de OpenStack, Neutron requiere una base de datos para persistir las configuraciones de los elementos de red. El servicio de red de OpenStack permite crear desde redes y subredes hasta topologÃas de red avanzadas las cuales pueden contener firewalls, balanceadores, VPNs entre otros. 
 
-Las instalaciones del mÃ³dulo de red deben tener al menos un red externa, la cual no es una SDN definida dentro de Openstack sino que es una red accesible por fuera de Openstack. Estas redes permiten que las redes virtuales construidas con neutron tengan conectividad con el mundo exterior. Por otro lado, neutron permite crear redes internas a las cuales se conectarÃ¡n directamente las VMs. Para lograr que dichas VMs se conecten con las redes externas son necesarios routers que relacionen ambos tipos de redes.
+Las instalaciones del mÃ³dulo de red deben tener al menos un red externa, la cual no es una SDN definida dentro de OpenStack sino que es una red accesible por fuera de OpenStack. Estas redes permiten que las redes virtuales construidas con Neutron tengan conectividad con el mundo exterior. Por otro lado, Neutron permite crear redes internas a las cuales se conectarÃ¡n directamente las VMs. Para lograr que dichas VMs se conecten con las redes externas son necesarios routers que relacionen ambos tipos de redes.
 
 Una arquitectura simplificada de Neutron se puede ver en la figura \ref{neutron2}.
 
@@ -127,7 +127,7 @@ En OpenStack los usuarios tienen la posibilidad de crear su propio esquema de re
 Cuando se crea una red de proyecto los aspectos fÃsicos de como es implementada son transparentes al usuario, por lo contrario en la red de proveedor se puede especificar el tipo de red, la interfaz fÃsica y el identificador de segmentaciÃ³n utilizado.
 
 \subsubsection{Tipo de trÃ¡fico}
-El trÃ¡fico en OpenStack se puede dividir en dos categorÃas: plano de control y plano de datos. El plano de control estÃ¡ relacionado con el trÃ¡fico utilizado para administraciÃ³n de los nodos fÃsicos o contenedores, para las API de los servicios de OpenStack y todo el trÃ¡fico que no estÃ© relacionado con las instancias virtuales de Openstack. El plano de datos estÃ¡ relacionado con el trÃ¡fico generado o dirigido hacia instancias virtuales.
+El trÃ¡fico en OpenStack se puede dividir en dos categorÃas: plano de control y plano de datos. El plano de control estÃ¡ relacionado con el trÃ¡fico utilizado para administraciÃ³n de los nodos fÃsicos o contenedores, para las API de los servicios de OpenStack y todo el trÃ¡fico que no estÃ© relacionado con las instancias virtuales de OpenStack. El plano de datos estÃ¡ relacionado con el trÃ¡fico generado o dirigido hacia instancias virtuales.
 
 En ambientes de producciÃ³n es recomendable utilizar interfaces fÃsicas diferentes para los distintos tipos de trÃ¡ficos \cite{openstack-networking-book-3}. La decisiÃ³n de colapsar todo el trÃ¡fico en una sola interfaz y segmentarlo con VLANs o utilizar mÃºltiples interfaces depende de las necesidades de cada caso. Al utilizar una sola interfaz fÃsica las probabilidades de fallas de red aumentan.
 
@@ -190,7 +190,7 @@ El servicio de almacenamiento de bloques proporciona administraciÃ³n de almacena
 \begin{itemize}
 	\item Crear, listar y eliminar volÃºmenes.
 	\item Crear. listar y eliminar snapshots.
-	\item Atachear y desatachear volÃºmenes a mÃ¡quinas virtuales.
+	\item Asociar y desasociar volÃºmenes a mÃ¡quinas virtuales.
 \end{itemize}
 
 Los volÃºmenes son utilizados como una soluciÃ³n para persistir los datos de una instancia incluso luego de destruir la misma. Los volÃºmenes pueden ser asignados a una instancia a la vez.
@@ -218,7 +218,7 @@ Se trata del componente de almacenamiento de objetos de OpenStack, implementado
 Swift maneja una jerarquÃa en tres niveles para organizar el almacenamiento de objetos \cite{openstack-storage-api}:
 
 \begin{itemize}
-	\item \textbf{Account}: la cuenta es el nivel mas alto en la jerarquÃa, creando un namespace en el cual residen las instancias del siguiente nivel. A nivel de Openstack una cuenta estÃ¡ dada por un proyecto o usuario tenant.
+	\item \textbf{Account}: la cuenta es el nivel mas alto en la jerarquÃa, creando un namespace en el cual residen las instancias del siguiente nivel. A nivel de OpenStack una cuenta estÃ¡ dada por un proyecto o usuario tenant.
 	\item \textbf{Container}: no es mas que un contenedor de objetos, pero permite gestionar un control de acceso a estos mediante ACLs (no es posible tener ACLs directamente sobre objetos). Como contenedor, define un namespace para los objetos que almacena. 
 	\item \textbf{Objeto}: es el contenido a almacenar propiamente dicho, como documentos o imÃ¡genes, incluyendo la metadata asociada a estos. Todos los objetos tienen una URL que los identifica para poder ser accedidos. 
 \end{itemize}
@@ -247,11 +247,11 @@ La figura \ref{swift} ilustra la arquitectura del servicio Swift, en la cual se
 	\item \textbf{Partitions}: cada particiÃ³n puede estar compuesta por un conjunto de bases de datos de cuentas, bases de datos contenedores y objetos propiamente dichos. Se trata de un agrupamiento de elementos para poder ser trasladados dentro del cluster, facilitando operaciones de replicaciÃ³n.
 \end{itemize}
 
-\section{Tipos de nodos}
+\section{Tipos de nodos}\label{sec:tipos-nodos}
 En general los sistemas de OpenStack estÃ¡n construidos con servidores o nodos fÃsicos, aunque tambiÃ©n es posible utilizarlos virtualizados como es el caso de este trabajo, en donde se pueden agrupar en 4 categorÃas \cite{openstack-networking-book-1}:
 
 \subparagraph{Nodo de control}
-Estos nodos en general corren las APIs de todos los servicios de los componentes de OpenStack. AdemÃ¡s estos nodos alojan la base de datos de los mÃ³dulos, los servidores de mensajes y los componentes de cachÃ© en memoria como Memcache. Para escalar horizontalmente las APIs pueden ser instaladas en varios nodos de control pudiendo adicionalmente balancear la carga. 
+Estos nodos en general corren las APIs de todos los servicios de los componentes de OpenStack. AdemÃ¡s estos nodos alojan la base de datos de los mÃ³dulos, los servidores de mensajes y los componentes de cachÃ© en memoria como Memcached. Para escalar horizontalmente las APIs pueden ser instaladas en varios nodos de control pudiendo adicionalmente balancear la carga. 
 
 \subparagraph{Nodo de red}
 Estos nodos en general corren los servicios de metadatos y DHCP. AdemÃ¡s permiten crear routers virtuales cuando el agente de Neutron L3 es instalado. Al igual que los nodos de control, para mejorar el rendimiento y escalar horizontalmente se pueden separar los servicios de red entre los distintos nodos de red. El uso de nodos de red dedicados mejora la seguridad y resistencia, dado que los nodos de control tendrÃ¡n menor riesgo de que se sature la red y sus recursos.
@@ -280,13 +280,13 @@ Estos nodos son fundamentales para el funcionamiento Ã³ptimo de una instalaciÃ³n
 Estos servicios son transversales a todos los mÃ³dulos del sistema y son mandatorios para el funcionamiento de OpenStack. En general estos servicios son instalados en los nodos de control como fue mencionado en la secciÃ³n anterior.
 
 \subparagraph{Galera - MariaDB}
-La base de datos MariaDB se utiliza para almacenar el estado de todos los servicios de openstack, utilizando usualmente una base de datos MySQL. El servidor de base de datos en general se despliega con una configuraciÃ³n activo/pasivo en donde solamente el servidor principal (activo) podrÃ¡ ser utilizado por los servicios. Para poder utilizar un esquema activo/activo se puede utilizar Galera, el cual se define como un software de clusterizaciÃ³n para MySQL, el cual utiliza un mecanismo sincrÃ³nico de replicaciÃ³n para lograr una alta disponibilidad \cite{openstack-architects-book}.
+La base de datos MariaDB se utiliza para almacenar el estado de todos los servicios de OpenStack, utilizando usualmente una base de datos MySQL. El servidor de base de datos en general se despliega con una configuraciÃ³n activo/pasivo en donde solamente el servidor principal (activo) podrÃ¡ ser utilizado por los servicios. Para poder utilizar un esquema activo/activo se puede utilizar Galera, el cual se define como un software de clusterizaciÃ³n para MySQL, el cual utiliza un mecanismo sincrÃ³nico de replicaciÃ³n para lograr una alta disponibilidad \cite{openstack-architects-book}.
 
 \subparagraph{Message queue}
 OpenStack utiliza una cola de mensajes para llevar a cabo la comunicaciÃ³n entre procesos. Los servicios de cola de mensaje que OpenStack soporta son: RabbitMQ y Qpid. Ambos servicios son Advanced Message Queuing Protocol (AMQP) frameworks, los cuales proveen colas de mensajes para comunicaciones punto a punto. En general las colas de mensajes son desplegadas como pools de servidores centralizados o descentralizados. En la instalaciÃ³n realizada se utilizÃ³ RabbitMQ \cite{openstack-messaging}.
 
 \subparagraph{Memcached}
-Es un sistema de cachÃ© de objetos en memoria distribuido, apuntado a mejorar el rendimiento de los sistemas mediante la reducciÃ³n de carga a la base de datos. En Openstack este software es utilizado por el mecanismo de autenticaciÃ³n de keystone para cachear los tokens del sistema \cite{openstack-memcached}.
+Es un sistema de cachÃ© de objetos en memoria distribuido, apuntado a mejorar el rendimiento de los sistemas mediante la reducciÃ³n de carga a la base de datos. En OpenStack este software es utilizado por el mecanismo de autenticaciÃ³n de Keystone para cachear los tokens del sistema \cite{openstack-memcached}.
 
 \section{MÃ©todos de instalaciÃ³n}
 Realizar la instalaciÃ³n bÃ¡sica de OpenStack (mÃ³dulos core) es una tarea sumamente compleja. Esto se debe a la gran cantidad de configuraciones y diversos tÃ³picos en los cuales hay que tener un grado de entendimiento no menor, como en bases de datos, Linux, redes y backends de almacenamiento. Las guÃas de instalaciÃ³n que se pueden encontrar en el sitio oficial de OpenStack consisten de cientos de configuraciones y comandos a ejecutar en donde es muy probable equivocarse y en consecuencia instalar incorrectamente los mÃ³dulos de la herramienta.
@@ -295,7 +295,7 @@ Debido a la relevancia que ha tomado en los Ãºltimos aÃ±os OpenStack, la amplia
 
 Otra de las razones principales para utilizar herramientas de automatizaciÃ³n ademÃ¡s de facilitar la instalaciÃ³n es para poder mantener el sistema luego de su instalaciÃ³n. En el caso de realizar las tareas manualmente no se podrÃ¡ escalar la nube a cientos o miles de servidores dado que serÃa prÃ¡cticamente imposible de mantener o actualizar.
 
-En el presente trabajo se emplea la herramienta de automatizaciÃ³n Ansible dentro del proyecto OpenStack-Ansible (OSA). Dicho proyecto se encarga de proveer playbooks y roles para desplegar y configurar un ambiente de OpenStack basado en el concepto de Infrastructure as Code (IaC). OSA no es un proyecto que funcione simplemente con los archivos y configuraciones por defecto sino que modificaciones por parte del administrador del cloud serÃ¡n necesarias. El resultado final que se obtiene con OSA es un cloud de OpenStack probada para ambientes de cualquier tamaÃ±o, desde datacenters de testing hasta producciÃ³n.
+En el presente trabajo se emplea la herramienta de automatizaciÃ³n Ansible dentro del proyecto OpenStack-Ansible (OSA). Dicho proyecto se encarga de proveer playbooks y roles para desplegar y configurar un ambiente de OpenStack basado en el concepto de Infrastructure as Code (IaC). OSA no es un proyecto que funcione simplemente con los archivos y configuraciones por defecto sino que modificaciones por parte del administrador del cloud serÃ¡n necesarias. El resultado final que se obtiene con OSA es un cloud de OpenStack probada para ambientes de cualquier tamaÃ±o, desde Datacenters de testing hasta producciÃ³n.
 
 Antes de continuar profundizando en las particularidades de OSA se introducirÃ¡ brevemente Ansible.
 
@@ -316,100 +316,6 @@ Todas las acciones que se pueden realizar con Ansible se llevan a cabo con un m
 Es la unidad de acciÃ³n en Ansible. 
 
 \subparagraph{Playbook}
-Contienen una lista ordenada de tareas. Las playbooks se escriben en YAML lo cual beneficia la lectura, escritura y la comprensiÃ³n de las mismas. Son una forma de organizar las tareas bajo un criterio determinado. En el caso de OSA utiliza varias playbooks para setear el ambiente inicial, instalar los componentes de infraestructura, entre otros que se especificarÃ¡n en las prÃ³ximas secciones.
+Contienen una lista ordenada de tareas. Las playbooks se escriben en YAML lo cual beneficia la lectura, escritura y la comprensiÃ³n de las mismas. Son una forma de organizar las tareas bajo un criterio determinado. En el caso de OSA utiliza varias playbooks para preparar el ambiente inicial, instalar los componentes de infraestructura, entre otros que se especificarÃ¡n en las prÃ³ximas secciones.
 
-\section{Arquitectura}
-El mÃ©todo de instalaciÃ³n OSA emplea LXC para desplegar los servicios de Openstack. AdemÃ¡s utiliza Linux bridges entre los contenedores y las interfaces fÃsicas o lÃ³gicas del host con el fin de proveer conectividad directa a nivel de capa 2. El aislamiento de cada contenedor se logra mediante la utilizaciÃ³n de namespaces, esto genera que se deban utilizar pares de interfaces virtuales (veth pairs) para tener conectividad entre los mismos. Esta implementaciÃ³n se puede ver en la imagen \ref{network-components}.
-
-\begin{figure}[h!]
-	\centering
-	\includegraphics[width=0.6\columnwidth]{chap3/network-components}
-	\caption{Componentes de red en Openstack. \cite{openstack-container-networking}.}
-	\label{network-components}
-\end{figure}
-
-\subsection{Arquitectura de red}
-OSA soporta mÃºltiples arquitecturas de red, las cuales se diferencian segÃºn sea para un ambiente de producciÃ³n o testing, cantidad de interfaces fÃsicas de los servidores o mÃ³dulos de openstack utilizados. Para los ambientes de producciÃ³n es comÃºn utilizar interfaces bondeadas mejorando la disponibilidad de los servicios. En general para segmentar el trÃ¡fico, tanto en los casos donde se realiza bonding o en donde hay interfaces simples, se utilizan VLANs asignando un ID para cada subred utilizada dentro de OpenStack. A continuaciÃ³n se describen las subredes empleadas por OSA para su funcionamiento:
-
-\subparagraph{Management Network}
-La red de administraciÃ³n o tambiÃ©n container network se encarga de proveer la administraciÃ³n y comunicaciÃ³n entre la infraestructura y los servicios de OpenStack en containers o en servidores fÃsicos. Para que todas las instancias tengan acceso a esta red, es necesario que todos los nodos host del datacenter cuenten con el bridge br-mgmt. A este Ãºltimo se le asocian las interfaces virtuales de cada contenedor y la lÃ³gica o fÃsica del host en cuestiÃ³n, asignadas a dicha red. Esta interfaz suele ser la primaria del nodo mediante la cual se accede por SSH.
-
-\subparagraph{Overlay Network}
-La red de superposiciÃ³n o tambiÃ©n tunnel network, provee conectividad entre los hosts virtualizados dentro de OpenStack encapsulando el trÃ¡fico con algÃºn protocolo de tunelizaciÃ³n como son VXLAN o GENEVE. La VLAN o interfaz utilizada para esta subred se asocia al bridge br-vxlan. Este bridge debe instanciarse en todos los nodos que manejen agentes del mÃ³dulo Neutron, tÃpicamente involucra los nodos de cÃ³mputo y/o red.
-
-\subparagraph{Storage Network}
-La red de almacenamiento provee acceso entre los backends de almacenamiento, tales como Block storage, y los servicios de Openstack, como Cinder o Glance. En este caso las interfaces o VLANs se asocian al bridge br-storage, que debe instanciarse en todos los nodos que alojan servicios de cÃ³mputo o almacenamiento.
-
-\subsubsection{Interfaces de red}
-Como se mencionÃ³ en OSA se pueden tener diversas configuraciones dependiendo de la cantidad de interfaces del host fÃsico, algunas de ellas se muestran en la figura \ref{interfaces}.
-
-\begin{figure}[h!]
-	\centering
-	\includegraphics[width=1.0\columnwidth]{chap3/interfaces}
-	\caption{Diagrama de mÃºltiples interfaces de red. ExtraÃda de \cite{openstack-networking-architecture}.}
-	\label{interfaces}
-\end{figure}
-
-En esta se utilizan dos interfaces simples, subdivididas mediante la implementaciÃ³n de VLANs que finalmente se asocian a los bridges mencionados anteriormente.
-
-\begin{figure}[h!]
-	\centering
-	\includegraphics[width=1.0\columnwidth]{chap3/bonded-interfaces}
-	\caption{Diagrama de bonds de mÃºltiples interfaces de red. ExtraÃda de \cite{openstack-networking-architecture}.}
-	\label{bonded-interfaces}
-\end{figure}
-
-En el segundo (figura \ref{bonded-interfaces}), se cuenta con cuatro interfaces (provenientes de dos tarjetas fÃsicas) que son bondeadas en forma cruzada para mejorar la disponibilidad y subdivididas mediante la implementaciÃ³n de VLANs para finalmente asociarlas a los bridges.
-
-En ambos casos, se resalta la separaciÃ³n de las redes tenant con las redes internas para el funcionamiento de OSA y la ausencia de veth pairs asociadas a los bridges debido a que no se visualizan servicios desplegados en contenedores. 
-
-En la figura \ref{containers-deploy} se presenta un diseÃ±o que ilustra servicios desplegados en contenedores y cÃ³mo varÃan las interconexiones de red para proveer conectividad.
-
-\begin{figure}[h!]
-	\centering
-	\includegraphics[width=1.0\columnwidth]{chap3/containers-deploy}
-	\caption{Despliegue de servicios OpenStack en contenedores. ExtraÃda de \cite{openstack-appendix-e}.}
-	\label{containers-deploy}
-\end{figure}
-
-Como se menciona anteriormente los contenedores que corren servicios de OpenStack requieren de interfaces virtuales para conectarse con los bridges del nodo fÃsico. AdemÃ¡s se puede observar cÃ³mo varÃan las conexiones necesarias a los distintos tipos de red, en funciÃ³n del tipo de agente que corre en el contenedor. Al utilizar contenedores, OSA crea automÃ¡ticamente una nueva red que se utilizarÃ¡ para la administraciÃ³n de los mismos (por ejemplo para descargar paquetes). Un punto a tener en cuenta es que Ansible para crear esta subred utiliza el rango 10.0.3.0/24.
-
-En la figura \ref{diagrama-openstack-1} se presenta el diagrama de una arquitectura modelo de OpenStack Ansible en un ambiente de producciÃ³n que involucra los conceptos mencionados en puntos anteriores.
-
-\begin{figure}[h!]
-	\centering
-	\includegraphics[width=1.0\columnwidth]{chap3/diagrama-openstack-1}
-	\caption{ExtraÃda de \cite{openstack-cookbook-book}}
-	\label{diagrama-openstack-1}
-\end{figure}
-
-\section{ConfiguraciÃ³n OSA}
-En esta secciÃ³n se presentan las configuraciones y conceptos mÃ¡s relevantes del nodo Deploy a tener en cuenta durante un despliegue de Openstack utilizando Ansible. Estas incluyen las convenciones de directorios empleadas, la configuraciÃ³n estÃ¡ndar y el significado del contenido de los archivos que deben ser modificados.
-
-\subsection{Convenciones}
-\begin{itemize}
-	\item El repositorio de OSA se clona generalmente en el directorio \path{/opt/openstack-ansible}.
-	\item Los roles de Ansible utilizados por defecto se encuentran en el directorio \path{/etc/ansible/roles} los cuales son generados a partir del archivo \path{/opt/openstack-ansible/ansible-role-requirements.yml} mediante la ejecuciÃ³n del \path{script bootstrap-ansible.sh}. 
-	\item Las configuraciones realizadas por el administrador son indicadas en el directorio \path{/etc/openstack_deploy}.
-\end{itemize}
-
-\subsection{Inventario}
-Define las especificaciones de los hosts y contenedores dentro del ambiente actual de OpenStack. Esta informaciÃ³n se encuentra en el archivo \path{/etc/openstack-ansible/openstack_inventory.json}, generado a partir de los host groups, containers groups y components indicados en:
-\begin{itemize}
-	\item La estructura por defecto almacenada en \path{/opt/openstack-ansible/inventory/env.d}
-	\item Lo configurado por el administrador dentro de \path{/etc/openstack_deploy/} en:
-	\begin{itemize}
-		\item El archivo \path{openstack_user_config.yml}
-		\item El directorio \path{conf.d/}
-		\item El directorio \path{env.d/}
-	\end{itemize}		 
-\end{itemize}
-
-Este archivo es considerado como referencia en cualquiera de los comandos asociados al despliegue de OSA por lo tanto nunca debe ser eliminado o modificado en un ambiente de producciÃ³n.
-
-Los components hacen referencia a los diferentes servicios que serÃ¡n instalados durante el despliegue de OpenStack, tanto en contenedores virtuales como directamente en los target host. Los containers groups agrupan estos components, determinando los potenciales contenedores a ser creados junto con sus especificaciones. 
-En las configuraciones realizadas en ambos directorios env.d/ se asocian los containers groups anteriores con los hosts groups, los cuales agrupan diversos target hosts. De esta forma se determina quÃ© servicio debe ser instalado en quÃ© target host.
-
-\subsection{openstack\_user\_config.yml}
-Es el principal archivo de configuraciÃ³n, creado por el operador de Openstack. Las especificaciones de cada secciÃ³n se detallan en \cite{openstack-user-config}.
 
diff --git a/docs/udelartex/tesis.lof b/docs/udelartex/tesis.lof
index 3e05ee8aea20594f950ff1a9bedb8fdff9c1c288..a45d7189b3c8561ed10e91f7d2c295cf1805c23f 100644
--- a/docs/udelartex/tesis.lof
+++ b/docs/udelartex/tesis.lof
@@ -19,92 +19,92 @@
 \contentsline {figure}{\numberline {4.7}{\ignorespaces Principales componentes de Cinder. ExtraÃdo de \cite {redhat-cinder}.\relax }}{29}{figure.caption.35}%
 \contentsline {figure}{\numberline {4.8}{\ignorespaces Arquitectura del mÃ³dulo Swift. ExtraÃda de \cite {openstack-storage-components}.\relax }}{31}{figure.caption.36}%
 \contentsline {figure}{\numberline {4.9}{\ignorespaces Arquitectura de Neutron. ExtraÃda de \cite {openstack-networking-book-1}.\relax }}{33}{figure.caption.40}%
-\contentsline {figure}{\numberline {4.10}{\ignorespaces Componentes de red en Openstack. \cite {openstack-container-networking}.\relax }}{37}{figure.caption.52}%
-\contentsline {figure}{\numberline {4.11}{\ignorespaces Diagrama de mÃºltiples interfaces de red. ExtraÃda de \cite {openstack-networking-architecture}.\relax }}{38}{figure.caption.56}%
-\contentsline {figure}{\numberline {4.12}{\ignorespaces Diagrama de bonds de mÃºltiples interfaces de red. ExtraÃda de \cite {openstack-networking-architecture}.\relax }}{39}{figure.caption.57}%
-\contentsline {figure}{\numberline {4.13}{\ignorespaces Despliegue de servicios OpenStack en contenedores. ExtraÃda de \cite {openstack-appendix-e}.\relax }}{40}{figure.caption.58}%
-\contentsline {figure}{\numberline {4.14}{\ignorespaces ExtraÃda de \cite {openstack-cookbook-book}\relax }}{41}{figure.caption.59}%
 \addvspace {10\p@ }
-\contentsline {figure}{\numberline {5.1}{\ignorespaces Acceso remoto al servidor renata.\relax }}{45}{figure.caption.60}%
-\contentsline {figure}{\numberline {5.2}{\ignorespaces Nueva conexiÃ³n en virt-manager.\relax }}{45}{figure.caption.61}%
-\contentsline {figure}{\numberline {5.3}{\ignorespaces ConfiguraciÃ³n de redes virtuales en virt-manager.\relax }}{47}{figure.caption.62}%
-\contentsline {figure}{\numberline {5.4}{\ignorespaces TÃºnel reverso y esquema de servidores.\relax }}{53}{figure.caption.76}%
-\contentsline {figure}{\numberline {5.5}{\ignorespaces Salida a Internet en los nodos de Openstack.\relax }}{54}{figure.caption.77}%
+\contentsline {figure}{\numberline {5.1}{\ignorespaces Componentes de red en Openstack. \cite {openstack-container-networking}.\relax }}{37}{figure.caption.52}%
+\contentsline {figure}{\numberline {5.2}{\ignorespaces Diagrama de mÃºltiples interfaces de red. ExtraÃda de \cite {openstack-networking-architecture}.\relax }}{39}{figure.caption.56}%
+\contentsline {figure}{\numberline {5.3}{\ignorespaces Diagrama de bonds de mÃºltiples interfaces de red. ExtraÃda de \cite {openstack-networking-architecture}.\relax }}{39}{figure.caption.57}%
+\contentsline {figure}{\numberline {5.4}{\ignorespaces Despliegue de servicios OpenStack en contenedores. ExtraÃda de \cite {openstack-appendix-e}.\relax }}{41}{figure.caption.58}%
+\contentsline {figure}{\numberline {5.5}{\ignorespaces ExtraÃda de \cite {openstack-cookbook-book}\relax }}{42}{figure.caption.59}%
 \addvspace {10\p@ }
-\contentsline {figure}{\numberline {6.1}{\ignorespaces Vista del login de Horizon.\relax }}{59}{figure.caption.78}%
-\contentsline {figure}{\numberline {6.2}{\ignorespaces CreaciÃ³n de un proyecto (1/2).\relax }}{60}{figure.caption.79}%
-\contentsline {figure}{\numberline {6.3}{\ignorespaces CreaciÃ³n de un proyecto (2/2).\relax }}{61}{figure.caption.80}%
-\contentsline {figure}{\numberline {6.4}{\ignorespaces CreaciÃ³n de un usuario.\relax }}{62}{figure.caption.81}%
-\contentsline {figure}{\numberline {6.5}{\ignorespaces CreaciÃ³n de un flavor (1/2).\relax }}{63}{figure.caption.82}%
-\contentsline {figure}{\numberline {6.6}{\ignorespaces CreaciÃ³n de un flavor (2/2).\relax }}{63}{figure.caption.83}%
-\contentsline {figure}{\numberline {6.7}{\ignorespaces CreaciÃ³n de una red provider (1/2).\relax }}{64}{figure.caption.84}%
-\contentsline {figure}{\numberline {6.8}{\ignorespaces CreaciÃ³n de una red provider (2/2).\relax }}{65}{figure.caption.85}%
-\contentsline {figure}{\numberline {6.9}{\ignorespaces CreaciÃ³n de una imagen (1/2).\relax }}{66}{figure.caption.86}%
-\contentsline {figure}{\numberline {6.10}{\ignorespaces CreaciÃ³n de una imagen (2/2).\relax }}{67}{figure.caption.87}%
-\contentsline {figure}{\numberline {6.11}{\ignorespaces CreaciÃ³n de una red (1/3).\relax }}{68}{figure.caption.88}%
-\contentsline {figure}{\numberline {6.12}{\ignorespaces CreaciÃ³n de una red (2/3).\relax }}{68}{figure.caption.89}%
-\contentsline {figure}{\numberline {6.13}{\ignorespaces CreaciÃ³n de una red (3/3).\relax }}{69}{figure.caption.90}%
-\contentsline {figure}{\numberline {6.14}{\ignorespaces CreaciÃ³n de un router.\relax }}{69}{figure.caption.91}%
-\contentsline {figure}{\numberline {6.15}{\ignorespaces CreaciÃ³n de una interfaz en un router.\relax }}{70}{figure.caption.92}%
-\contentsline {figure}{\numberline {6.16}{\ignorespaces CreaciÃ³n de una key pair.\relax }}{70}{figure.caption.93}%
-\contentsline {figure}{\numberline {6.17}{\ignorespaces Lanzar una nueva instancia (1/5).\relax }}{71}{figure.caption.94}%
-\contentsline {figure}{\numberline {6.18}{\ignorespaces Lanzar una nueva instancia (2/5).\relax }}{71}{figure.caption.95}%
-\contentsline {figure}{\numberline {6.19}{\ignorespaces Lanzar una nueva instancia (3/5).\relax }}{72}{figure.caption.96}%
-\contentsline {figure}{\numberline {6.20}{\ignorespaces Lanzar una nueva instancia (4/5).\relax }}{72}{figure.caption.97}%
-\contentsline {figure}{\numberline {6.21}{\ignorespaces Lanzar una nueva instancia (5/5).\relax }}{73}{figure.caption.98}%
-\contentsline {figure}{\numberline {6.22}{\ignorespaces AsignaciÃ³n de floating IP.\relax }}{74}{figure.caption.99}%
-\contentsline {figure}{\numberline {6.23}{\ignorespaces AsociaciÃ³n de floating IP.\relax }}{75}{figure.caption.100}%
-\contentsline {figure}{\numberline {6.24}{\ignorespaces Reglas security group por defecto.\relax }}{75}{figure.caption.101}%
-\contentsline {figure}{\numberline {6.25}{\ignorespaces Agregar regla para trÃ¡fico ICMP.\relax }}{76}{figure.caption.102}%
-\contentsline {figure}{\numberline {6.26}{\ignorespaces Agregar regla para trÃ¡fico SSH.\relax }}{76}{figure.caption.103}%
+\contentsline {figure}{\numberline {6.1}{\ignorespaces Arquitectura diseÃ±ada.\relax }}{49}{figure.caption.60}%
+\contentsline {figure}{\numberline {6.2}{\ignorespaces Arquitectura diseÃ±ada para instalaciÃ³n Stein\relax }}{52}{figure.caption.61}%
+\contentsline {figure}{\numberline {6.3}{\ignorespaces Acceso remoto al servidor renata.\relax }}{54}{figure.caption.62}%
+\contentsline {figure}{\numberline {6.4}{\ignorespaces TÃºnel reverso y esquema de servidores.\relax }}{55}{figure.caption.63}%
+\contentsline {figure}{\numberline {6.5}{\ignorespaces Salida a Internet en los nodos de Openstack.\relax }}{56}{figure.caption.64}%
 \addvspace {10\p@ }
+\contentsline {figure}{\numberline {7.1}{\ignorespaces Vista del login de Horizon.\relax }}{58}{figure.caption.65}%
+\contentsline {figure}{\numberline {7.2}{\ignorespaces CreaciÃ³n de un proyecto (1/2).\relax }}{59}{figure.caption.66}%
+\contentsline {figure}{\numberline {7.3}{\ignorespaces CreaciÃ³n de un proyecto (2/2).\relax }}{60}{figure.caption.67}%
+\contentsline {figure}{\numberline {7.4}{\ignorespaces CreaciÃ³n de un usuario.\relax }}{61}{figure.caption.68}%
+\contentsline {figure}{\numberline {7.5}{\ignorespaces CreaciÃ³n de un flavor (1/2).\relax }}{62}{figure.caption.69}%
+\contentsline {figure}{\numberline {7.6}{\ignorespaces CreaciÃ³n de un flavor (2/2).\relax }}{62}{figure.caption.70}%
+\contentsline {figure}{\numberline {7.7}{\ignorespaces CreaciÃ³n de una red provider (1/2).\relax }}{63}{figure.caption.71}%
+\contentsline {figure}{\numberline {7.8}{\ignorespaces CreaciÃ³n de una red provider (2/2).\relax }}{64}{figure.caption.72}%
+\contentsline {figure}{\numberline {7.9}{\ignorespaces CreaciÃ³n de una imagen (1/2).\relax }}{65}{figure.caption.73}%
+\contentsline {figure}{\numberline {7.10}{\ignorespaces CreaciÃ³n de una imagen (2/2).\relax }}{66}{figure.caption.74}%
+\contentsline {figure}{\numberline {7.11}{\ignorespaces CreaciÃ³n de una red (1/3).\relax }}{67}{figure.caption.75}%
+\contentsline {figure}{\numberline {7.12}{\ignorespaces CreaciÃ³n de una red (2/3).\relax }}{67}{figure.caption.76}%
+\contentsline {figure}{\numberline {7.13}{\ignorespaces CreaciÃ³n de una red (3/3).\relax }}{68}{figure.caption.77}%
+\contentsline {figure}{\numberline {7.14}{\ignorespaces CreaciÃ³n de un router.\relax }}{68}{figure.caption.78}%
+\contentsline {figure}{\numberline {7.15}{\ignorespaces CreaciÃ³n de una interfaz en un router.\relax }}{69}{figure.caption.79}%
+\contentsline {figure}{\numberline {7.16}{\ignorespaces CreaciÃ³n de una key pair.\relax }}{69}{figure.caption.80}%
+\contentsline {figure}{\numberline {7.17}{\ignorespaces Lanzar una nueva instancia (1/5).\relax }}{70}{figure.caption.81}%
+\contentsline {figure}{\numberline {7.18}{\ignorespaces Lanzar una nueva instancia (2/5).\relax }}{70}{figure.caption.82}%
+\contentsline {figure}{\numberline {7.19}{\ignorespaces Lanzar una nueva instancia (3/5).\relax }}{71}{figure.caption.83}%
+\contentsline {figure}{\numberline {7.20}{\ignorespaces Lanzar una nueva instancia (4/5).\relax }}{71}{figure.caption.84}%
+\contentsline {figure}{\numberline {7.21}{\ignorespaces Lanzar una nueva instancia (5/5).\relax }}{72}{figure.caption.85}%
+\contentsline {figure}{\numberline {7.22}{\ignorespaces AsignaciÃ³n de floating IP.\relax }}{73}{figure.caption.86}%
+\contentsline {figure}{\numberline {7.23}{\ignorespaces AsociaciÃ³n de floating IP.\relax }}{74}{figure.caption.87}%
+\contentsline {figure}{\numberline {7.24}{\ignorespaces Reglas security group por defecto.\relax }}{74}{figure.caption.88}%
+\contentsline {figure}{\numberline {7.25}{\ignorespaces Agregar regla para trÃ¡fico ICMP.\relax }}{75}{figure.caption.89}%
+\contentsline {figure}{\numberline {7.26}{\ignorespaces Agregar regla para trÃ¡fico SSH.\relax }}{75}{figure.caption.90}%
 \addvspace {10\p@ }
-\contentsline {figure}{\numberline {8.1}{\ignorespaces Diagrama de arquitectura para el escenario 1 de Linux Bridge\relax }}{90}{figure.caption.122}%
-\contentsline {figure}{\numberline {8.2}{\ignorespaces Paquete ARP request capturado en la interfaz eth0 de la instancia 1\relax }}{95}{figure.caption.125}%
-\contentsline {figure}{\numberline {8.3}{\ignorespaces Paquete ARP request encapsulado en VXLAN capturado en la interfaz br-vxlan del nodo de cÃ³mputo 1\relax }}{95}{figure.caption.126}%
-\contentsline {figure}{\numberline {8.4}{\ignorespaces Paquete ARP reply encapsulado en VXLAN capturado en la interfaz br-vxlan del nodo de cÃ³mputo 1\relax }}{97}{figure.caption.127}%
-\contentsline {figure}{\numberline {8.5}{\ignorespaces Paquete ARP reply capturado en la interfaz eth0 de la instancia 1\relax }}{98}{figure.caption.128}%
-\contentsline {figure}{\numberline {8.6}{\ignorespaces Paquete ICMP request capturado en la interfaz eth0 de la instancia 1\relax }}{98}{figure.caption.130}%
-\contentsline {figure}{\numberline {8.7}{\ignorespaces Paquete ICMP request encapsulado en VXLAN capturado en la interfaz br-vxlan del nodo de cÃ³mputo 1\relax }}{99}{figure.caption.131}%
-\contentsline {figure}{\numberline {8.8}{\ignorespaces Diagrama de arquitectura para el escenario 2 de Linux Bridge\relax }}{100}{figure.caption.133}%
-\contentsline {figure}{\numberline {8.9}{\ignorespaces Paquete ICMP echo request encapsulado en VXLAN capturado en la interfaz br-vxlan en el nodo de cÃ³mputo 1\relax }}{107}{figure.caption.137}%
-\contentsline {figure}{\numberline {8.10}{\ignorespaces Paquete ICMP echo request encapsulado en VXLAN capturado en la interfaz br-vxlan en el nodo de cÃ³mputo 2\relax }}{108}{figure.caption.141}%
-\contentsline {figure}{\numberline {8.11}{\ignorespaces Diagrama de arquitectura para el escenario 3 de Linux Bridge\relax }}{108}{figure.caption.143}%
-\contentsline {figure}{\numberline {8.12}{\ignorespaces Paquete ICMP echo request encapsulado en VXLAN capturado en la interfaz br-vxlan en el nodo de cÃ³mputo 1\relax }}{113}{figure.caption.147}%
-\contentsline {figure}{\numberline {8.13}{\ignorespaces Paquete ARP request taggeado con el VLAN ID 100 capturado en la interfaz br-vlan en el nodo de red\relax }}{114}{figure.caption.150}%
-\contentsline {figure}{\numberline {8.14}{\ignorespaces Paquete ICMP echo request capturado en la interfaz br-vlan del nodo de red\relax }}{115}{figure.caption.152}%
-\contentsline {figure}{\numberline {8.15}{\ignorespaces Diagrama de arquitectura para el escenario 4 de Linux Bridge\relax }}{116}{figure.caption.154}%
-\contentsline {figure}{\numberline {8.16}{\ignorespaces Paquete ICMP echo request taggeado con el VLAN ID 100 capturado en la interfaz eth3 del router fÃsico\relax }}{119}{figure.caption.158}%
-\contentsline {figure}{\numberline {8.17}{\ignorespaces Paquete ICMP echo request capturado en la interfaz qg del router de Neutron\relax }}{119}{figure.caption.159}%
-\contentsline {figure}{\numberline {8.18}{\ignorespaces Paquete ICMP echo request capturado en la interfaz qr del router de Neutron\relax }}{120}{figure.caption.162}%
-\contentsline {figure}{\numberline {8.19}{\ignorespaces Diagrama de componentes de Open vSwitch\relax }}{121}{figure.caption.164}%
-\contentsline {figure}{\numberline {8.20}{\ignorespaces Diagrama de arquitectura para el escenario 1 de Open vSwitch\relax }}{125}{figure.caption.165}%
-\contentsline {figure}{\numberline {8.21}{\ignorespaces Paquete ARP request capturado en la interfaz eth0 de la instancia 1\relax }}{132}{figure.caption.168}%
-\contentsline {figure}{\numberline {8.22}{\ignorespaces ARP request encapsulado en VXLAN capturado en la interfaz br-vxlan del nodo de cÃ³mputo 1\relax }}{134}{figure.caption.169}%
-\contentsline {figure}{\numberline {8.23}{\ignorespaces ARP reply encapsulado en VXLAN capturado en la interfaz br-vxlan del nodo de cÃ³mputo 1\relax }}{138}{figure.caption.170}%
-\contentsline {figure}{\numberline {8.24}{\ignorespaces Paquete ARP reply capturado en la interfaz eth0 de la instancia 1\relax }}{139}{figure.caption.171}%
-\contentsline {figure}{\numberline {8.25}{\ignorespaces Paquete ICMP request capturado en la interfaz eth0 de la instancia 1\relax }}{139}{figure.caption.173}%
-\contentsline {figure}{\numberline {8.26}{\ignorespaces Paquete ICMP request encapsulado en VXLAN 19 capturado en el bridge br-vxlan en el nodo de cÃ³mputo 1\relax }}{141}{figure.caption.174}%
-\contentsline {figure}{\numberline {8.27}{\ignorespaces Diagrama de arquitectura para el escenario 2 de Open vSwitch\relax }}{142}{figure.caption.176}%
-\contentsline {figure}{\numberline {8.28}{\ignorespaces Paquete ICMP echo request encapsulado en VXLAN capturado en la interfaz br-vxlan en el nodo de cÃ³mputo 1\relax }}{147}{figure.caption.180}%
-\contentsline {figure}{\numberline {8.29}{\ignorespaces Paquete ICMP echo request encapsulado en VXLAN capturado en la interfaz br-vxlan en el nodo de cÃ³mputo 2\relax }}{148}{figure.caption.184}%
-\contentsline {figure}{\numberline {8.30}{\ignorespaces Diagrama de arquitectura para el escenario 3 de Open vSwitch\relax }}{149}{figure.caption.186}%
-\contentsline {figure}{\numberline {8.31}{\ignorespaces Paquete ICMP echo request encapsulado en VXLAN capturado en la interfaz br-vxlan en el nodo de cÃ³mputo 1\relax }}{153}{figure.caption.190}%
-\contentsline {figure}{\numberline {8.32}{\ignorespaces Paquete ARP request taggeado con el VLAN ID 100 capturado en la interfaz br-vlan en el nodo de red\relax }}{154}{figure.caption.193}%
-\contentsline {figure}{\numberline {8.33}{\ignorespaces Paquete ICMP echo request capturado en la interfaz br-vlan del nodo de red\relax }}{155}{figure.caption.195}%
-\contentsline {figure}{\numberline {8.34}{\ignorespaces Diagrama de arquitectura para el escenario 4 de Open vSwitch\relax }}{156}{figure.caption.197}%
-\contentsline {figure}{\numberline {8.35}{\ignorespaces Paquete ICMP echo request taggeado con el VLAN ID 100 capturado en la interfaz eth3 del router fÃsico\relax }}{159}{figure.caption.201}%
-\contentsline {figure}{\numberline {8.36}{\ignorespaces Paquete ICMP echo request capturado en la interfaz qg del router de Neutron\relax }}{159}{figure.caption.202}%
-\contentsline {figure}{\numberline {8.37}{\ignorespaces Paquete ICMP echo request capturado en la interfaz qr del router de Neutron\relax }}{160}{figure.caption.205}%
 \addvspace {10\p@ }
+\contentsline {figure}{\numberline {9.1}{\ignorespaces Diagrama de arquitectura para el escenario 1 de Linux Bridge\relax }}{89}{figure.caption.109}%
+\contentsline {figure}{\numberline {9.2}{\ignorespaces Paquete ARP request capturado en la interfaz eth0 de la instancia 1\relax }}{94}{figure.caption.112}%
+\contentsline {figure}{\numberline {9.3}{\ignorespaces Paquete ARP request encapsulado en VXLAN capturado en la interfaz br-vxlan del nodo de cÃ³mputo 1\relax }}{94}{figure.caption.113}%
+\contentsline {figure}{\numberline {9.4}{\ignorespaces Paquete ARP reply encapsulado en VXLAN capturado en la interfaz br-vxlan del nodo de cÃ³mputo 1\relax }}{96}{figure.caption.114}%
+\contentsline {figure}{\numberline {9.5}{\ignorespaces Paquete ARP reply capturado en la interfaz eth0 de la instancia 1\relax }}{97}{figure.caption.115}%
+\contentsline {figure}{\numberline {9.6}{\ignorespaces Paquete ICMP request capturado en la interfaz eth0 de la instancia 1\relax }}{97}{figure.caption.117}%
+\contentsline {figure}{\numberline {9.7}{\ignorespaces Paquete ICMP request encapsulado en VXLAN capturado en la interfaz br-vxlan del nodo de cÃ³mputo 1\relax }}{98}{figure.caption.118}%
+\contentsline {figure}{\numberline {9.8}{\ignorespaces Diagrama de arquitectura para el escenario 2 de Linux Bridge\relax }}{99}{figure.caption.120}%
+\contentsline {figure}{\numberline {9.9}{\ignorespaces Paquete ICMP echo request encapsulado en VXLAN capturado en la interfaz br-vxlan en el nodo de cÃ³mputo 1\relax }}{106}{figure.caption.124}%
+\contentsline {figure}{\numberline {9.10}{\ignorespaces Paquete ICMP echo request encapsulado en VXLAN capturado en la interfaz br-vxlan en el nodo de cÃ³mputo 2\relax }}{107}{figure.caption.128}%
+\contentsline {figure}{\numberline {9.11}{\ignorespaces Diagrama de arquitectura para el escenario 3 de Linux Bridge\relax }}{107}{figure.caption.130}%
+\contentsline {figure}{\numberline {9.12}{\ignorespaces Paquete ICMP echo request encapsulado en VXLAN capturado en la interfaz br-vxlan en el nodo de cÃ³mputo 1\relax }}{112}{figure.caption.134}%
+\contentsline {figure}{\numberline {9.13}{\ignorespaces Paquete ARP request taggeado con el VLAN ID 100 capturado en la interfaz br-vlan en el nodo de red\relax }}{113}{figure.caption.137}%
+\contentsline {figure}{\numberline {9.14}{\ignorespaces Paquete ICMP echo request capturado en la interfaz br-vlan del nodo de red\relax }}{114}{figure.caption.139}%
+\contentsline {figure}{\numberline {9.15}{\ignorespaces Diagrama de arquitectura para el escenario 4 de Linux Bridge\relax }}{115}{figure.caption.141}%
+\contentsline {figure}{\numberline {9.16}{\ignorespaces Paquete ICMP echo request taggeado con el VLAN ID 100 capturado en la interfaz eth3 del router fÃsico\relax }}{118}{figure.caption.145}%
+\contentsline {figure}{\numberline {9.17}{\ignorespaces Paquete ICMP echo request capturado en la interfaz qg del router de Neutron\relax }}{118}{figure.caption.146}%
+\contentsline {figure}{\numberline {9.18}{\ignorespaces Paquete ICMP echo request capturado en la interfaz qr del router de Neutron\relax }}{119}{figure.caption.149}%
+\contentsline {figure}{\numberline {9.19}{\ignorespaces Diagrama de componentes de Open vSwitch\relax }}{120}{figure.caption.151}%
+\contentsline {figure}{\numberline {9.20}{\ignorespaces Diagrama de arquitectura para el escenario 1 de Open vSwitch\relax }}{124}{figure.caption.152}%
+\contentsline {figure}{\numberline {9.21}{\ignorespaces Paquete ARP request capturado en la interfaz eth0 de la instancia 1\relax }}{131}{figure.caption.155}%
+\contentsline {figure}{\numberline {9.22}{\ignorespaces ARP request encapsulado en VXLAN capturado en la interfaz br-vxlan del nodo de cÃ³mputo 1\relax }}{133}{figure.caption.156}%
+\contentsline {figure}{\numberline {9.23}{\ignorespaces ARP reply encapsulado en VXLAN capturado en la interfaz br-vxlan del nodo de cÃ³mputo 1\relax }}{137}{figure.caption.157}%
+\contentsline {figure}{\numberline {9.24}{\ignorespaces Paquete ARP reply capturado en la interfaz eth0 de la instancia 1\relax }}{138}{figure.caption.158}%
+\contentsline {figure}{\numberline {9.25}{\ignorespaces Paquete ICMP request capturado en la interfaz eth0 de la instancia 1\relax }}{138}{figure.caption.160}%
+\contentsline {figure}{\numberline {9.26}{\ignorespaces Paquete ICMP request encapsulado en VXLAN 19 capturado en el bridge br-vxlan en el nodo de cÃ³mputo 1\relax }}{140}{figure.caption.161}%
+\contentsline {figure}{\numberline {9.27}{\ignorespaces Diagrama de arquitectura para el escenario 2 de Open vSwitch\relax }}{141}{figure.caption.163}%
+\contentsline {figure}{\numberline {9.28}{\ignorespaces Paquete ICMP echo request encapsulado en VXLAN capturado en la interfaz br-vxlan en el nodo de cÃ³mputo 1\relax }}{146}{figure.caption.167}%
+\contentsline {figure}{\numberline {9.29}{\ignorespaces Paquete ICMP echo request encapsulado en VXLAN capturado en la interfaz br-vxlan en el nodo de cÃ³mputo 2\relax }}{147}{figure.caption.171}%
+\contentsline {figure}{\numberline {9.30}{\ignorespaces Diagrama de arquitectura para el escenario 3 de Open vSwitch\relax }}{148}{figure.caption.173}%
+\contentsline {figure}{\numberline {9.31}{\ignorespaces Paquete ICMP echo request encapsulado en VXLAN capturado en la interfaz br-vxlan en el nodo de cÃ³mputo 1\relax }}{152}{figure.caption.177}%
+\contentsline {figure}{\numberline {9.32}{\ignorespaces Paquete ARP request taggeado con el VLAN ID 100 capturado en la interfaz br-vlan en el nodo de red\relax }}{153}{figure.caption.180}%
+\contentsline {figure}{\numberline {9.33}{\ignorespaces Paquete ICMP echo request capturado en la interfaz br-vlan del nodo de red\relax }}{154}{figure.caption.182}%
+\contentsline {figure}{\numberline {9.34}{\ignorespaces Diagrama de arquitectura para el escenario 4 de Open vSwitch\relax }}{155}{figure.caption.184}%
+\contentsline {figure}{\numberline {9.35}{\ignorespaces Paquete ICMP echo request taggeado con el VLAN ID 100 capturado en la interfaz eth3 del router fÃsico\relax }}{158}{figure.caption.188}%
+\contentsline {figure}{\numberline {9.36}{\ignorespaces Paquete ICMP echo request capturado en la interfaz qg del router de Neutron\relax }}{158}{figure.caption.189}%
+\contentsline {figure}{\numberline {9.37}{\ignorespaces Paquete ICMP echo request capturado en la interfaz qr del router de Neutron\relax }}{159}{figure.caption.192}%
 \addvspace {10\p@ }
 \addvspace {10\p@ }
 \addvspace {10\p@ }
-\contentsline {figure}{\numberline {2.1}{\ignorespaces Arquitectura diseÃ±ada para instalaciÃ³n Stein\relax }}{174}{figure.caption.209}%
+\contentsline {figure}{\numberline {1.1}{\ignorespaces Arquitectura diseÃ±ada para desarrollo\relax }}{172}{figure.caption.196}%
+\contentsline {figure}{\numberline {1.2}{\ignorespaces Arquitectura diseÃ±ada para producciÃ³n\relax }}{173}{figure.caption.197}%
 \addvspace {10\p@ }
 \addvspace {10\p@ }
-\contentsline {figure}{\numberline {1.1}{\ignorespaces Arquitectura diseÃ±ada.\relax }}{178}{figure.caption.211}%
-\contentsline {figure}{\numberline {1.2}{\ignorespaces DisposiciÃ³n de componentes en Neutron. ExtraÃda de \cite {openstack-networking-book-4}.\relax }}{179}{figure.caption.212}%
 \addvspace {10\p@ }
-\contentsline {figure}{\numberline {2.1}{\ignorespaces Arquitectura diseÃ±ada para instalaciÃ³n Stein\relax }}{200}{figure.caption.214}%
+\contentsline {figure}{\numberline {3.1}{\ignorespaces Nueva conexiÃ³n en virt-manager.\relax }}{219}{figure.caption.200}%
+\contentsline {figure}{\numberline {3.2}{\ignorespaces ConfiguraciÃ³n de redes virtuales en virt-manager.\relax }}{220}{figure.caption.201}%
 \contentsfinish 
diff --git a/docs/udelartex/tesis.lot b/docs/udelartex/tesis.lot
index 9a6cc7914943e5c164c4595f68c73f70bbf5d785..9f90e3de51c76bab1b2f31f5a75e96a3e660b144 100644
--- a/docs/udelartex/tesis.lot
+++ b/docs/udelartex/tesis.lot
@@ -9,25 +9,25 @@
 \addvspace {10\p@ }
 \addvspace {10\p@ }
 \addvspace {10\p@ }
-\contentsline {table}{\numberline {8.1}{\ignorespaces Sabores creados para anÃ¡lisis de red\relax }}{84}{table.caption.104}%
-\contentsline {table}{\numberline {8.2}{\ignorespaces ImÃ¡genes creadas para anÃ¡lisis de red\relax }}{84}{table.caption.105}%
-\contentsline {table}{\numberline {8.3}{\ignorespaces Redes provider creadas para anÃ¡lisis de red\relax }}{85}{table.caption.106}%
-\contentsline {table}{\numberline {8.4}{\ignorespaces Subredes provider creadas para anÃ¡lisis de red\relax }}{85}{table.caption.107}%
-\contentsline {table}{\numberline {8.5}{\ignorespaces Escenario 1: detalles de la subred 1\relax }}{86}{table.caption.108}%
-\contentsline {table}{\numberline {8.6}{\ignorespaces Escenario 1: detalles de las instancias\relax }}{86}{table.caption.109}%
-\contentsline {table}{\numberline {8.7}{\ignorespaces Escenario 2: detalles de la subred 1\relax }}{87}{table.caption.110}%
-\contentsline {table}{\numberline {8.8}{\ignorespaces Escenario 2: detalles de la subred 2\relax }}{87}{table.caption.111}%
-\contentsline {table}{\numberline {8.9}{\ignorespaces Escenario 2: detalles de las instancias\relax }}{87}{table.caption.112}%
-\contentsline {table}{\numberline {8.10}{\ignorespaces Escenario 2: detalles del router\relax }}{87}{table.caption.113}%
-\contentsline {table}{\numberline {8.11}{\ignorespaces Escenario 3: detalles de la subred 1\relax }}{88}{table.caption.114}%
-\contentsline {table}{\numberline {8.12}{\ignorespaces Escenario 3: detalles de la subred provider vlan\relax }}{88}{table.caption.115}%
-\contentsline {table}{\numberline {8.13}{\ignorespaces Escenario 3: detalles de las instancias\relax }}{88}{table.caption.116}%
-\contentsline {table}{\numberline {8.14}{\ignorespaces Escenario 3: detalles del router\relax }}{88}{table.caption.117}%
-\contentsline {table}{\numberline {8.15}{\ignorespaces Escenario 4: detalles de la subred 1\relax }}{89}{table.caption.118}%
-\contentsline {table}{\numberline {8.16}{\ignorespaces Escenario 4: detalles de la subred provider vlan\relax }}{90}{table.caption.119}%
-\contentsline {table}{\numberline {8.17}{\ignorespaces Escenario 4: detalles de las instancias\relax }}{90}{table.caption.120}%
-\contentsline {table}{\numberline {8.18}{\ignorespaces Escenario 4: detalles del router\relax }}{90}{table.caption.121}%
 \addvspace {10\p@ }
+\contentsline {table}{\numberline {9.1}{\ignorespaces Sabores creados para anÃ¡lisis de red\relax }}{83}{table.caption.91}%
+\contentsline {table}{\numberline {9.2}{\ignorespaces ImÃ¡genes creadas para anÃ¡lisis de red\relax }}{83}{table.caption.92}%
+\contentsline {table}{\numberline {9.3}{\ignorespaces Redes provider creadas para anÃ¡lisis de red\relax }}{84}{table.caption.93}%
+\contentsline {table}{\numberline {9.4}{\ignorespaces Subredes provider creadas para anÃ¡lisis de red\relax }}{84}{table.caption.94}%
+\contentsline {table}{\numberline {9.5}{\ignorespaces Escenario 1: detalles de la subred 1\relax }}{85}{table.caption.95}%
+\contentsline {table}{\numberline {9.6}{\ignorespaces Escenario 1: detalles de las instancias\relax }}{85}{table.caption.96}%
+\contentsline {table}{\numberline {9.7}{\ignorespaces Escenario 2: detalles de la subred 1\relax }}{86}{table.caption.97}%
+\contentsline {table}{\numberline {9.8}{\ignorespaces Escenario 2: detalles de la subred 2\relax }}{86}{table.caption.98}%
+\contentsline {table}{\numberline {9.9}{\ignorespaces Escenario 2: detalles de las instancias\relax }}{86}{table.caption.99}%
+\contentsline {table}{\numberline {9.10}{\ignorespaces Escenario 2: detalles del router\relax }}{86}{table.caption.100}%
+\contentsline {table}{\numberline {9.11}{\ignorespaces Escenario 3: detalles de la subred 1\relax }}{87}{table.caption.101}%
+\contentsline {table}{\numberline {9.12}{\ignorespaces Escenario 3: detalles de la subred provider vlan\relax }}{87}{table.caption.102}%
+\contentsline {table}{\numberline {9.13}{\ignorespaces Escenario 3: detalles de las instancias\relax }}{87}{table.caption.103}%
+\contentsline {table}{\numberline {9.14}{\ignorespaces Escenario 3: detalles del router\relax }}{87}{table.caption.104}%
+\contentsline {table}{\numberline {9.15}{\ignorespaces Escenario 4: detalles de la subred 1\relax }}{88}{table.caption.105}%
+\contentsline {table}{\numberline {9.16}{\ignorespaces Escenario 4: detalles de la subred provider vlan\relax }}{89}{table.caption.106}%
+\contentsline {table}{\numberline {9.17}{\ignorespaces Escenario 4: detalles de las instancias\relax }}{89}{table.caption.107}%
+\contentsline {table}{\numberline {9.18}{\ignorespaces Escenario 4: detalles del router\relax }}{89}{table.caption.108}%
 \addvspace {10\p@ }
 \addvspace {10\p@ }
 \addvspace {10\p@ }
diff --git a/docs/udelartex/tesis.out b/docs/udelartex/tesis.out
index 68c5e15a0f68a7cc25bdd39c3d09eb27694dfeb3..0beed708de5a48e5b05b60563df12b8b0270ced6 100644
--- a/docs/udelartex/tesis.out
+++ b/docs/udelartex/tesis.out
@@ -13,7 +13,7 @@
 \BOOKMARK [1][-]{section.3.7}{Backends de almacenamiento}{chapter.3}% 13
 \BOOKMARK [2][-]{subsection.3.7.1}{LVM}{section.3.7}% 14
 \BOOKMARK [2][-]{subsection.3.7.2}{Ceph}{section.3.7}% 15
-\BOOKMARK [0][-]{chapter.4}{Openstack}{}% 16
+\BOOKMARK [0][-]{chapter.4}{OpenStack}{}% 16
 \BOOKMARK [1][-]{section.4.1}{Origen y definici\363n}{chapter.4}% 17
 \BOOKMARK [1][-]{section.4.2}{M\363dulos Core}{chapter.4}% 18
 \BOOKMARK [2][-]{subsection.4.2.1}{Keystone}{section.4.2}% 19
@@ -26,87 +26,95 @@
 \BOOKMARK [1][-]{section.4.4}{Servicios de infraestructura}{chapter.4}% 26
 \BOOKMARK [1][-]{section.4.5}{M\351todos de instalaci\363n}{chapter.4}% 27
 \BOOKMARK [2][-]{subsection.4.5.1}{Ansible}{section.4.5}% 28
-\BOOKMARK [1][-]{section.4.6}{Arquitectura}{chapter.4}% 29
-\BOOKMARK [2][-]{subsection.4.6.1}{Arquitectura de red}{section.4.6}% 30
-\BOOKMARK [1][-]{section.4.7}{Configuraci\363n OSA}{chapter.4}% 31
-\BOOKMARK [2][-]{subsection.4.7.1}{Convenciones}{section.4.7}% 32
-\BOOKMARK [2][-]{subsection.4.7.2}{Inventario}{section.4.7}% 33
-\BOOKMARK [2][-]{subsection.4.7.3}{openstack\137user\137config.yml}{section.4.7}% 34
-\BOOKMARK [0][-]{chapter.5}{Dise\361o}{}% 35
-\BOOKMARK [1][-]{section.5.1}{Dise\361o de arquitectura}{chapter.5}% 36
-\BOOKMARK [1][-]{section.5.2}{Ambiente de trabajo}{chapter.5}% 37
-\BOOKMARK [2][-]{subsection.5.2.1}{Hardware utilizado}{section.5.2}% 38
-\BOOKMARK [2][-]{subsection.5.2.2}{Conexi\363n remota hacia el servidor renata}{section.5.2}% 39
-\BOOKMARK [2][-]{subsection.5.2.3}{Virtualizaci\363n con KVM}{section.5.2}% 40
-\BOOKMARK [2][-]{subsection.5.2.4}{Especificaciones servidor renata}{section.5.2}% 41
-\BOOKMARK [2][-]{subsection.5.2.5}{Acceso al exterior desde nodos}{section.5.2}% 42
-\BOOKMARK [1][-]{section.5.3}{Ejecuci\363n de playbooks}{chapter.5}% 43
-\BOOKMARK [1][-]{section.5.4}{Verificaci\363n}{chapter.5}% 44
-\BOOKMARK [0][-]{chapter.6}{Interaccci\363n}{}% 45
-\BOOKMARK [1][-]{section.6.1}{Configuraciones de administrador}{chapter.6}% 46
-\BOOKMARK [1][-]{section.6.2}{Interacci\363n de un usuario}{chapter.6}% 47
-\BOOKMARK [1][-]{section.6.3}{Acceso a una instancia}{chapter.6}% 48
-\BOOKMARK [2][-]{subsection.6.3.1}{Por SPICE}{section.6.3}% 49
-\BOOKMARK [2][-]{subsection.6.3.2}{Por SSH}{section.6.3}% 50
-\BOOKMARK [2][-]{subsection.6.3.3}{Por virsh}{section.6.3}% 51
-\BOOKMARK [0][-]{chapter.7}{Gesti\363n del Datacenter}{}% 52
-\BOOKMARK [1][-]{section.7.1}{Recuperaci\363n ante fallas}{chapter.7}% 53
-\BOOKMARK [2][-]{subsection.7.1.1}{Verificar el estado general de OpenStack}{section.7.1}% 54
-\BOOKMARK [2][-]{subsection.7.1.2}{Verificar estado de los componentes de la infraestructura}{section.7.1}% 55
-\BOOKMARK [2][-]{subsection.7.1.3}{Solucionar problemas}{section.7.1}% 56
-\BOOKMARK [2][-]{subsection.7.1.4}{Problemas con Ceph}{section.7.1}% 57
-\BOOKMARK [1][-]{section.7.2}{Agregar y remover nodos}{chapter.7}% 58
-\BOOKMARK [2][-]{subsection.7.2.1}{Agregar nodo de C\363mputo}{section.7.2}% 59
-\BOOKMARK [2][-]{subsection.7.2.2}{Eliminar un nodo de c\363mputo}{section.7.2}% 60
-\BOOKMARK [2][-]{subsection.7.2.3}{Infraestructura}{section.7.2}% 61
-\BOOKMARK [2][-]{subsection.7.2.4}{Storage}{section.7.2}% 62
-\BOOKMARK [1][-]{section.7.3}{Actualizar versi\363n}{chapter.7}% 63
-\BOOKMARK [0][-]{chapter.8}{An\341lisis del m\363dulo de red}{}% 64
-\BOOKMARK [1][-]{section.8.1}{Escenarios de prueba}{chapter.8}% 65
-\BOOKMARK [2][-]{subsection.8.1.1}{Escenario 1: tr\341fico este-oeste \(misma red tenant\)}{section.8.1}% 66
-\BOOKMARK [2][-]{subsection.8.1.2}{Escenario 2: tr\341fico este-oeste \(distintas redes tenant\)}{section.8.1}% 67
-\BOOKMARK [2][-]{subsection.8.1.3}{Escenario 3: tr\341fico norte-sur \(acceso hacia el exterior\)}{section.8.1}% 68
-\BOOKMARK [2][-]{subsection.8.1.4}{Escenario 4: tr\341fico norte-sur \(acceso desde el exterior\)}{section.8.1}% 69
-\BOOKMARK [1][-]{section.8.2}{Linux bridge}{chapter.8}% 70
-\BOOKMARK [2][-]{subsection.8.2.1}{Escenario 1}{section.8.2}% 71
-\BOOKMARK [2][-]{subsection.8.2.2}{Escenario 2}{section.8.2}% 72
-\BOOKMARK [2][-]{subsection.8.2.3}{Escenario 3}{section.8.2}% 73
-\BOOKMARK [2][-]{subsection.8.2.4}{Escenario 4}{section.8.2}% 74
-\BOOKMARK [1][-]{section.8.3}{Open vSwitch}{chapter.8}% 75
-\BOOKMARK [2][-]{subsection.8.3.1}{Escenario 1}{section.8.3}% 76
-\BOOKMARK [2][-]{subsection.8.3.2}{Escenario 2}{section.8.3}% 77
-\BOOKMARK [2][-]{subsection.8.3.3}{Escenario 3}{section.8.3}% 78
-\BOOKMARK [2][-]{subsection.8.3.4}{Escenario 4}{section.8.3}% 79
-\BOOKMARK [1][-]{section.8.4}{Comparativa de drivers}{chapter.8}% 80
-\BOOKMARK [1][-]{section.8.5}{Funcionalidades avanzadas}{chapter.8}% 81
-\BOOKMARK [2][-]{subsection.8.5.1}{Layer 3 High Availability}{section.8.5}% 82
-\BOOKMARK [0][-]{chapter.9}{Trabajo a futuro}{}% 83
-\BOOKMARK [0][-]{chapter.10}{Conclusiones}{}% 84
-\BOOKMARK [0][-]{chapter*.207}{Referencias bibliogr\341ficas}{}% 85
-\BOOKMARK [0][-]{chapter*.207}{Glosario}{}% 86
-\BOOKMARK [0][-]{section*.208}{Ap\351ndices}{}% 87
-\BOOKMARK [0][-]{appendix.Alph1}{Datos procesados}{}% 88
-\BOOKMARK [0][-]{appendix.Alph2}{Im\341genes remasterizadas}{}% 89
-\BOOKMARK [0][-]{appendix.Alph3}{Entrevistas desgrabadas}{}% 90
-\BOOKMARK [0][-]{section*.210}{Anexos}{}% 91
-\BOOKMARK [0][-]{appendix.Anexo.1}{Instalaci\363n versi\363n Queens}{}% 92
-\BOOKMARK [1][-]{section.Anexo.1.1}{Dise\361o de arquitectura}{appendix.Anexo.1}% 93
-\BOOKMARK [1][-]{section.Anexo.1.2}{Preparaci\363n de nodos}{appendix.Anexo.1}% 94
-\BOOKMARK [1][-]{section.Anexo.1.3}{Configuraci\363n}{appendix.Anexo.1}% 95
-\BOOKMARK [2][-]{subsection.Anexo.1.3.1}{Configuraci\363n claves SSH}{section.Anexo.1.3}% 96
-\BOOKMARK [2][-]{subsection.Anexo.1.3.2}{Archivos de configuraci\363n OSA}{section.Anexo.1.3}% 97
-\BOOKMARK [2][-]{subsection.Anexo.1.3.3}{Generaci\363n de claves}{section.Anexo.1.3}% 98
-\BOOKMARK [2][-]{subsection.Anexo.1.3.4}{Correcciones}{section.Anexo.1.3}% 99
-\BOOKMARK [1][-]{section.Anexo.1.4}{Inconvenientes}{appendix.Anexo.1}% 100
-\BOOKMARK [2][-]{subsection.Anexo.1.4.1}{Bloqueo de paquetes}{section.Anexo.1.4}% 101
-\BOOKMARK [2][-]{subsection.Anexo.1.4.2}{M\363dulo de seguridad SELinux}{section.Anexo.1.4}% 102
-\BOOKMARK [2][-]{subsection.Anexo.1.4.3}{Percona-release en playbook setup-infrastructure}{section.Anexo.1.4}% 103
-\BOOKMARK [2][-]{subsection.Anexo.1.4.4}{Subred reservada}{section.Anexo.1.4}% 104
-\BOOKMARK [2][-]{subsection.Anexo.1.4.5}{Versiones de librer\355as y SO}{section.Anexo.1.4}% 105
-\BOOKMARK [2][-]{subsection.Anexo.1.4.6}{Soporte para CentOS}{section.Anexo.1.4}% 106
-\BOOKMARK [0][-]{appendix.Anexo.2}{Instalaci\363n versi\363n Stein}{}% 107
-\BOOKMARK [1][-]{section.Anexo.2.1}{Dise\361o de arquitectura}{appendix.Anexo.2}% 108
-\BOOKMARK [1][-]{section.Anexo.2.2}{Preparaci\363n de nodos}{appendix.Anexo.2}% 109
-\BOOKMARK [1][-]{section.Anexo.2.3}{Configuraci\363n archivos OSA}{appendix.Anexo.2}% 110
-\BOOKMARK [1][-]{section.Anexo.2.4}{Ejecuci\363n de playbooks}{appendix.Anexo.2}% 111
-\BOOKMARK [1][-]{section.Anexo.2.5}{Cambios para driver OVS}{appendix.Anexo.2}% 112
+\BOOKMARK [0][-]{chapter.5}{OpenStack-Ansible}{}% 29
+\BOOKMARK [1][-]{section.5.1}{Arquitectura}{chapter.5}% 30
+\BOOKMARK [2][-]{subsection.5.1.1}{Arquitectura de red}{section.5.1}% 31
+\BOOKMARK [1][-]{section.5.2}{Configuraci\363n OSA}{chapter.5}% 32
+\BOOKMARK [2][-]{subsection.5.2.1}{Convenciones}{section.5.2}% 33
+\BOOKMARK [2][-]{subsection.5.2.2}{Inventario}{section.5.2}% 34
+\BOOKMARK [2][-]{subsection.5.2.3}{openstack\137user\137config.yml}{section.5.2}% 35
+\BOOKMARK [1][-]{section.5.3}{Ejecuci\363n de playbooks}{chapter.5}% 36
+\BOOKMARK [2][-]{subsection.5.3.1}{setup-hosts.yml}{section.5.3}% 37
+\BOOKMARK [2][-]{subsection.5.3.2}{install-haproxy.yml}{section.5.3}% 38
+\BOOKMARK [2][-]{subsection.5.3.3}{setup-infrastructure.yml}{section.5.3}% 39
+\BOOKMARK [2][-]{subsection.5.3.4}{setup-openstack.yml}{section.5.3}% 40
+\BOOKMARK [1][-]{section.5.4}{Verificaci\363n}{chapter.5}% 41
+\BOOKMARK [0][-]{chapter.6}{Dise\361o}{}% 42
+\BOOKMARK [1][-]{section.6.1}{Dise\361o de arquitectura}{chapter.6}% 43
+\BOOKMARK [2][-]{subsection.6.1.1}{Arquitectura desarrollo}{section.6.1}% 44
+\BOOKMARK [2][-]{subsection.6.1.2}{Arquitectura producci\363n}{section.6.1}% 45
+\BOOKMARK [2][-]{subsection.6.1.3}{Distribuci\363n de los servicios}{section.6.1}% 46
+\BOOKMARK [1][-]{section.6.2}{Ambiente de trabajo}{chapter.6}% 47
+\BOOKMARK [2][-]{subsection.6.2.1}{Hardware utilizado}{section.6.2}% 48
+\BOOKMARK [2][-]{subsection.6.2.2}{Conexi\363n remota hacia el servidor renata}{section.6.2}% 49
+\BOOKMARK [2][-]{subsection.6.2.3}{Especificaciones servidor renata}{section.6.2}% 50
+\BOOKMARK [2][-]{subsection.6.2.4}{Acceso al exterior desde nodos}{section.6.2}% 51
+\BOOKMARK [0][-]{chapter.7}{Interaccci\363n}{}% 52
+\BOOKMARK [1][-]{section.7.1}{Configuraciones de administrador}{chapter.7}% 53
+\BOOKMARK [1][-]{section.7.2}{Interacci\363n de un usuario}{chapter.7}% 54
+\BOOKMARK [1][-]{section.7.3}{Acceso a una instancia}{chapter.7}% 55
+\BOOKMARK [2][-]{subsection.7.3.1}{Por SPICE}{section.7.3}% 56
+\BOOKMARK [2][-]{subsection.7.3.2}{Por SSH}{section.7.3}% 57
+\BOOKMARK [2][-]{subsection.7.3.3}{Por virsh}{section.7.3}% 58
+\BOOKMARK [0][-]{chapter.8}{Gesti\363n del Datacenter}{}% 59
+\BOOKMARK [1][-]{section.8.1}{Recuperaci\363n ante fallas}{chapter.8}% 60
+\BOOKMARK [2][-]{subsection.8.1.1}{Verificar el estado general de OpenStack}{section.8.1}% 61
+\BOOKMARK [2][-]{subsection.8.1.2}{Verificar estado de los componentes de la infraestructura}{section.8.1}% 62
+\BOOKMARK [2][-]{subsection.8.1.3}{Solucionar problemas}{section.8.1}% 63
+\BOOKMARK [2][-]{subsection.8.1.4}{Problemas con Ceph}{section.8.1}% 64
+\BOOKMARK [1][-]{section.8.2}{Agregar y remover nodos}{chapter.8}% 65
+\BOOKMARK [2][-]{subsection.8.2.1}{Agregar nodo de C\363mputo}{section.8.2}% 66
+\BOOKMARK [2][-]{subsection.8.2.2}{Eliminar un nodo de c\363mputo}{section.8.2}% 67
+\BOOKMARK [2][-]{subsection.8.2.3}{Infraestructura}{section.8.2}% 68
+\BOOKMARK [2][-]{subsection.8.2.4}{Storage}{section.8.2}% 69
+\BOOKMARK [1][-]{section.8.3}{Actualizar versi\363n}{chapter.8}% 70
+\BOOKMARK [0][-]{chapter.9}{An\341lisis del m\363dulo de red}{}% 71
+\BOOKMARK [1][-]{section.9.1}{Escenarios de prueba}{chapter.9}% 72
+\BOOKMARK [2][-]{subsection.9.1.1}{Escenario 1: tr\341fico este-oeste \(misma red tenant\)}{section.9.1}% 73
+\BOOKMARK [2][-]{subsection.9.1.2}{Escenario 2: tr\341fico este-oeste \(distintas redes tenant\)}{section.9.1}% 74
+\BOOKMARK [2][-]{subsection.9.1.3}{Escenario 3: tr\341fico norte-sur \(acceso hacia el exterior\)}{section.9.1}% 75
+\BOOKMARK [2][-]{subsection.9.1.4}{Escenario 4: tr\341fico norte-sur \(acceso desde el exterior\)}{section.9.1}% 76
+\BOOKMARK [1][-]{section.9.2}{Linux bridge}{chapter.9}% 77
+\BOOKMARK [2][-]{subsection.9.2.1}{Escenario 1}{section.9.2}% 78
+\BOOKMARK [2][-]{subsection.9.2.2}{Escenario 2}{section.9.2}% 79
+\BOOKMARK [2][-]{subsection.9.2.3}{Escenario 3}{section.9.2}% 80
+\BOOKMARK [2][-]{subsection.9.2.4}{Escenario 4}{section.9.2}% 81
+\BOOKMARK [1][-]{section.9.3}{Open vSwitch}{chapter.9}% 82
+\BOOKMARK [2][-]{subsection.9.3.1}{Escenario 1}{section.9.3}% 83
+\BOOKMARK [2][-]{subsection.9.3.2}{Escenario 2}{section.9.3}% 84
+\BOOKMARK [2][-]{subsection.9.3.3}{Escenario 3}{section.9.3}% 85
+\BOOKMARK [2][-]{subsection.9.3.4}{Escenario 4}{section.9.3}% 86
+\BOOKMARK [1][-]{section.9.4}{Comparativa de drivers}{chapter.9}% 87
+\BOOKMARK [1][-]{section.9.5}{Funcionalidades avanzadas}{chapter.9}% 88
+\BOOKMARK [2][-]{subsection.9.5.1}{Layer 3 High Availability}{section.9.5}% 89
+\BOOKMARK [0][-]{chapter.10}{Trabajo a futuro}{}% 90
+\BOOKMARK [0][-]{chapter.11}{Conclusiones}{}% 91
+\BOOKMARK [0][-]{chapter*.194}{Referencias bibliogr\341ficas}{}% 92
+\BOOKMARK [0][-]{chapter*.194}{Glosario}{}% 93
+\BOOKMARK [0][-]{section*.195}{Ap\351ndices}{}% 94
+\BOOKMARK [0][-]{appendix.Alph1}{Im\341genes}{}% 95
+\BOOKMARK [0][-]{section*.198}{Anexos}{}% 96
+\BOOKMARK [0][-]{appendix.Anexo.1}{Instalaci\363n versi\363n Queens}{}% 97
+\BOOKMARK [1][-]{section.Anexo.1.1}{Preparaci\363n de nodos}{appendix.Anexo.1}% 98
+\BOOKMARK [1][-]{section.Anexo.1.2}{Configuraci\363n}{appendix.Anexo.1}% 99
+\BOOKMARK [2][-]{subsection.Anexo.1.2.1}{Configuraci\363n claves SSH}{section.Anexo.1.2}% 100
+\BOOKMARK [2][-]{subsection.Anexo.1.2.2}{Archivos de configuraci\363n OSA}{section.Anexo.1.2}% 101
+\BOOKMARK [2][-]{subsection.Anexo.1.2.3}{Generaci\363n de claves}{section.Anexo.1.2}% 102
+\BOOKMARK [2][-]{subsection.Anexo.1.2.4}{Correcciones}{section.Anexo.1.2}% 103
+\BOOKMARK [1][-]{section.Anexo.1.3}{Inconvenientes}{appendix.Anexo.1}% 104
+\BOOKMARK [2][-]{subsection.Anexo.1.3.1}{Bloqueo de paquetes}{section.Anexo.1.3}% 105
+\BOOKMARK [2][-]{subsection.Anexo.1.3.2}{M\363dulo de seguridad SELinux}{section.Anexo.1.3}% 106
+\BOOKMARK [2][-]{subsection.Anexo.1.3.3}{Percona-release en playbook setup-infrastructure}{section.Anexo.1.3}% 107
+\BOOKMARK [2][-]{subsection.Anexo.1.3.4}{Subred reservada}{section.Anexo.1.3}% 108
+\BOOKMARK [2][-]{subsection.Anexo.1.3.5}{Versiones de librer\355as y SO}{section.Anexo.1.3}% 109
+\BOOKMARK [2][-]{subsection.Anexo.1.3.6}{Soporte para CentOS}{section.Anexo.1.3}% 110
+\BOOKMARK [0][-]{appendix.Anexo.2}{Instalaci\363n versi\363n Stein}{}% 111
+\BOOKMARK [1][-]{section.Anexo.2.1}{Preparaci\363n de nodos}{appendix.Anexo.2}% 112
+\BOOKMARK [1][-]{section.Anexo.2.2}{Configuraci\363n archivos OSA}{appendix.Anexo.2}% 113
+\BOOKMARK [1][-]{section.Anexo.2.3}{Ejecuci\363n de playbooks}{appendix.Anexo.2}% 114
+\BOOKMARK [1][-]{section.Anexo.2.4}{Cambios para driver OVS}{appendix.Anexo.2}% 115
+\BOOKMARK [0][-]{appendix.Anexo.3}{Virtualizaci\363n con KVM}{}% 116
+\BOOKMARK [1][-]{section.Anexo.3.1}{Utilizaci\363n virt-manager}{appendix.Anexo.3}% 117
+\BOOKMARK [2][-]{subsection.Anexo.3.1.1}{Conexi\363n remota}{section.Anexo.3.1}% 118
+\BOOKMARK [2][-]{subsection.Anexo.3.1.2}{Creaci\363n de una red}{section.Anexo.3.1}% 119
+\BOOKMARK [2][-]{subsection.Anexo.3.1.3}{Crear nodo}{section.Anexo.3.1}% 120
diff --git a/docs/udelartex/tesis.pdf b/docs/udelartex/tesis.pdf
index 8ca20080c52093e4f15a72f413331fcc1fce64c2..5413ffa48443d220c804e1bb2efd68905c195daf 100644
Binary files a/docs/udelartex/tesis.pdf and b/docs/udelartex/tesis.pdf differ
diff --git a/docs/udelartex/tesis.synctex.gz b/docs/udelartex/tesis.synctex.gz
index 6f1a7a532cd151fd09c8d2a60eaf869031161ab5..55d697bf1528c04d7f9982464afc05ef07f6730b 100644
Binary files a/docs/udelartex/tesis.synctex.gz and b/docs/udelartex/tesis.synctex.gz differ
diff --git a/docs/udelartex/tesis.tex b/docs/udelartex/tesis.tex
index c29b7d1f8589a976b73ea99bbf5c76325f93568d..cc81c7aa909f883507bfdd6e16de598bc8cd6d7a 100644
--- a/docs/udelartex/tesis.tex
+++ b/docs/udelartex/tesis.tex
@@ -116,6 +116,7 @@ nopostdot, 											 %quita el punto final en los acrÃ³nimos         .
   \include{capitulos/planproyecto} 
   \include{capitulos/fundamentos} 
   \include{capitulos/openstack}
+  \include{capitulos/openstack-ansible}
   \include{capitulos/diseÃ±o}
   \include{capitulos/interaccion}
   \include{capitulos/gestion} 
@@ -133,15 +134,14 @@ nopostdot, 											 %quita el punto final en los acrÃ³nimos         .
   %
   \apenarabicnumbering
   \apenmatter				 % ApÃ©ndices, NO comentar
-  \input{apendice/apendice_A}
-  \input{apendice/apendice_B}
-  \input{apendice/apendice_C}
+  \input{apendice/imagenes}
   % Seguir copiando la linea de arriba para agregar mÃ¡s apÃ©ndices.
   %
   \anexarabicnumbering
   \anexmatter				 % Anexos, NO comentar
   \input{anexo/anexoQueens}
   \input{anexo/anexoStein}
+  \input{anexo/anexoVirtualizacionKVM}
 %  \input{anexo/anexo_B}
   % Seguir copiando la linea de arriba para agregar mÃ¡s anexos.
   % 
diff --git a/docs/udelartex/tesis.toc b/docs/udelartex/tesis.toc
index c2efa5e3f9f3fce1651970f96b244d250a3b65c4..677e87d886b4d635c69c27e27e9d16232acce3d9 100644
--- a/docs/udelartex/tesis.toc
+++ b/docs/udelartex/tesis.toc
@@ -25,7 +25,7 @@
 \contentsline {section}{\numberline {3.7}Backends de almacenamiento}{14}{section.3.7}%
 \contentsline {subsection}{\numberline {3.7.1}LVM}{14}{subsection.3.7.1}%
 \contentsline {subsection}{\numberline {3.7.2}Ceph}{14}{subsection.3.7.2}%
-\contentsline {chapter}{\numberline {4}Openstack}{17}{chapter.4}%
+\contentsline {chapter}{\numberline {4}OpenStack}{17}{chapter.4}%
 \contentsline {section}{\numberline {4.1}Origen y definiciÃ³n}{17}{section.4.1}%
 \contentsline {section}{\numberline {4.2}MÃ³dulos Core}{18}{section.4.2}%
 \contentsline {subsection}{\numberline {4.2.1}Keystone}{18}{subsection.4.2.1}%
@@ -63,209 +63,212 @@
 \contentsline {subparagraph}{MÃ³dulos}{36}{section*.49}%
 \contentsline {subparagraph}{Tarea}{36}{section*.50}%
 \contentsline {subparagraph}{Playbook}{36}{section*.51}%
-\contentsline {section}{\numberline {4.6}Arquitectura}{36}{section.4.6}%
-\contentsline {subsection}{\numberline {4.6.1}Arquitectura de red}{37}{subsection.4.6.1}%
-\contentsline {subparagraph}{Management Network}{37}{section*.53}%
-\contentsline {subparagraph}{Overlay Network}{37}{section*.54}%
+\contentsline {chapter}{\numberline {5}OpenStack-Ansible}{37}{chapter.5}%
+\contentsline {section}{\numberline {5.1}Arquitectura}{37}{section.5.1}%
+\contentsline {subsection}{\numberline {5.1.1}Arquitectura de red}{38}{subsection.5.1.1}%
+\contentsline {subparagraph}{Management Network}{38}{section*.53}%
+\contentsline {subparagraph}{Overlay Network}{38}{section*.54}%
 \contentsline {subparagraph}{Storage Network}{38}{section*.55}%
-\contentsline {subsubsection}{\numberline {4.6.1.1}Interfaces de red}{38}{subsubsection.4.6.1.1}%
-\contentsline {section}{\numberline {4.7}ConfiguraciÃ³n OSA}{39}{section.4.7}%
-\contentsline {subsection}{\numberline {4.7.1}Convenciones}{41}{subsection.4.7.1}%
-\contentsline {subsection}{\numberline {4.7.2}Inventario}{41}{subsection.4.7.2}%
-\contentsline {subsection}{\numberline {4.7.3}openstack\_user\_config.yml}{42}{subsection.4.7.3}%
-\contentsline {chapter}{\numberline {5}DiseÃ±o}{43}{chapter.5}%
-\contentsline {section}{\numberline {5.1}DiseÃ±o de arquitectura}{43}{section.5.1}%
-\contentsline {section}{\numberline {5.2}Ambiente de trabajo}{43}{section.5.2}%
-\contentsline {subsection}{\numberline {5.2.1}Hardware utilizado}{43}{subsection.5.2.1}%
-\contentsline {subsection}{\numberline {5.2.2}ConexiÃ³n remota hacia el servidor renata}{44}{subsection.5.2.2}%
-\contentsline {subsection}{\numberline {5.2.3}VirtualizaciÃ³n con KVM}{44}{subsection.5.2.3}%
-\contentsline {subsubsection}{\numberline {5.2.3.1}UtilizaciÃ³n virt-manager}{45}{subsubsection.5.2.3.1}%
-\contentsline {subsection}{\numberline {5.2.4}Especificaciones servidor renata}{53}{subsection.5.2.4}%
-\contentsline {subsection}{\numberline {5.2.5}Acceso al exterior desde nodos}{54}{subsection.5.2.5}%
-\contentsline {section}{\numberline {5.3}EjecuciÃ³n de playbooks}{55}{section.5.3}%
-\contentsline {subsubsection}{\numberline {5.3.0.1}setup-hosts.yml}{55}{subsubsection.5.3.0.1}%
-\contentsline {subsubsection}{\numberline {5.3.0.2}install-haproxy.yml}{55}{subsubsection.5.3.0.2}%
-\contentsline {subsubsection}{\numberline {5.3.0.3}setup-infrastructure.yml}{56}{subsubsection.5.3.0.3}%
-\contentsline {subsubsection}{\numberline {5.3.0.4}setup-openstack.yml}{56}{subsubsection.5.3.0.4}%
-\contentsline {section}{\numberline {5.4}VerificaciÃ³n}{56}{section.5.4}%
-\contentsline {chapter}{\numberline {6}InteraccciÃ³n}{58}{chapter.6}%
-\contentsline {section}{\numberline {6.1}Configuraciones de administrador}{59}{section.6.1}%
-\contentsline {subsubsection}{\numberline {6.1.0.1}Crear proyecto}{59}{subsubsection.6.1.0.1}%
-\contentsline {subsubsection}{\numberline {6.1.0.2}Crear usuario}{61}{subsubsection.6.1.0.2}%
-\contentsline {subsubsection}{\numberline {6.1.0.3}Crear flavor}{62}{subsubsection.6.1.0.3}%
-\contentsline {subsubsection}{\numberline {6.1.0.4}Crear provider network}{64}{subsubsection.6.1.0.4}%
-\contentsline {section}{\numberline {6.2}InteracciÃ³n de un usuario}{65}{section.6.2}%
-\contentsline {subsubsection}{\numberline {6.2.0.1}Crear imagen}{65}{subsubsection.6.2.0.1}%
-\contentsline {subsubsection}{\numberline {6.2.0.2}Crear red}{67}{subsubsection.6.2.0.2}%
-\contentsline {subsubsection}{\numberline {6.2.0.3}Crear router}{69}{subsubsection.6.2.0.3}%
-\contentsline {subsubsection}{\numberline {6.2.0.4}Crear interfaz de router}{70}{subsubsection.6.2.0.4}%
-\contentsline {subsubsection}{\numberline {6.2.0.5}Crear key pair}{70}{subsubsection.6.2.0.5}%
-\contentsline {subsubsection}{\numberline {6.2.0.6}Lanzar una instancia}{70}{subsubsection.6.2.0.6}%
-\contentsline {section}{\numberline {6.3}Acceso a una instancia}{73}{section.6.3}%
-\contentsline {subsection}{\numberline {6.3.1}Por SPICE}{73}{subsection.6.3.1}%
-\contentsline {subsection}{\numberline {6.3.2}Por SSH}{74}{subsection.6.3.2}%
-\contentsline {subsubsection}{\numberline {6.3.2.1}Asociar una Floating IP a la instancia}{74}{subsubsection.6.3.2.1}%
-\contentsline {subsubsection}{\numberline {6.3.2.2}Modificar security group}{75}{subsubsection.6.3.2.2}%
-\contentsline {subsubsection}{\numberline {6.3.2.3}SSH}{76}{subsubsection.6.3.2.3}%
-\contentsline {subsection}{\numberline {6.3.3}Por virsh}{77}{subsection.6.3.3}%
-\contentsline {chapter}{\numberline {7}GestiÃ³n del Datacenter}{78}{chapter.7}%
-\contentsline {section}{\numberline {7.1}RecuperaciÃ³n ante fallas}{78}{section.7.1}%
-\contentsline {subsection}{\numberline {7.1.1}Verificar el estado general de OpenStack}{78}{subsection.7.1.1}%
-\contentsline {subsection}{\numberline {7.1.2}Verificar estado de los componentes de la infraestructura}{79}{subsection.7.1.2}%
-\contentsline {subsection}{\numberline {7.1.3}Solucionar problemas}{79}{subsection.7.1.3}%
-\contentsline {subsection}{\numberline {7.1.4}Problemas con Ceph}{80}{subsection.7.1.4}%
-\contentsline {section}{\numberline {7.2}Agregar y remover nodos}{81}{section.7.2}%
-\contentsline {subsection}{\numberline {7.2.1}Agregar nodo de CÃ³mputo}{81}{subsection.7.2.1}%
-\contentsline {subsection}{\numberline {7.2.2}Eliminar un nodo de cÃ³mputo}{83}{subsection.7.2.2}%
-\contentsline {subsection}{\numberline {7.2.3}Infraestructura}{83}{subsection.7.2.3}%
-\contentsline {subsection}{\numberline {7.2.4}Storage}{83}{subsection.7.2.4}%
-\contentsline {section}{\numberline {7.3}Actualizar versiÃ³n}{83}{section.7.3}%
-\contentsline {chapter}{\numberline {8}AnÃ¡lisis del mÃ³dulo de red}{84}{chapter.8}%
-\contentsline {section}{\numberline {8.1}Escenarios de prueba}{84}{section.8.1}%
-\contentsline {subsection}{\numberline {8.1.1}Escenario 1: trÃ¡fico este-oeste (misma red tenant)}{85}{subsection.8.1.1}%
-\contentsline {subsubsection}{\numberline {8.1.1.1}ComposiciÃ³n del escenario}{85}{subsubsection.8.1.1.1}%
-\contentsline {subsection}{\numberline {8.1.2}Escenario 2: trÃ¡fico este-oeste (distintas redes tenant)}{86}{subsection.8.1.2}%
-\contentsline {subsubsection}{\numberline {8.1.2.1}ComposiciÃ³n del escenario}{86}{subsubsection.8.1.2.1}%
-\contentsline {subsection}{\numberline {8.1.3}Escenario 3: trÃ¡fico norte-sur (acceso hacia el exterior)}{87}{subsection.8.1.3}%
-\contentsline {subsubsection}{\numberline {8.1.3.1}ComposiciÃ³n del escenario}{88}{subsubsection.8.1.3.1}%
-\contentsline {subsection}{\numberline {8.1.4}Escenario 4: trÃ¡fico norte-sur (acceso desde el exterior)}{89}{subsection.8.1.4}%
-\contentsline {subsubsection}{\numberline {8.1.4.1}ComposiciÃ³n del escenario}{89}{subsubsection.8.1.4.1}%
-\contentsline {section}{\numberline {8.2}Linux bridge}{89}{section.8.2}%
-\contentsline {subsection}{\numberline {8.2.1}Escenario 1}{90}{subsection.8.2.1}%
-\contentsline {subsubsection}{\numberline {8.2.1.1}AnÃ¡lisis de componentes}{91}{subsubsection.8.2.1.1}%
-\contentsline {subsubsection}{\numberline {8.2.1.2}AnÃ¡lisis de trÃ¡fico}{94}{subsubsection.8.2.1.2}%
-\contentsline {subparagraph}{Paso 1}{94}{section*.123}%
-\contentsline {subparagraph}{Paso 2}{94}{section*.124}%
-\contentsline {subparagraph}{Paso 3}{98}{section*.129}%
-\contentsline {subparagraph}{Paso 4}{99}{section*.132}%
-\contentsline {subsection}{\numberline {8.2.2}Escenario 2}{100}{subsection.8.2.2}%
-\contentsline {subsubsection}{\numberline {8.2.2.1}AnÃ¡lisis de componentes}{100}{subsubsection.8.2.2.1}%
-\contentsline {subsubsection}{\numberline {8.2.2.2}AnÃ¡lisis de trÃ¡fico}{106}{subsubsection.8.2.2.2}%
-\contentsline {subparagraph}{Paso 1}{106}{section*.134}%
-\contentsline {subparagraph}{Paso 2}{106}{section*.135}%
-\contentsline {subparagraph}{Paso 3}{106}{section*.136}%
-\contentsline {subparagraph}{Paso 4}{107}{section*.138}%
-\contentsline {subparagraph}{Paso 5}{107}{section*.139}%
-\contentsline {subparagraph}{Paso 6}{107}{section*.140}%
-\contentsline {subparagraph}{Paso 7}{107}{section*.142}%
-\contentsline {subsection}{\numberline {8.2.3}Escenario 3}{108}{subsection.8.2.3}%
-\contentsline {subsubsection}{\numberline {8.2.3.1}AnÃ¡lisis de componentes}{109}{subsubsection.8.2.3.1}%
-\contentsline {subsubsection}{\numberline {8.2.3.2}AnÃ¡lisis de trÃ¡fico}{112}{subsubsection.8.2.3.2}%
-\contentsline {subparagraph}{Paso 1}{112}{section*.144}%
-\contentsline {subparagraph}{Paso 2}{112}{section*.145}%
-\contentsline {subparagraph}{Paso 3}{112}{section*.146}%
-\contentsline {subparagraph}{Paso 4}{113}{section*.148}%
-\contentsline {subparagraph}{Paso 5}{113}{section*.149}%
-\contentsline {subparagraph}{Paso 6}{114}{section*.151}%
-\contentsline {subparagraph}{Paso 7}{115}{section*.153}%
-\contentsline {subsection}{\numberline {8.2.4}Escenario 4}{116}{subsection.8.2.4}%
-\contentsline {subsubsection}{\numberline {8.2.4.1}AnÃ¡lisis de componentes}{116}{subsubsection.8.2.4.1}%
-\contentsline {subsubsection}{\numberline {8.2.4.2}AnÃ¡lisis de trÃ¡fico}{118}{subsubsection.8.2.4.2}%
-\contentsline {subparagraph}{Paso 1}{118}{section*.155}%
-\contentsline {subparagraph}{Paso 2}{118}{section*.156}%
-\contentsline {subparagraph}{Paso 3}{118}{section*.157}%
-\contentsline {subparagraph}{Paso 4}{119}{section*.160}%
-\contentsline {subparagraph}{Paso 5}{119}{section*.161}%
-\contentsline {subparagraph}{Paso 6}{120}{section*.163}%
-\contentsline {section}{\numberline {8.3}Open vSwitch}{120}{section.8.3}%
-\contentsline {subsubsection}{\numberline {8.3.0.1}Archivos de configuraciÃ³n}{122}{subsubsection.8.3.0.1}%
-\contentsline {subsection}{\numberline {8.3.1}Escenario 1}{125}{subsection.8.3.1}%
-\contentsline {subsubsection}{\numberline {8.3.1.1}AnÃ¡lisis de componentes}{125}{subsubsection.8.3.1.1}%
-\contentsline {subsubsection}{\numberline {8.3.1.2}AnÃ¡lisis de trÃ¡fico}{131}{subsubsection.8.3.1.2}%
-\contentsline {subparagraph}{Paso 1}{131}{section*.166}%
-\contentsline {subparagraph}{Paso 2}{132}{section*.167}%
-\contentsline {subparagraph}{Paso 3}{139}{section*.172}%
-\contentsline {subparagraph}{Paso 4}{141}{section*.175}%
-\contentsline {subsection}{\numberline {8.3.2}Escenario 2}{142}{subsection.8.3.2}%
-\contentsline {subsubsection}{\numberline {8.3.2.1}AnÃ¡lisis de componentes}{142}{subsubsection.8.3.2.1}%
-\contentsline {subsubsection}{\numberline {8.3.2.2}AnÃ¡lisis de trÃ¡fico}{146}{subsubsection.8.3.2.2}%
-\contentsline {subparagraph}{Paso 1}{147}{section*.177}%
-\contentsline {subparagraph}{Paso 2}{147}{section*.178}%
-\contentsline {subparagraph}{Paso 3}{147}{section*.179}%
-\contentsline {subparagraph}{Paso 4}{147}{section*.181}%
-\contentsline {subparagraph}{Paso 5}{148}{section*.182}%
-\contentsline {subparagraph}{Paso 6}{148}{section*.183}%
-\contentsline {subparagraph}{Paso 7}{148}{section*.185}%
-\contentsline {subsection}{\numberline {8.3.3}Escenario 3}{149}{subsection.8.3.3}%
-\contentsline {subsubsection}{\numberline {8.3.3.1}AnÃ¡lisis de componentes}{149}{subsubsection.8.3.3.1}%
-\contentsline {subsubsection}{\numberline {8.3.3.2}AnÃ¡lisis de trÃ¡fico}{152}{subsubsection.8.3.3.2}%
-\contentsline {subparagraph}{Paso 1}{152}{section*.187}%
-\contentsline {subparagraph}{Paso 2}{152}{section*.188}%
-\contentsline {subparagraph}{Paso 3}{153}{section*.189}%
-\contentsline {subparagraph}{Paso 4}{153}{section*.191}%
-\contentsline {subparagraph}{Paso 5}{153}{section*.192}%
-\contentsline {subparagraph}{Paso 6}{155}{section*.194}%
-\contentsline {subparagraph}{Paso 7}{155}{section*.196}%
-\contentsline {subsection}{\numberline {8.3.4}Escenario 4}{156}{subsection.8.3.4}%
-\contentsline {subsubsection}{\numberline {8.3.4.1}AnÃ¡lisis de componentes}{156}{subsubsection.8.3.4.1}%
-\contentsline {subsubsection}{\numberline {8.3.4.2}AnÃ¡lisis de trÃ¡fico}{157}{subsubsection.8.3.4.2}%
-\contentsline {subparagraph}{Paso 1}{158}{section*.198}%
-\contentsline {subparagraph}{Paso 2}{158}{section*.199}%
-\contentsline {subparagraph}{Paso 3}{158}{section*.200}%
-\contentsline {subparagraph}{Paso 4}{160}{section*.203}%
-\contentsline {subparagraph}{Paso 5}{160}{section*.204}%
-\contentsline {subparagraph}{Paso 6}{160}{section*.206}%
-\contentsline {section}{\numberline {8.4}Comparativa de drivers}{160}{section.8.4}%
-\contentsline {section}{\numberline {8.5}Funcionalidades avanzadas}{160}{section.8.5}%
-\contentsline {subsection}{\numberline {8.5.1}Layer 3 High Availability}{160}{subsection.8.5.1}%
-\contentsline {chapter}{\numberline {9}Trabajo a futuro}{161}{chapter.9}%
-\contentsline {subsubsection}{\numberline {9.0.0.1}Firewall}{161}{subsubsection.9.0.0.1}%
-\contentsline {subsubsection}{\numberline {9.0.0.2}Arquitectura segura}{161}{subsubsection.9.0.0.2}%
-\contentsline {subsubsection}{\numberline {9.0.0.3}Brindar conexiÃ³n directa a Internet}{162}{subsubsection.9.0.0.3}%
-\contentsline {subsubsection}{\numberline {9.0.0.4}GestiÃ³n de Openstack en operaciÃ³n}{162}{subsubsection.9.0.0.4}%
-\contentsline {chapter}{\numberline {10}Conclusiones}{163}{chapter.10}%
-\contentsline {chapter}{Referencias bibliogrÃ¡ficas}{164}{chapter*.207}%
-\contentsline {chapter}{Glosario}{170}{chapter*.207}%
-\contentsline {chapter}{\textbf {ApÃ©ndices}}{171}{section*.208}%
+\contentsline {subsubsection}{\numberline {5.1.1.1}Interfaces de red}{38}{subsubsection.5.1.1.1}%
+\contentsline {section}{\numberline {5.2}ConfiguraciÃ³n OSA}{40}{section.5.2}%
+\contentsline {subsection}{\numberline {5.2.1}Convenciones}{40}{subsection.5.2.1}%
+\contentsline {subsection}{\numberline {5.2.2}Inventario}{42}{subsection.5.2.2}%
+\contentsline {subsection}{\numberline {5.2.3}openstack\_user\_config.yml}{43}{subsection.5.2.3}%
+\contentsline {section}{\numberline {5.3}EjecuciÃ³n de playbooks}{43}{section.5.3}%
+\contentsline {subsection}{\numberline {5.3.1}setup-hosts.yml}{43}{subsection.5.3.1}%
+\contentsline {subsection}{\numberline {5.3.2}install-haproxy.yml}{44}{subsection.5.3.2}%
+\contentsline {subsection}{\numberline {5.3.3}setup-infrastructure.yml}{44}{subsection.5.3.3}%
+\contentsline {subsection}{\numberline {5.3.4}setup-openstack.yml}{44}{subsection.5.3.4}%
+\contentsline {section}{\numberline {5.4}VerificaciÃ³n}{45}{section.5.4}%
+\contentsline {chapter}{\numberline {6}DiseÃ±o}{47}{chapter.6}%
+\contentsline {section}{\numberline {6.1}DiseÃ±o de arquitectura}{47}{section.6.1}%
+\contentsline {subsection}{\numberline {6.1.1}Arquitectura desarrollo}{47}{subsection.6.1.1}%
+\contentsline {subsection}{\numberline {6.1.2}Arquitectura producciÃ³n}{50}{subsection.6.1.2}%
+\contentsline {subsection}{\numberline {6.1.3}DistribuciÃ³n de los servicios}{52}{subsection.6.1.3}%
+\contentsline {section}{\numberline {6.2}Ambiente de trabajo}{53}{section.6.2}%
+\contentsline {subsection}{\numberline {6.2.1}Hardware utilizado}{53}{subsection.6.2.1}%
+\contentsline {subsection}{\numberline {6.2.2}ConexiÃ³n remota hacia el servidor renata}{54}{subsection.6.2.2}%
+\contentsline {subsection}{\numberline {6.2.3}Especificaciones servidor renata}{54}{subsection.6.2.3}%
+\contentsline {subsection}{\numberline {6.2.4}Acceso al exterior desde nodos}{56}{subsection.6.2.4}%
+\contentsline {chapter}{\numberline {7}InteraccciÃ³n}{57}{chapter.7}%
+\contentsline {section}{\numberline {7.1}Configuraciones de administrador}{58}{section.7.1}%
+\contentsline {subsubsection}{\numberline {7.1.0.1}Crear proyecto}{58}{subsubsection.7.1.0.1}%
+\contentsline {subsubsection}{\numberline {7.1.0.2}Crear usuario}{60}{subsubsection.7.1.0.2}%
+\contentsline {subsubsection}{\numberline {7.1.0.3}Crear flavor}{61}{subsubsection.7.1.0.3}%
+\contentsline {subsubsection}{\numberline {7.1.0.4}Crear provider network}{63}{subsubsection.7.1.0.4}%
+\contentsline {section}{\numberline {7.2}InteracciÃ³n de un usuario}{64}{section.7.2}%
+\contentsline {subsubsection}{\numberline {7.2.0.1}Crear imagen}{64}{subsubsection.7.2.0.1}%
+\contentsline {subsubsection}{\numberline {7.2.0.2}Crear red}{66}{subsubsection.7.2.0.2}%
+\contentsline {subsubsection}{\numberline {7.2.0.3}Crear router}{68}{subsubsection.7.2.0.3}%
+\contentsline {subsubsection}{\numberline {7.2.0.4}Crear interfaz de router}{69}{subsubsection.7.2.0.4}%
+\contentsline {subsubsection}{\numberline {7.2.0.5}Crear key pair}{69}{subsubsection.7.2.0.5}%
+\contentsline {subsubsection}{\numberline {7.2.0.6}Lanzar una instancia}{69}{subsubsection.7.2.0.6}%
+\contentsline {section}{\numberline {7.3}Acceso a una instancia}{72}{section.7.3}%
+\contentsline {subsection}{\numberline {7.3.1}Por SPICE}{72}{subsection.7.3.1}%
+\contentsline {subsection}{\numberline {7.3.2}Por SSH}{73}{subsection.7.3.2}%
+\contentsline {subsubsection}{\numberline {7.3.2.1}Asociar una Floating IP a la instancia}{73}{subsubsection.7.3.2.1}%
+\contentsline {subsubsection}{\numberline {7.3.2.2}Modificar security group}{74}{subsubsection.7.3.2.2}%
+\contentsline {subsubsection}{\numberline {7.3.2.3}SSH}{75}{subsubsection.7.3.2.3}%
+\contentsline {subsection}{\numberline {7.3.3}Por virsh}{76}{subsection.7.3.3}%
+\contentsline {chapter}{\numberline {8}GestiÃ³n del Datacenter}{77}{chapter.8}%
+\contentsline {section}{\numberline {8.1}RecuperaciÃ³n ante fallas}{77}{section.8.1}%
+\contentsline {subsection}{\numberline {8.1.1}Verificar el estado general de OpenStack}{77}{subsection.8.1.1}%
+\contentsline {subsection}{\numberline {8.1.2}Verificar estado de los componentes de la infraestructura}{78}{subsection.8.1.2}%
+\contentsline {subsection}{\numberline {8.1.3}Solucionar problemas}{78}{subsection.8.1.3}%
+\contentsline {subsection}{\numberline {8.1.4}Problemas con Ceph}{79}{subsection.8.1.4}%
+\contentsline {section}{\numberline {8.2}Agregar y remover nodos}{80}{section.8.2}%
+\contentsline {subsection}{\numberline {8.2.1}Agregar nodo de CÃ³mputo}{80}{subsection.8.2.1}%
+\contentsline {subsection}{\numberline {8.2.2}Eliminar un nodo de cÃ³mputo}{82}{subsection.8.2.2}%
+\contentsline {subsection}{\numberline {8.2.3}Infraestructura}{82}{subsection.8.2.3}%
+\contentsline {subsection}{\numberline {8.2.4}Storage}{82}{subsection.8.2.4}%
+\contentsline {section}{\numberline {8.3}Actualizar versiÃ³n}{82}{section.8.3}%
+\contentsline {chapter}{\numberline {9}AnÃ¡lisis del mÃ³dulo de red}{83}{chapter.9}%
+\contentsline {section}{\numberline {9.1}Escenarios de prueba}{83}{section.9.1}%
+\contentsline {subsection}{\numberline {9.1.1}Escenario 1: trÃ¡fico este-oeste (misma red tenant)}{84}{subsection.9.1.1}%
+\contentsline {subsubsection}{\numberline {9.1.1.1}ComposiciÃ³n del escenario}{84}{subsubsection.9.1.1.1}%
+\contentsline {subsection}{\numberline {9.1.2}Escenario 2: trÃ¡fico este-oeste (distintas redes tenant)}{85}{subsection.9.1.2}%
+\contentsline {subsubsection}{\numberline {9.1.2.1}ComposiciÃ³n del escenario}{85}{subsubsection.9.1.2.1}%
+\contentsline {subsection}{\numberline {9.1.3}Escenario 3: trÃ¡fico norte-sur (acceso hacia el exterior)}{86}{subsection.9.1.3}%
+\contentsline {subsubsection}{\numberline {9.1.3.1}ComposiciÃ³n del escenario}{87}{subsubsection.9.1.3.1}%
+\contentsline {subsection}{\numberline {9.1.4}Escenario 4: trÃ¡fico norte-sur (acceso desde el exterior)}{88}{subsection.9.1.4}%
+\contentsline {subsubsection}{\numberline {9.1.4.1}ComposiciÃ³n del escenario}{88}{subsubsection.9.1.4.1}%
+\contentsline {section}{\numberline {9.2}Linux bridge}{88}{section.9.2}%
+\contentsline {subsection}{\numberline {9.2.1}Escenario 1}{89}{subsection.9.2.1}%
+\contentsline {subsubsection}{\numberline {9.2.1.1}AnÃ¡lisis de componentes}{90}{subsubsection.9.2.1.1}%
+\contentsline {subsubsection}{\numberline {9.2.1.2}AnÃ¡lisis de trÃ¡fico}{93}{subsubsection.9.2.1.2}%
+\contentsline {subparagraph}{Paso 1}{93}{section*.110}%
+\contentsline {subparagraph}{Paso 2}{93}{section*.111}%
+\contentsline {subparagraph}{Paso 3}{97}{section*.116}%
+\contentsline {subparagraph}{Paso 4}{98}{section*.119}%
+\contentsline {subsection}{\numberline {9.2.2}Escenario 2}{99}{subsection.9.2.2}%
+\contentsline {subsubsection}{\numberline {9.2.2.1}AnÃ¡lisis de componentes}{99}{subsubsection.9.2.2.1}%
+\contentsline {subsubsection}{\numberline {9.2.2.2}AnÃ¡lisis de trÃ¡fico}{105}{subsubsection.9.2.2.2}%
+\contentsline {subparagraph}{Paso 1}{105}{section*.121}%
+\contentsline {subparagraph}{Paso 2}{105}{section*.122}%
+\contentsline {subparagraph}{Paso 3}{105}{section*.123}%
+\contentsline {subparagraph}{Paso 4}{106}{section*.125}%
+\contentsline {subparagraph}{Paso 5}{106}{section*.126}%
+\contentsline {subparagraph}{Paso 6}{106}{section*.127}%
+\contentsline {subparagraph}{Paso 7}{106}{section*.129}%
+\contentsline {subsection}{\numberline {9.2.3}Escenario 3}{107}{subsection.9.2.3}%
+\contentsline {subsubsection}{\numberline {9.2.3.1}AnÃ¡lisis de componentes}{108}{subsubsection.9.2.3.1}%
+\contentsline {subsubsection}{\numberline {9.2.3.2}AnÃ¡lisis de trÃ¡fico}{111}{subsubsection.9.2.3.2}%
+\contentsline {subparagraph}{Paso 1}{111}{section*.131}%
+\contentsline {subparagraph}{Paso 2}{111}{section*.132}%
+\contentsline {subparagraph}{Paso 3}{111}{section*.133}%
+\contentsline {subparagraph}{Paso 4}{112}{section*.135}%
+\contentsline {subparagraph}{Paso 5}{112}{section*.136}%
+\contentsline {subparagraph}{Paso 6}{113}{section*.138}%
+\contentsline {subparagraph}{Paso 7}{114}{section*.140}%
+\contentsline {subsection}{\numberline {9.2.4}Escenario 4}{115}{subsection.9.2.4}%
+\contentsline {subsubsection}{\numberline {9.2.4.1}AnÃ¡lisis de componentes}{115}{subsubsection.9.2.4.1}%
+\contentsline {subsubsection}{\numberline {9.2.4.2}AnÃ¡lisis de trÃ¡fico}{117}{subsubsection.9.2.4.2}%
+\contentsline {subparagraph}{Paso 1}{117}{section*.142}%
+\contentsline {subparagraph}{Paso 2}{117}{section*.143}%
+\contentsline {subparagraph}{Paso 3}{117}{section*.144}%
+\contentsline {subparagraph}{Paso 4}{118}{section*.147}%
+\contentsline {subparagraph}{Paso 5}{118}{section*.148}%
+\contentsline {subparagraph}{Paso 6}{119}{section*.150}%
+\contentsline {section}{\numberline {9.3}Open vSwitch}{119}{section.9.3}%
+\contentsline {subsubsection}{\numberline {9.3.0.1}Archivos de configuraciÃ³n}{121}{subsubsection.9.3.0.1}%
+\contentsline {subsection}{\numberline {9.3.1}Escenario 1}{124}{subsection.9.3.1}%
+\contentsline {subsubsection}{\numberline {9.3.1.1}AnÃ¡lisis de componentes}{124}{subsubsection.9.3.1.1}%
+\contentsline {subsubsection}{\numberline {9.3.1.2}AnÃ¡lisis de trÃ¡fico}{130}{subsubsection.9.3.1.2}%
+\contentsline {subparagraph}{Paso 1}{130}{section*.153}%
+\contentsline {subparagraph}{Paso 2}{131}{section*.154}%
+\contentsline {subparagraph}{Paso 3}{138}{section*.159}%
+\contentsline {subparagraph}{Paso 4}{140}{section*.162}%
+\contentsline {subsection}{\numberline {9.3.2}Escenario 2}{141}{subsection.9.3.2}%
+\contentsline {subsubsection}{\numberline {9.3.2.1}AnÃ¡lisis de componentes}{141}{subsubsection.9.3.2.1}%
+\contentsline {subsubsection}{\numberline {9.3.2.2}AnÃ¡lisis de trÃ¡fico}{145}{subsubsection.9.3.2.2}%
+\contentsline {subparagraph}{Paso 1}{146}{section*.164}%
+\contentsline {subparagraph}{Paso 2}{146}{section*.165}%
+\contentsline {subparagraph}{Paso 3}{146}{section*.166}%
+\contentsline {subparagraph}{Paso 4}{146}{section*.168}%
+\contentsline {subparagraph}{Paso 5}{147}{section*.169}%
+\contentsline {subparagraph}{Paso 6}{147}{section*.170}%
+\contentsline {subparagraph}{Paso 7}{147}{section*.172}%
+\contentsline {subsection}{\numberline {9.3.3}Escenario 3}{148}{subsection.9.3.3}%
+\contentsline {subsubsection}{\numberline {9.3.3.1}AnÃ¡lisis de componentes}{148}{subsubsection.9.3.3.1}%
+\contentsline {subsubsection}{\numberline {9.3.3.2}AnÃ¡lisis de trÃ¡fico}{151}{subsubsection.9.3.3.2}%
+\contentsline {subparagraph}{Paso 1}{151}{section*.174}%
+\contentsline {subparagraph}{Paso 2}{151}{section*.175}%
+\contentsline {subparagraph}{Paso 3}{152}{section*.176}%
+\contentsline {subparagraph}{Paso 4}{152}{section*.178}%
+\contentsline {subparagraph}{Paso 5}{152}{section*.179}%
+\contentsline {subparagraph}{Paso 6}{154}{section*.181}%
+\contentsline {subparagraph}{Paso 7}{154}{section*.183}%
+\contentsline {subsection}{\numberline {9.3.4}Escenario 4}{155}{subsection.9.3.4}%
+\contentsline {subsubsection}{\numberline {9.3.4.1}AnÃ¡lisis de componentes}{155}{subsubsection.9.3.4.1}%
+\contentsline {subsubsection}{\numberline {9.3.4.2}AnÃ¡lisis de trÃ¡fico}{156}{subsubsection.9.3.4.2}%
+\contentsline {subparagraph}{Paso 1}{157}{section*.185}%
+\contentsline {subparagraph}{Paso 2}{157}{section*.186}%
+\contentsline {subparagraph}{Paso 3}{157}{section*.187}%
+\contentsline {subparagraph}{Paso 4}{159}{section*.190}%
+\contentsline {subparagraph}{Paso 5}{159}{section*.191}%
+\contentsline {subparagraph}{Paso 6}{159}{section*.193}%
+\contentsline {section}{\numberline {9.4}Comparativa de drivers}{159}{section.9.4}%
+\contentsline {section}{\numberline {9.5}Funcionalidades avanzadas}{159}{section.9.5}%
+\contentsline {subsection}{\numberline {9.5.1}Layer 3 High Availability}{159}{subsection.9.5.1}%
+\contentsline {chapter}{\numberline {10}Trabajo a futuro}{160}{chapter.10}%
+\contentsline {subsubsection}{\numberline {10.0.0.1}Firewall}{160}{subsubsection.10.0.0.1}%
+\contentsline {subsubsection}{\numberline {10.0.0.2}Arquitectura segura}{160}{subsubsection.10.0.0.2}%
+\contentsline {subsubsection}{\numberline {10.0.0.3}Brindar conexiÃ³n directa a Internet}{161}{subsubsection.10.0.0.3}%
+\contentsline {subsubsection}{\numberline {10.0.0.4}GestiÃ³n de Openstack en operaciÃ³n}{161}{subsubsection.10.0.0.4}%
+\contentsline {chapter}{\numberline {11}Conclusiones}{162}{chapter.11}%
+\contentsline {chapter}{Referencias bibliogrÃ¡ficas}{163}{chapter*.194}%
+\contentsline {chapter}{Glosario}{169}{chapter*.194}%
+\contentsline {chapter}{\textbf {ApÃ©ndices}}{170}{section*.195}%
 \ttl@change@i {\@ne }{chapter}{13pt}{}{ ApÃ©ndice\ \thecontentslabel \quad }{}{\titlerule *[1pc]{.}\contentspage }\relax 
 \ttl@change@v {chapter}{}{}{}\relax 
-\contentsline {chapter}{\numberline {1}Datos procesados}{172}{appendix.Alph1}%
-\contentsline {chapter}{\numberline {2}ImÃ¡genes remasterizadas}{173}{appendix.Alph2}%
-\contentsline {chapter}{\numberline {3}Entrevistas desgrabadas}{175}{appendix.Alph3}%
+\contentsline {chapter}{\numberline {1}ImÃ¡genes}{171}{appendix.Alph1}%
 \ttl@change@i {\@ne }{chapter}{0pt}{\vspace *{0.45cm}}{\thecontentslabel \quad }{}{\bfseries \hfill \contentspage }\relax 
 \ttl@change@v {chapter}{}{}{}\relax 
-\contentsline {chapter}{\textbf {Anexos}}{176}{section*.210}%
+\contentsline {chapter}{\textbf {Anexos}}{174}{section*.198}%
 \ttl@change@i {\@ne }{chapter}{13pt}{}{ Anexo\ \thecontentslabel \quad }{}{\titlerule *[1pc]{.}\contentspage }\relax 
 \ttl@change@v {chapter}{}{}{}\relax 
-\contentsline {chapter}{\numberline {1}InstalaciÃ³n versiÃ³n Queens}{177}{appendix.Anexo.1}%
-\contentsline {section}{\numberline {1.1}DiseÃ±o de arquitectura}{177}{section.Anexo.1.1}%
-\contentsline {section}{\numberline {1.2}PreparaciÃ³n de nodos}{178}{section.Anexo.1.2}%
-\contentsline {subsubsection}{\numberline {1.2.0.1}Deploy}{178}{subsubsection.Anexo.1.2.0.1}%
-\contentsline {subsubsection}{\numberline {1.2.0.2}Infra1}{181}{subsubsection.Anexo.1.2.0.2}%
-\contentsline {subsubsection}{\numberline {1.2.0.3}Compute1}{184}{subsubsection.Anexo.1.2.0.3}%
-\contentsline {subsubsection}{\numberline {1.2.0.4}Storage1}{186}{subsubsection.Anexo.1.2.0.4}%
-\contentsline {subsubsection}{\numberline {1.2.0.5}HAproxy1}{187}{subsubsection.Anexo.1.2.0.5}%
-\contentsline {section}{\numberline {1.3}ConfiguraciÃ³n}{188}{section.Anexo.1.3}%
-\contentsline {subsection}{\numberline {1.3.1}ConfiguraciÃ³n claves SSH}{188}{subsection.Anexo.1.3.1}%
-\contentsline {subsection}{\numberline {1.3.2}Archivos de configuraciÃ³n OSA}{189}{subsection.Anexo.1.3.2}%
-\contentsline {subsubsection}{\numberline {1.3.2.1}openstack\_user\_config.yml}{189}{subsubsection.Anexo.1.3.2.1}%
-\contentsline {subsubsection}{\numberline {1.3.2.2}user\_variables.yml}{193}{subsubsection.Anexo.1.3.2.2}%
-\contentsline {subsubsection}{\numberline {1.3.2.3}cinder.yml}{194}{subsubsection.Anexo.1.3.2.3}%
-\contentsline {subsection}{\numberline {1.3.3}GeneraciÃ³n de claves}{194}{subsection.Anexo.1.3.3}%
-\contentsline {subsection}{\numberline {1.3.4}Correcciones}{195}{subsection.Anexo.1.3.4}%
-\contentsline {subsubsection}{\numberline {1.3.4.1}SELinux}{195}{subsubsection.Anexo.1.3.4.1}%
-\contentsline {section}{\numberline {1.4}Inconvenientes}{195}{section.Anexo.1.4}%
-\contentsline {subsection}{\numberline {1.4.1}Bloqueo de paquetes}{195}{subsection.Anexo.1.4.1}%
-\contentsline {subsection}{\numberline {1.4.2}MÃ³dulo de seguridad SELinux}{196}{subsection.Anexo.1.4.2}%
-\contentsline {subsection}{\numberline {1.4.3}Percona-release en playbook setup-infrastructure}{196}{subsection.Anexo.1.4.3}%
-\contentsline {subsection}{\numberline {1.4.4}Subred reservada}{197}{subsection.Anexo.1.4.4}%
-\contentsline {subsection}{\numberline {1.4.5}Versiones de librerÃas y SO}{197}{subsection.Anexo.1.4.5}%
-\contentsline {subsection}{\numberline {1.4.6}Soporte para CentOS}{198}{subsection.Anexo.1.4.6}%
-\contentsline {chapter}{\numberline {2}InstalaciÃ³n versiÃ³n Stein}{199}{appendix.Anexo.2}%
-\contentsline {section}{\numberline {2.1}DiseÃ±o de arquitectura}{199}{section.Anexo.2.1}%
-\contentsline {section}{\numberline {2.2}PreparaciÃ³n de nodos}{201}{section.Anexo.2.2}%
-\contentsline {subsubsection}{\numberline {2.2.0.1}Deploy}{201}{subsubsection.Anexo.2.2.0.1}%
-\contentsline {subsubsection}{\numberline {2.2.0.2}Infra1}{203}{subsubsection.Anexo.2.2.0.2}%
-\contentsline {subsubsection}{\numberline {2.2.0.3}Compute1}{206}{subsubsection.Anexo.2.2.0.3}%
-\contentsline {subsubsection}{\numberline {2.2.0.4}Compute2}{207}{subsubsection.Anexo.2.2.0.4}%
-\contentsline {subsubsection}{\numberline {2.2.0.5}Storage1}{208}{subsubsection.Anexo.2.2.0.5}%
-\contentsline {subsubsection}{\numberline {2.2.0.6}Storage2}{209}{subsubsection.Anexo.2.2.0.6}%
-\contentsline {subsubsection}{\numberline {2.2.0.7}HAproxy1}{209}{subsubsection.Anexo.2.2.0.7}%
-\contentsline {subsubsection}{\numberline {2.2.0.8}Router}{209}{subsubsection.Anexo.2.2.0.8}%
-\contentsline {section}{\numberline {2.3}ConfiguraciÃ³n archivos OSA}{214}{section.Anexo.2.3}%
-\contentsline {subsubsection}{\numberline {2.3.0.1}openstack\_user\_config.yml}{214}{subsubsection.Anexo.2.3.0.1}%
-\contentsline {subsubsection}{\numberline {2.3.0.2}user\_variables.yml}{219}{subsubsection.Anexo.2.3.0.2}%
-\contentsline {subsubsection}{\numberline {2.3.0.3}cinder.yml}{220}{subsubsection.Anexo.2.3.0.3}%
-\contentsline {section}{\numberline {2.4}EjecuciÃ³n de playbooks}{221}{section.Anexo.2.4}%
-\contentsline {section}{\numberline {2.5}Cambios para driver OVS}{221}{section.Anexo.2.5}%
+\contentsline {chapter}{\numberline {1}InstalaciÃ³n versiÃ³n Queens}{175}{appendix.Anexo.1}%
+\contentsline {section}{\numberline {1.1}PreparaciÃ³n de nodos}{175}{section.Anexo.1.1}%
+\contentsline {subsubsection}{\numberline {1.1.0.1}Deploy}{175}{subsubsection.Anexo.1.1.0.1}%
+\contentsline {subsubsection}{\numberline {1.1.0.2}Infra1}{178}{subsubsection.Anexo.1.1.0.2}%
+\contentsline {subsubsection}{\numberline {1.1.0.3}Compute1}{180}{subsubsection.Anexo.1.1.0.3}%
+\contentsline {subsubsection}{\numberline {1.1.0.4}Storage1}{182}{subsubsection.Anexo.1.1.0.4}%
+\contentsline {subsubsection}{\numberline {1.1.0.5}HAproxy1}{183}{subsubsection.Anexo.1.1.0.5}%
+\contentsline {section}{\numberline {1.2}ConfiguraciÃ³n}{184}{section.Anexo.1.2}%
+\contentsline {subsection}{\numberline {1.2.1}ConfiguraciÃ³n claves SSH}{184}{subsection.Anexo.1.2.1}%
+\contentsline {subsection}{\numberline {1.2.2}Archivos de configuraciÃ³n OSA}{185}{subsection.Anexo.1.2.2}%
+\contentsline {subsubsection}{\numberline {1.2.2.1}openstack\_user\_config.yml}{185}{subsubsection.Anexo.1.2.2.1}%
+\contentsline {subsubsection}{\numberline {1.2.2.2}user\_variables.yml}{189}{subsubsection.Anexo.1.2.2.2}%
+\contentsline {subsubsection}{\numberline {1.2.2.3}cinder.yml}{190}{subsubsection.Anexo.1.2.2.3}%
+\contentsline {subsection}{\numberline {1.2.3}GeneraciÃ³n de claves}{191}{subsection.Anexo.1.2.3}%
+\contentsline {subsection}{\numberline {1.2.4}Correcciones}{191}{subsection.Anexo.1.2.4}%
+\contentsline {subsubsection}{\numberline {1.2.4.1}SELinux}{191}{subsubsection.Anexo.1.2.4.1}%
+\contentsline {section}{\numberline {1.3}Inconvenientes}{192}{section.Anexo.1.3}%
+\contentsline {subsection}{\numberline {1.3.1}Bloqueo de paquetes}{192}{subsection.Anexo.1.3.1}%
+\contentsline {subsection}{\numberline {1.3.2}MÃ³dulo de seguridad SELinux}{192}{subsection.Anexo.1.3.2}%
+\contentsline {subsection}{\numberline {1.3.3}Percona-release en playbook setup-infrastructure}{192}{subsection.Anexo.1.3.3}%
+\contentsline {subsection}{\numberline {1.3.4}Subred reservada}{193}{subsection.Anexo.1.3.4}%
+\contentsline {subsection}{\numberline {1.3.5}Versiones de librerÃas y SO}{193}{subsection.Anexo.1.3.5}%
+\contentsline {subsection}{\numberline {1.3.6}Soporte para CentOS}{194}{subsection.Anexo.1.3.6}%
+\contentsline {chapter}{\numberline {2}InstalaciÃ³n versiÃ³n Stein}{195}{appendix.Anexo.2}%
+\contentsline {section}{\numberline {2.1}PreparaciÃ³n de nodos}{195}{section.Anexo.2.1}%
+\contentsline {subsubsection}{\numberline {2.1.0.1}Deploy}{195}{subsubsection.Anexo.2.1.0.1}%
+\contentsline {subsubsection}{\numberline {2.1.0.2}Infra1}{198}{subsubsection.Anexo.2.1.0.2}%
+\contentsline {subsubsection}{\numberline {2.1.0.3}Compute1}{200}{subsubsection.Anexo.2.1.0.3}%
+\contentsline {subsubsection}{\numberline {2.1.0.4}Compute2}{202}{subsubsection.Anexo.2.1.0.4}%
+\contentsline {subsubsection}{\numberline {2.1.0.5}Storage1}{202}{subsubsection.Anexo.2.1.0.5}%
+\contentsline {subsubsection}{\numberline {2.1.0.6}Storage2}{203}{subsubsection.Anexo.2.1.0.6}%
+\contentsline {subsubsection}{\numberline {2.1.0.7}HAproxy1}{203}{subsubsection.Anexo.2.1.0.7}%
+\contentsline {subsubsection}{\numberline {2.1.0.8}Router}{204}{subsubsection.Anexo.2.1.0.8}%
+\contentsline {section}{\numberline {2.2}ConfiguraciÃ³n archivos OSA}{208}{section.Anexo.2.2}%
+\contentsline {subsubsection}{\numberline {2.2.0.1}openstack\_user\_config.yml}{208}{subsubsection.Anexo.2.2.0.1}%
+\contentsline {subsubsection}{\numberline {2.2.0.2}user\_variables.yml}{213}{subsubsection.Anexo.2.2.0.2}%
+\contentsline {subsubsection}{\numberline {2.2.0.3}cinder.yml}{215}{subsubsection.Anexo.2.2.0.3}%
+\contentsline {section}{\numberline {2.3}EjecuciÃ³n de playbooks}{215}{section.Anexo.2.3}%
+\contentsline {section}{\numberline {2.4}Cambios para driver OVS}{216}{section.Anexo.2.4}%
+\contentsline {chapter}{\numberline {3}VirtualizaciÃ³n con KVM}{219}{appendix.Anexo.3}%
+\contentsline {section}{\numberline {3.1}UtilizaciÃ³n virt-manager}{219}{section.Anexo.3.1}%
+\contentsline {subsection}{\numberline {3.1.1}ConexiÃ³n remota}{219}{subsection.Anexo.3.1.1}%
+\contentsline {subsection}{\numberline {3.1.2}CreaciÃ³n de una red}{220}{subsection.Anexo.3.1.2}%
+\contentsline {subsection}{\numberline {3.1.3}Crear nodo}{222}{subsection.Anexo.3.1.3}%
 \contentsfinish 
diff --git a/docs/udelartex/tesis.xwm b/docs/udelartex/tesis.xwm
index 18f6a4699b5355f92368099ab60a2c6fcef658c4..18f4bd9c0934073af8ae4392871dd254662ba4ff 100644
--- a/docs/udelartex/tesis.xwm
+++ b/docs/udelartex/tesis.xwm
@@ -1,2 +1,2 @@
 \relax 
-\xwmnewlabel{xwmlastpage}{{2.5}{223}{Cambios para driver OVS\relax }{lstnumber.-277.4}{}}
+\xwmnewlabel{xwmlastpage}{{3.1.3}{225}{Crear nodo\relax }{Item.265}{}}