Arquitecturas de Sistemas Operativos 1

1
Arquitecturas de
Sistemas Operativos
Diseño de Sistemas Operativos
(cc) José Antonio Gómez
Curso 2013-14
Objetivo
• Conocer las estructuras/arquitectura de SOS
actuales desde el punto de vista de la
adaptabilidad funcional de los mismos a nuevos
servicios y hardware.
Índice
• Arquitectura monolítica:
–
–
–
–
configuración del kernel
configuración en el arranque
configuración en tiempo de ejecución
módulos de carga
• Máquinas virtuales:
– Soporte del kernel a la virtualización: namespaces,
cgroups, containers.
– Soporte a máquinas virtuales: Xen, KVM.
Introducción
• Necesitamos estructuras (arquitecturas) que
permitan dar soporte a nuevos tipos de
aplicaciones y a nuevos dispositivos –
sistemas extensibles/adaptables.
• Necesitamos construir sistemas seguros,
correctos, y robustos.
• La arquitectura puede determinar
propiedades no funcionales, por ejemplo,
QoS.
Diseño de Sistemas Operativos - Tema 1
4
Arquitecturas en uso
• En la actualidad, las estructuras más
usadas:
– Monolítica – Linux, ...
– Microkernel – MacOS, Windows, QNX, ...
– Máquinas virtuales – Xen, VMWare, …
– SO de internet – PalmOS(WebOS)
Diseño de Sistemas Operativos - Tema 1
5
Arquitectura Monolítica
• Características:
– Toda la funcionalidad en modo kernel.
– Ventaja: eficiencia
– Problema: no confinamiento de errores en modo
kernel
– Adaptabilidad:
• De forma estática:
– Configuración y arranque del kernel
– Modificar o añadir código
• De forma dinámica:
– “On-the-fly”
– LKM (Linux Kernel Modules)
Diseño de Sistemas Operativos - Tema 1
6
Arq. Monolítica: configuración
• Razones para configurar un kernel:
– Añadir nuevo hardware
– Optimizar según entorno: servidor, desktop, ..,
SMP, …
– Añadir nueva funcionalidad o un manejador no
oficial.
– Fijar errores de la versión actual.
• Lista opciones de configuración:
– [Kroadh-Hartman2006]
– make [config|menuconfig|xconfig|gconfig]
Diseño de Sistemas Operativos - Tema 1
7
Arq. Monolitica: arranque
• Podemos pasar parámetro al kernel en el
arranque, a través de GRUB o LILO.
• Por ejemplo:
– nousb
– elevator=[cfq|deadline|noop]
• Todas las opciones en:
– Doc/Documentation/kernel-parameters.txt
– Libro [Kroadh-Hartman2006]
Diseño de Sistemas Operativos - Tema 1
8
Compilación del kernel (2.6)
• Configurado el kernel, debemos compilarlo:
– Situados en /usr/src/linux, ejecutamos:
% make
– Optimizaciones:
• Compilar una porción del kernel:
% make [M=]drivers/usb/serial
• Realizar una compilación cruzada:
% make ARCH=arm CROSS_COMPILER=/usr/local/bin/...
• Acelerar la compilación con ccache (http://ccache.samba.org/) o
distcc (http://code.google.com/p/distcc/):
% make CC=”ccache distcc”
• Compilación mutihebra:
% make -jn
(donde n = 2 * número_de_procesadores).
Diseño de Sistemas Operativos - Tema 1
9
Instalación del kernel (2.6)
• Instalamos los módulos:
% make modules_install
• Instalamos la imagen del kernel:
% make install
– verifica la correcta construcción del kernel
– Instala el kernel en /boot
– Se genera cualquier imagen ramdisk inicial (se debe generar un disco ram
después de hacer make modules_install:
# mkinitramfs -o /boot/initrd.img-2.6.20.1 /lib/modules/2.6.20.1
– Se notificar al programa cargador de la existencia de una nueva imagen y se actualiza.
• Algunas distribuciones automatizan los pasos de la compilación:
– installkernel
(paquete mkinitrd).
– make-kpkg en Ubuntu.
Diseño de Sistemas Operativos - Tema 1
10
Parcheado del kernel
• Permite modificar funcionalidad, corregir
errores o actualizar el kernel.
• Un parche es un archivo que contiene los
elementos a cambiar respecto de un archivo
original existente en la distribución.
• El proceso de pasar un parche se puede
automatizar con la herramienta ketchup.
• Lo generamos con diff:
– diff -Naur dir_archivo_original
archivo_nuevo > parche.patch
Diseño de Sistemas Operativos - Tema 1
11
Parchear: pasos
1. Bajar los fuentes del kernel, el parche en /usr/src, y descomprimir.
2. Parchear el kernel:
bzcat ../patch-2.4.21-ac1.bz2 | patch -p1
3. Copiar el .config anterior al directorio actual.
4. Verificar opciones nuevas y hacer consistente con las actuales:
make oldconfig
5. Configurar o modificar más opciones si lo deseamos:
make menuconfig
6. Compilar como lo hacemos habitualmente.
9. Instalar como lo hacemos habitualmente.
Diseño de Sistemas Operativos - Tema 1
12
Modificar el kernel
• La complejidad medida como LOC es exponencial.
Ngc891, “Evolution of the Linux kernel source code tarball size”, en línea (6/3/2012)
en http://ngc891.blogdns.net/?p=92
Diseño de Sistemas Operativos - Tema 1
13
Modificar/añadir código
La
complejidad
de modificar /
añadir código
es muy
elevada
debido a las
dependencias
entre
componentes
http://www.makelinux.net/kernel_map o http://lxr.linux.no
Diseño de Sistemas Operativos - Tema 1
14
Modificaciones “on-the-fly”
• El seudo-sistema de archivos /proc nos permite
configurar al vuelo ciertos parámetros del sistema.
% echo “mihost” >/proc/sys/kernel/hostname
• Podemos hacer los cambios permanentes con
sysctl:
% sysctl –w kernel.hostname=mihost
• Ajuste de servicios a través de órdenes
(start/stop/restart/reload/status):
% /etc/init.d/xinetd reload
Diseño de Sistemas Operativos - Tema 1
15
Linux Kernel Modules
• Un LKM es un objeto ELF (Executable and
Linkable Format) que resuelve sus símbolos
cuando se carga en el kernel.
• Aligera el núcleo vs. Sobrecarga
• No es un proceso.
• Puede estar en un de los siguientes estados:
MODULE_STATE_COMING, MODULE_STATE_LIVE, y
MODULE_STATE_GOING.
• Órdenes relacionadas: insmod, rmmod,
modprobe y lsmod.
Diseño de Sistemas Operativos - Tema 1
16
LKM
Kernel “limpio”
Figura extraída de [CorbetRubiniKroah-Hartmanen05]
Diseño de Sistemas Operativos - Tema 1
17
Estructura de un LKM (2.6)
#include <linux/module.h>
#include <linux/init.h>
Includes
MODULE_LICENSE(“GPL”)
MODULE_AUTHOR(“Autor del módulo”)
MODULE_DESCRIPTION(“Descripción del módulo)
Macros del módulo
static int __init funcion_entrada(void)
{
....
return 0;
}
Constructor del módulo
static void __exit funcion_salida (void)
{
return;
}
module_init (funcion_entrada);
module_exit(funcion_salida);
Destructor del módulo
Macros de entrada/salida
Diseño de Sistemas Operativos - Tema 1
18
Construcción de un módulo
• En 2.6, la construcción es más simple
gracias al sistema de construcción kbuild.
• Lo primero que tenemos que decidir en
donde “vivirá” el módulo:
– Junto con las fuentes del kernel: ya sea como
parche o mezclando el código con el árbol
oficial.
– Fuera del árbol de fuentes.
Diseño de Sistemas Operativos - Tema 1
19
Construcción: árbol de fuentes
• Si el módulo es parte una parte oficia del
kernel “vive” en el árbol de fuentes.
• Por ejemplo, un manejador de un
dispositivo de caracteres estará en
drivers/char.
• Las reglas para ubicarlo no son muy
estrictas, por lo que podemos crear
nuestro propio directorio si es necesario.
Diseño de Sistemas Operativos - Tema 1
20
Construcción: externo
• Crear un Makefile en el directorio que
contiene el archivo fuente y añadir la línea:
obj-m := mi_modulo.o
• La diferencia esta en la construcción.
Debemos indicar donde estan los fuentes:
make -C
/kernel/source/location
SUBDIRS=$PWD modules
Diseño de Sistemas Operativos - Tema 1
21
Instalación y dependencias
• Los módulos instalados se sitúan en
/lib/modules/version/kernel/
• Esto es lo que hace make modules_install
• Podemos construir la información de dependencias entre
módulos con depmod.
• Las dependencias se almacenan en
/lib/modules/version/modules.dep que es usado por depmod.
• Por ejemplo:
% cat modules.dep | grep vfat
kernel/fs/fat/vfat.ko: kernel/fs/fat/fat.ko
Diseño de Sistemas Operativos - Tema 1
22
Carga de módulos
• Cargamos un módulo con:
– insmod : no controla dependencias, ni errores.
– modprobe: suministra resolución de
dependencias, control errores e informes.
• Descarga de módulos:
– rmmod
– modprobe -r
• Las llamadas al sistema usadas son:
init_module() y delete_module().
Diseño de Sistemas Operativos - Tema 1
23
Información
• Podemos obtener información de un modulo con /sbin/modinfo.
% /sbin/modinfo vfat
filename:
/lib/modules/2.6.34.7-0.7desktop/kernel/fs/fat/vfat.ko
author:
Gordon Chaffee
description:
VFAT filesystem support
license:
GPL
srcversion:
70D5128491544D7A33E0C3A
depends:
fat
vermagic:
2.6.34.7-0.7-desktop SMP preempt
mod_unload modversions 686
• La información se almacena en la sección .modinfo del ELF.
Diseño de Sistemas Operativos - Tema 1
24
¿Qué es un módulo?
• Un módulo es un archivo objeto reubicable:
% file vfat.ko
vfat.ko: ELF 32-bit LSB relocatable, …, not
stripped
• Funciones externas del módulo:
% nm vfat.ko
00000000 T init_module
00000000 t init_vfat_fs
U iput
U jiffies
U kfree
Diseño de Sistemas Operativos - Tema 1
25
¿qué es .. (ii)?
• Los símbolos marcados indefinidos (U) son
símbolos del kernel o de otros módulos.
% cat /proc/kallsyms|grep jiffies
c0946a40 D jiffies
• La D indica que es símbolo definido en el
segmento de datos. Una T, indicaría en el de
texto, … ver espeficación de ELF.
• Esta información es la que usa depmod.
• Todos los símbolos que exporta el kernel están
en System.map o en /proc/kallsyms.
Diseño de Sistemas Operativos - Tema 1
26
Kernels contaminados
• El kernel mantiene un estado de contaminación (taint state) que es un indicador de que
ha ocurrido algo que puede producir un error o cuelgue del kernel.
• Este estado solo se abandona reiniciando el kernel.
• La bandera de contaminación también indica las razones de contaminación:
– P: A module with a Proprietary license has been loaded, i.e. a module that is not licensed under the
GNU General Public License (GPL) or a compatible license. This may indicate that source code for
this module is not available to the Linux kernel developers or to Novell's developers.
– G: The opposite of 'P': the kernel has been tainted (for a reason indicated by a different flag), but all
modules loaded into it were licensed under the GPL or a license compatible with the GPL.
– F: A module was loaded using the Force option "-f" of insmod or modprobe, which caused a sanity
check of the versioning information from the module (if present) to be skipped.
– R: A module which was in use or was not designed to be removed has been forcefully Removed from
the running kernelusing the force option "-f" of rmmod.
– S: The Linux kernel is running with Symmetric MultiProcessor support (SMP), but the CPUs in the
system are not designed or certified for SMP use.
– M: A Machine Check Exception (MCE) has been raised while the kernel was running. MCEs are
triggered by the hardware to indicate a hardware related problem, for example the CPU's
temperature exceeding a treshold or a memory bank signaling an uncorrectable error.
– B: A process has been found in a Bad page state, indicating a corruption of the virtual memory
subsystem, possibly caused by malfunctioning RAM or cache memory.
Diseño de Sistemas Operativos - Tema 1
27
Kernels contaminados (ii)
• Cómo evitar la corrupción según tipo:
– "P", utilizar manejadores/modulos suministrados por el distribuidor.
No siempre es posible ya que algunos componentes hardware solo
son soportados por manejadores propietarios.
– "F" o "R", no utilizar la opción -f al (des)cargar el módulo. Si es
necesario, obtener el módulo para versión específica del kernel.
– "S", no utilizar kernels SMP en sistemas con CPUs que no han sido
certificadas o diseñadas para uso SMP.
– "M" o "B", asegurarse de que el hardware opera dentro de los
parámetros establecidos de suministro de potencia, temperatura,
humedad, y flujo de aire.
– "U" o "N", marcar YES en configuración certificada.
Diseño de Sistemas Operativos - Tema 1
28
Kernel contaminados (y)
• Podemos ver el estado de contaminación de un kernel en /proc/sys/kernel/tainted. Un valor no-cero
indica que el kernel esta contaminado (los valores puede estar OR'ados).
• En /usr/src/linux/Documentation/sysctl/kernel.txt:
1 - A module with a non-GPL license has been loaded, this
includes modules with no license.
Set by modutils >= 2.4.9 and module-init-tools.
2 - A module was force loaded by insmod -f.
Set by modutils >= 2.4.9 and module-init-tools.
4 - Unsafe SMP processors: SMP with CPUs not designed for SMP.
8 - A module was forcibly unloaded from the system by rmmod -f.
16 - A hardware machine check error occurred on the system.
32 - A bad page was discovered on the system.
64 - The user has asked that the system be marked "tainted". This
could be because they are running software that directly modifies
the hardware, or for other reasons.
128 - The system has died.
256 - The ACPI DSDT has been overridden with one supplied by the user
instead of using the one provided by the hardware.
512 - A kernel warning has occurred.
1024 - A module from drivers/staging was loaded.
Diseño de Sistemas Operativos - Tema 1
29
Limitaciones LKM
• No podemos modificar funcionalidad
compilada estáticamente.
• Podemos preparar “ganchos”
• Dificultad de confinar un error dentro del
módulo. Intentos de solventarlo:
– Módulos binarios – no puede acceder a funciones
explícitamente disponibles sobre licencia GPL. Su
carga produce un kernel “contaminado” (tainted).
– Modularización del código fuente.
Diseño de Sistemas Operativos - Tema 1
30
Más detalles ..
• W. Mauerer, Professional Linux Kernel
Architecture, Wiley Publishing, 2008.
Capitulo 7.
• D. Bovet y M. Cesati, Understanding the
Linux kernel (3/e), O'Reilly, 2006,
Apéndice B.
Diseño de Sistemas Operativos - Tema 1
31
Virtualización
• “Virtualización es una tecnología que
combina o divide recursos de computación
para presentar uno o varios entornos de
operación utilizando metodologías como
particionamiento o agregación ya sea
hardware o software, simulación de
máquinas completa o parcial, emulación,
tiempo compartido, y otras” [Susanta Nanda y Tzi-cker
Chiueh, “A Survey on Virtualization Technologies”, RPE Report, SUNY at
Stony Brook, New York. Feb. 2005.]
Diseño de Sistemas Operativos - Tema 1
32
Virtualización
• Razones para virtualizar:
– Aislamiento de recursos
– Compartir recursos hardware o consolidar servidores*
– Desarrollo de software o SO para hardware no existente
• Dos enfoques:
– Sistemas virtualizados donde una máquina soporta varios
kernels
– Un único kernel opera sobre una entorno virtual que abstrae
los recursos globales en espacios de nombres aislados*.
Diseño de Sistemas Operativos - Tema 1
33
Virtualización: taxonomía
• VM divididas en:
– Process virtual Machine
– System Virtual Machine:
• Emulación: ISA1 → ISA2
• Virtualización:
– Hipervisor nativo (bare-metal)
o Tipo 1
– Hipervisor con anfitrión o Tipo 2
API
ABI
ISA
Aplicaciones
Bibliotecas
Sistema
Operativo
Hardware
Diseño de Sistemas Operativos - Tema 1
34
Tipos hipervisores
http://blogs.technet.com/b/chenley/archive/2011/02/09/hypervisors.aspx
• Según la implementación podemos separarlos:
– Traducción binaria dinámica del código binario “crítico” del invitado (no de las
aplicaciones).
– Paravirtualización - idem pero del código fuente.
– Virtualización asistida por hardware (Intel VT-x o AMD SVM) – trata de resolver
problemas del hardware relativos a virtualización (trampas).
Diseño de Sistemas Operativos - Tema 1
35
Virtualización total
• La VM simula suficiente hardware para permitir que
un SO invitado sin modificar se ejecute de forma
aislada.
• Por ejemplo, QEMU
• Pros: SO's anfitrión e invitado sin modificar.
• Cons: Peor rendimiento debido a la capa de
emulación.
Diseño de Sistemas Operativos - Tema 1
36
Paravirtualización
• La VM no simula necesariamente el hardware si no
que en su lugar ofrece una API especial para el SO
invitado modificado.
• Por ejemplo, Xen.
• Pros: Buen rendimiento.
• Cons: SOs anfitrión e invitados modificados (en
cada versión del kernel).
Diseño de Sistemas Operativos - Tema 1
37
Xen vs KVM: I/O path
Brendan's blog, “Virtualization Performance: Zones, KVM, Xen” (12/3/2013) disponible
en http://dtrace.org/blogs/brendan/2013/01/11/virtualization-performance-zones-kvm-xen/
Diseño de Sistemas Operativos - Tema 1
38
Xen vs KVM
D. Schirmer, P. Towalski, O.
Kopitetzk, “First experiencewith the
introduction of virtualization
techniques into the delta control
system”, Proceedings of ICALEPCS
2009, Kobe, Japan.
Diseño de Sistemas Operativos - Tema 1
39
KVM, Xen y Linux 3.0+
Chucknology, “KVM is Linux. Xen is Not.”, (2/2/2012) disponible
en http://chucknology.com/2012/02/02/kvm-is-linux-xen-is-not/
Diseño de Sistemas Operativos - Tema 1
40
Xen vs KVM
•
Comparativa en
–
•
http://virtualization.findthebest.com/saved_compare/Xen-vs-KVM-vs-VirtualBox-Comparison-ofOpen-Source-Virtualization-Software
Pros y contras:
–
http://www.cloudcomputingpath.com/kvm-and-xen-virtualization-in-cloud-infrastructure-pros-andcons/?goback=.gmp_2856284.gde_2856284_member_211095996
–
http://www.vps4post.com/thread-221.html
–
http://searchservervirtualization.techtarget.com/feature/Xen-vs-KVM-Linux-virtualizationhypervisors
Diseño de Sistemas Operativos - Tema 1
41
Intel VT-x
Johan De Geleas, “Hardwar virtualizaion: the nuts and Bolts”, AnandTech, 2008, disponible en
http://www.anandtech.com/show/2480/9.
Diseño de Sistemas Operativos - Tema 1
42
Rendimiento
a
[1]
[2]
[1] VMWare, “Ten Reasons Why Oracle Databases Run Best on Vmware”, 12/3/13
en http://blogs.vmware.com/performance/webtech
[2] Microsoft, “Get VIRTUAL Now - Virtualization and 'Green IT'”, 12/3/13
En http://blogs.msdn.com/b/microsoft-green/archive/2008/09/09/get-virtual-now-virtualization-and-green-it.aspx
Diseño de Sistemas Operativos - Tema 1
43
Rendimiento (y ii)
DataBase
Benchmark
CPU intensiva
Web server
benchmark
Memoria
Intensiva
L (Linux) X (Xen) V (VMWare Workstation) U (User Mode Linux)
P. Barham et al., Xen and the Art of Virtualization, Proceedings of the nineteenth ACM symposium on Operating
systems principles (SOSP), Volume 37, Issue 5, pages 164-177, 2003.
Diseño de Sistemas Operativos - Tema 1
44
Ejemplos de MV
•
•
•
•
Nivel ISA: Boch, QEMU, …
Nivel HAL: VMWare, Xen, UML, KVM
Nivel SO: Jail, Containers, …
Nivel de lenguaje de programación: JVM,
Microsoft .NET CLI
• Nivel de biblioteca: Wine, ...
Diseño de Sistemas Operativos - Tema 1
45
Virtualización en Linux
• Soporta a máquinas virtuales:
– Xen
– KVM
– UML, y otros
• Virtualización “ligera”
– Namespaces (espacios de nombres)
– Cgroups (control groups)
– Container (contenedor)
Diseño de Sistemas Operativos - Tema 1
46
Namespaces
• Namespaces es una forma ligera de
virtualización que permite que veamos
propiedades globales de un sistema bajo
diferentes aspectos (un namespace es
esencialmente una “vista” del sistema).
• SOs que soportan este tipo de virtualización:
– Namespaces – Linux
– Zones – Solaris
– Jail – FreeBSD
Diseño de Sistemas Operativos - Tema 1
47
Namespaces: objetivos de
diseño
• Transparencia y compatibilidad – las aplicaciones debe
ejecutarse en namespace como lo hacen en el host.
• Rendimiento – no afecta significativamente.
• Usabilidad y administración – la herramientas
existentes deben seguir funcionando.
• Aceptar de Linux main-stream – desarrollo homogéneo
del kernel (no kernel personalizado).
Diseño de Sistemas Operativos - Tema 1
48
Namespaces: lista
• La lista de namespaces actualmente incluidos:
– UTS (Unix Timesharing System) (lwn) – información del
sistema (nombre, versión, tipo arquitectura, etc.)
– System V IPC (lwn) – mecanismos de comunicación entre
procesos.
– mounts - sistemas de archivos montados: shared subtrees
(lwn) y r/o bind mount (lwn).
– pid (lwn)– espacio de nombres de identificadores de
procesos.
– network (lwn)– conjunto de dispositivos de red.
– userid (lwn)– permite limitar los recursos por usuario.
Diseño de Sistemas Operativos - Tema 1
49
Namespaces: creación
• Podemos establecer un nuevo namespace
con:
– Al crear un proceso con clone y los
indicadores: CLONE_NEWIPC,
CLONE_NEWNET, CLONE_NEWNS,
CLONE_NEWPID, CLONE_NEWUTS
– La llamada al sistema unshare() disocia
parte de los namespaces compartidos con el
padre.
Diseño de Sistemas Operativos - Tema 1
50
Namespaces: implementación
•
Para ahorrar espacio y mejorar la
eficiencia, necesitamos dos
componentes:
– Una estructura namespace por
subsistema que envuelve los
componentes que anteriormente
eran globales en base a un
namespace (struct
uts_namespace, ipc_namespace,
mnt_namespace, pid_namespace,
user_namespace, net_ns.
– Un mecanismo que asocia un
proceso con su namespace (struct
nsproxy).
Conexión entre procesos y namespaces
[Mauerer2008]
Diseño de Sistemas Operativos - Tema 1
51
PID Namespace: relación
• Los namespaces
pueden o no estar
jerárquicamente
relacionados.
• Podemos observar
como un proceso
tiene varios PIDs
dependiendo del
contexto en el que se
observa.
Jerarquía de namespaces [Mauerer2008]
Diseño de Sistemas Operativos - Tema 1
52
Usos de los namespaces
• Posibles usos:
– Servidores Privados Virtuales (VPS) como por
ejemplo Linux Containers (lxc.sourceforge.net)
– Application checkpoint and restart (ACS) – En clusters:
• Sustitución de NFS
• Re-construcción de /proc
Diseño de Sistemas Operativos - Tema 1
53
Pid namespace:requisitos
• Requisitos:
– Los pids en un namespace son
independientes de los pids de otros
namespace.
– El administrador debe visualizar y señalar
todos los procesos.
– Las utilidades existentes debe poder seguir
monitorizando y controlando el sistema
completo: ps, top, kill, etc.
Diseño de Sistemas Operativos - Tema 1
54
pid namespace: ED
• La gestión de identificadores maneja dos estructuras:
– pid – la representación interna del kernel de un PID (ID global).
struct pid {
atomic_t count; /* contador de referencias */
/* lista de tareas que usan este pid */
struct hlist_head tasks[PIDTYPE_MAX];
int level; /*en cuantos namespaces es visible el ID*/
struct upid numbers[1]; /*nº instancias upid por nivel*/
}
– upid – información visible en un namespace específico (ID local).
struct upid {
int nr; /* valor numérico de un ID */
struct pid_namespace ns; /*namespace al que pertenece*/
struct hlist_node pid_chain; /*lista hash desbordamiento*/
}
Donde struct pid_namespace {
….
struct task_struct child_reaper;
/* proceso init local*/
int level;
/* profundidad de la jerarquía namespace */
struct pid_namespace parent;
/* namespace padre */
};
Diseño de Sistemas Operativos - Tema 1
55
PID ns: Estructuras de datos
Diseño de Sistemas Operativos - Tema 1
56
Ejemplo: árbol de procesos con
procesos en 3 pid-namespaces
Diseño de Sistemas Operativos - Tema 1
57
Virtualización: bibliografía
• Susanta Nanda y Tzi-cker Chiueh, “A Survey on Virtualization Technologies”, RPE Report,
SUNY at Stony Brook, New York. Feb. 2005.
• J.E. Smith y R. Nair, Virtual Machines: Versatile Platforms for Systems and Processes, The
Morgan Kaufmann Series in Computer Architecture and Design, San Francisco, USA,
Morgan Kaufmann Inc., 2005.Disponible en
http://www.sciencedirect.com/science/book/9781558609105.
• Wikipedia, “Comparison of platform virtual machines”, consultado el 13/3/2012, disponible
es http://en.wikipedia.org/wiki/Comparison_of_platform_virtual_machines.
Diseño de Sistemas Operativos - Tema 1
58
Cuestiones …...
Diseño de Sistemas Operativos - Tema 1
59