Este es el comando guestfs-internals que se puede ejecutar en el proveedor de alojamiento gratuito de OnWorks utilizando una de nuestras múltiples estaciones de trabajo en línea gratuitas, como Ubuntu Online, Fedora Online, emulador en línea de Windows o emulador en línea de MAC OS.
PROGRAMA:
NOMBRE
guestfs-internals - arquitectura e interior de libguestfs
DESCRIPCIÓN
Esta página de manual es para piratas informáticos que desean comprender cómo funciona libguestfs internamente.
Esta es solo una descripción de cómo funciona libguestfs ahora, y puede cambiar en cualquier momento en
el futuro.
ARQUITECTURA
Internamente, libguestfs se implementa ejecutando un dispositivo (un tipo especial de pequeño
máquina virtual) usando qemu(1). Qemu se ejecuta como un proceso secundario del programa principal.
┌───────────────────┐
│ programa principal │
│ │
│ │ proceso hijo / dispositivo
│ │ ┌──────────────────────────┐
│ │ │ qemú │
├──────────────────┤ RPC │ ┌─────────────────┐ │
│ libguestfs ◀ ╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍ ▶ guestfsd │ │
│ │ │ ├─────────────────┤ │
└───────────────────┘ │ │ kernel de Linux │ │
│ └────────┬────────┘ │
└───────────────│──────────┘
│
│ virtio-scsi
┌──────┴──────┐
│ Dispositivo o │
│ imagen de disco │
└─────────────┘
La biblioteca, vinculada al programa principal, crea el proceso hijo y, por lo tanto, el dispositivo.
en la función "guestfs_launch".
Dentro del dispositivo hay un kernel de Linux y una pila completa de herramientas de espacio de usuario (como
LVM y programas ext2) y un pequeño demonio de control llamado "guestfsd". La biblioteca
habla con "guestfsd" mediante llamadas a procedimiento remoto (RPC). Hay una mayoría de uno a uno
correspondencia entre las llamadas a la API de libguestfs y las llamadas RPC al demonio. Por ultimo el disco
Las imágenes se adjuntan al proceso qemu que traduce el acceso al dispositivo por el
kernel de Linux del dispositivo en accesos a la imagen.
Un malentendido común es que el dispositivo "es" la máquina virtual. Aunque el
La imagen de disco a la que está conectado también puede ser utilizada por alguna máquina virtual, libguestfs
no sabe ni le importa esto. (Pero le importará si tanto el proceso qemu de libguestfs como
su máquina virtual está intentando actualizar la imagen del disco al mismo tiempo, ya que estos
generalmente resulta en una corrupción masiva del disco).
STATE MÁQUINA
libguestfs usa una máquina de estado para modelar el proceso hijo:
|
guestfs_create / guestfs_create_flags
|
|
____V_____
/ \
| CONFIGURAR |
\ __________ /
^ ^ \
| \ \ guestfs_lanzamiento
| _ \ __ V______
| /\
| | LANZAMIENTO |
| \ ___________ /
| /
| guestfs_lanzamiento
| /
__ | ____ V
/ \
| LISTO |
\ ________ /
Las transiciones normales son (1) CONFIG (cuando se crea el identificador, pero no hay un niño
proceso), (2) INICIO (cuando el proceso hijo se está iniciando), (3) LISTO, es decir,
dispositivo está activo, las acciones se pueden emitir y llevar a cabo por el proceso hijo.
El invitado puede ser asesinado por "guestfs_kill_subprocess", o puede morir asincrónicamente en cualquier
tiempo (por ejemplo, debido a algún error interno), y eso hace que el estado vuelva a
CONFIG.
Los comandos de configuración para qemu, como "guestfs_set_path", solo se pueden emitir en el
Estado CONFIG.
La API ofrece una llamada que va desde CONFIG hasta LAUNCHING y READY.
"guestfs_launch" se bloquea hasta que el proceso hijo está LISTO para aceptar comandos (o hasta que algunos
falla o tiempo de espera). "guestfs_launch" mueve internamente el estado de CONFIG a LAUNCHING
mientras está funcionando.
Las acciones de la API como "guestfs_mount" solo se pueden ejecutar cuando están en el estado READY. Estas API
Bloque de llamadas a la espera de que se ejecute el comando. No hay ningún bloqueo
versiones, y no hay forma de emitir más de un comando por identificador al mismo tiempo.
Finalmente, el proceso hijo envía mensajes asincrónicos al programa principal, como
mensajes de registro del kernel. Puede registrar una devolución de llamada para recibir estos mensajes.
INTERNOS
APARATO BARCO NUESTRO PROCESO
Este proceso ha evolucionado y sigue evolucionando. La descripción aquí corresponde solo
a la versión actual de libguestfs y se proporciona solo con fines informativos.
Para seguir las etapas involucradas a continuación, habilite la depuración de libguestfs (establezca el
variable de entorno "LIBGUESTFS_DEBUG = 1").
Crea el dispositivo
"supermin --build" se invoca para crear el kernel, un pequeño initrd y el dispositivo.
El dispositivo está almacenado en caché /var/tmp/.guestfs- (o en otro directorio si
Se establecen "LIBGUESTFS_CACHEDIR" o "TMPDIR").
Para obtener una descripción completa de cómo se crea y almacena en caché el dispositivo, lea el
supermín(1) página de manual.
Inicie qemu y arranque el kernel
qemu se invoca para arrancar el kernel.
Ejecute el initrd
"supermin --build" construye un pequeño initrd. El initrd no es el dispositivo. los
El propósito del initrd es cargar suficientes módulos del kernel para que el dispositivo
se puede montar y poner en marcha.
El initrd es un archivo cpio llamado /var/tmp/.guestfs- /appliance.d/initrd.
Cuando se haya iniciado initrd, verá mensajes que muestran que los módulos del kernel están
siendo cargado, similar a esto:
supermin: arrancando ext2 mini initrd
supermin: montaje / sys
supermin: interno insmod libcrc32c.ko
supermin: interno insmod crc32c-intel.ko
Busque y monte el dispositivo del dispositivo
El dispositivo es un archivo disperso que contiene un sistema de archivos ext2 que contiene un familiar
(aunque de tamaño reducido) Sistema operativo Linux. Normalmente se llamaría
/var/tmp/.guestfs- /appliance.d/root.
Los discos regulares que inspecciona libguestfs son los primeros dispositivos expuestos por qemu
(por ejemplo, como / dev / vda).
El último disco agregado a qemu es el dispositivo en sí (p. Ej. / dev / vdb si solo hubiera
un disco normal).
Por lo tanto, el trabajo final del initrd es ubicar el disco del dispositivo, montarlo y cambiar
root en el dispositivo y ejecutar /en eso del aparato.
Si esto funciona correctamente, verá mensajes como:
supermin: elegido / sys / block / vdb / dev como dispositivo raíz
supermin: creando / dev / root como bloque especial 252: 16
supermin: montaje de nueva raíz en / Root
supermin: chroot
Iniciando / init script ...
Tenga en cuenta que "Iniciando / script de inicio ..." indica que el script de inicio del dispositivo está
ahora corriendo.
Inicializar el dispositivo
El propio dispositivo ahora se inicializa. Esto implica iniciar ciertos procesos.
como "udev", posiblemente imprimiendo información de depuración y finalmente ejecutando el demonio
("guestfsd").
El demonio
Finalmente, el demonio ("guestfsd") se ejecuta dentro del dispositivo. Si se ejecuta, debería ver:
demonio detallado habilitado
El demonio espera ver un puerto virtio-serial nombrado expuesto por qemu y conectado en
el otro extremo a la biblioteca.
El demonio se conecta a este puerto (y por lo tanto a la biblioteca) y envía un mensaje de cuatro bytes
mensaje "GUESTFS_LAUNCH_FLAG", que inicia el protocolo de comunicación (ver más abajo).
COMUNICACIÓN PROTOCOLO
No confíe en usar este protocolo directamente. Esta sección documenta cómo se
funciona, pero puede cambiar en cualquier momento.
El protocolo utilizado para hablar entre la biblioteca y el demonio que se ejecuta dentro de qemu
La máquina virtual es un mecanismo RPC simple construido sobre XDR (RFC 1014, RFC 1832, RFC
4506).
El formato detallado de las estructuras está en src / guestfs_protocol.x (nota: este archivo es
generada automáticamente).
Hay dos casos generales, funciones ordinarias que no tienen "FileIn" y "FileOut"
parámetros, que se manejan con mensajes de solicitud / respuesta muy simples. Entonces hay
funciones que tienen cualquier parámetro "FileIn" o "FileOut", que utilizan la misma solicitud y
mensajes de respuesta, pero también pueden ir seguidos de archivos enviados con una codificación fragmentada.
ORDINARIO Las funciones (Yo no tengo FILEIN / FILEOUT PARÁMETROS)
Para funciones ordinarias, el mensaje de solicitud es:
longitud total (encabezado + argumentos,
pero sin incluir la longitud de la palabra en sí)
struct guestfs_message_header (codificado como XDR)
struct guestfs_ _args (codificado como XDR)
El campo de longitud total permite al demonio asignar un búfer de tamaño fijo en el que
sorbe el resto del mensaje. Como resultado, la longitud total se limita a
Bytes "GUESTFS_MESSAGE_MAX" (actualmente 4 MB), que significa el tamaño efectivo de cualquier solicitud
está limitado a algún lugar por debajo de este tamaño.
Tenga en cuenta también que muchas funciones no aceptan ningún argumento, en cuyo caso el
"guestfs_foo_args " se omite por completo.
El encabezado contiene el número de procedimiento ("guestfs_proc") que es como lo sabe el receptor
qué tipo de estructura de argumentos esperar, o ninguno en absoluto.
Para las funciones que toman argumentos opcionales, los argumentos opcionales se codifican en el
"guestfs_foo_args " estructura de la misma manera que los argumentos ordinarios. Una máscara de bits en el
El encabezado indica qué argumentos opcionales son significativos. La máscara de bits también se comprueba para
ver si contiene un conjunto de bits que el demonio no conoce (por ejemplo, si es más opcional
se agregaron argumentos en una versión posterior de la biblioteca), y esto hace que la llamada sea
rechazado.
El mensaje de respuesta para funciones ordinarias es:
longitud total (encabezado + ret,
pero sin incluir la longitud de la palabra en sí)
struct guestfs_message_header (codificado como XDR)
struct guestfs_ _ret (codificado como XDR)
Como arriba de "guestfs_foo_ret " La estructura puede omitirse por completo para funciones que
no devuelve valores de retorno formales.
Como se indicó anteriormente, la longitud total de la respuesta se limita a "GUESTFS_MESSAGE_MAX".
En el caso de un error, se establece una bandera en el encabezado y el mensaje de respuesta es ligeramente
cambiado:
longitud total (encabezado + error,
pero sin incluir la longitud de la palabra en sí)
struct guestfs_message_header (codificado como XDR)
struct guestfs_message_error (codificado como XDR)
La estructura "guestfs_message_error" contiene el mensaje de error como una cadena.
Las funciones QUE TENER PRESENTAR EN PARÁMETROS
Un parámetro "FileIn" indica que transferimos un archivo dentro el invitado. La solicitud normal
se envía el mensaje (ver arriba). Sin embargo, a esto le sigue una secuencia de fragmentos de archivo.
longitud total (encabezado + argumentos,
pero sin incluir la longitud de la palabra en sí,
y sin incluir los trozos)
struct guestfs_message_header (codificado como XDR)
struct guestfs_ _args (codificado como XDR)
secuencia de fragmentos para FileIn param # 0
secuencia de fragmentos para FileIn param # 1, etc.
La "secuencia de fragmentos" es:
longitud del fragmento (sin incluir la longitud de la palabra en sí)
struct guestfs_chunk (codificado como XDR)
longitud del trozo
struct guestfs_chunk (codificado como XDR)
...
longitud del trozo
struct guestfs_chunk (con data.data_len == 0)
El fragmento final tiene el campo "data_len" establecido en cero. Además, se coloca una bandera en el
fragmento final para indicar una finalización satisfactoria o una cancelación anticipada.
En el momento de escribir este artículo, no hay funciones que tengan más de un parámetro FileIn.
Sin embargo, esto es (teóricamente) compatible, enviando la secuencia de fragmentos para cada
Parámetro FileIn uno tras otro (de izquierda a derecha).
Tanto la biblioteca (remitente) y el demonio (receptor) puede cancelar la transferencia. La biblioteca
hace esto enviando un fragmento con una bandera especial establecida para indicar la cancelación. Cuando el
daemon ve esto, cancela todo el RPC, no no envía cualquier respuesta y vuelve a
leyendo la siguiente solicitud.
El demonio también puede cancelarse. Lo hace escribiendo una palabra especial "GUESTFS_CANCEL_FLAG"
al enchufe. La biblioteca escucha esto durante la transferencia y, si lo recibe,
cancelará la transferencia (envía un fragmento de cancelación). La palabra especial se elige para que
incluso si la cancelación ocurre justo al final de la transferencia (después de que la biblioteca
terminado de escribir y ha comenzado a escuchar la respuesta), la bandera de cancelación "espuria"
no debe confundirse con el mensaje de respuesta.
Este protocolo permite la transferencia de archivos de tamaño arbitrario (sin límite de 32 bits), y también
archivos cuyo tamaño no se conoce de antemano (por ejemplo, de tuberías o enchufes). Sin embargo, el
los fragmentos son bastante pequeños ("GUESTFS_MAX_CHUNK_SIZE"), por lo que ni la biblioteca ni la
El demonio necesita guardar mucho en la memoria.
Las funciones QUE TENER SALIDA DE ARCHIVO PARÁMETROS
El protocolo para los parámetros de FileOut es exactamente el mismo que para los parámetros de FileIn, pero con
los roles de demonio y biblioteca se invierten.
longitud total (encabezado + ret,
pero sin incluir la longitud de la palabra en sí,
y sin incluir los trozos)
struct guestfs_message_header (codificado como XDR)
struct guestfs_ _ret (codificado como XDR)
secuencia de fragmentos para FileOut param # 0
secuencia de fragmentos para FileOut param # 1, etc.
INICIAL MENSAJE
Cuando el demonio se inicia, envía una palabra inicial ("GUESTFS_LAUNCH_FLAG") que indica
que el invitado y el demonio están vivos. Esto es lo que espera "guestfs_launch".
PROGRESO NOTIFICACIÓN MENSAJES
El demonio puede enviar mensajes de notificación de progreso en cualquier momento. Estos se distinguen
por la palabra de longitud normal reemplazada por "GUESTFS_PROGRESS_FLAG", seguida de una palabra fija
mensaje de progreso de tamaño.
La biblioteca los convierte en devoluciones de llamada de progreso (consulte "GUESTFS_EVENT_PROGRESS") si hay
una devolución de llamada registrada, o los descarta si no.
El demonio autolimita la frecuencia de los mensajes de progreso que envía (consulte
"daemon / proto.c: notificar_progreso"). No todas las llamadas generan mensajes de progreso.
FIJO APARATO
Cuando se ejecutan libguestfs (o herramientas libguestfs), buscan una ruta en busca de una
aparato. La ruta está integrada en libguestfs, o se puede establecer usando "LIBGUESTFS_PATH"
Variable ambiental.
Normalmente, un dispositivo supermin se encuentra en esta ruta (consulte "APARATO SUPERMIN" en
supermín(1)). libguestfs reconstruye esto en un dispositivo completo ejecutando "supermin
--construir".
Sin embargo, también se puede utilizar un "aparato fijo" más simple. libguestfs detecta esto mirando
para un directorio en la ruta que contiene todos los archivos siguientes:
· núcleo
· initrd
· raíz
· LÉAME.arreglado (tenga en cuenta que debe estar presente también)
Si se encuentra el dispositivo fijo, libguestfs omite supermin por completo y simplemente ejecuta el
máquina virtual (usando qemu o el backend actual, ver "BACKEND") con el kernel, initrd
y el disco raíz del dispositivo fijo.
Por lo tanto, el dispositivo fijo se puede utilizar cuando una plataforma o una distribución de Linux no
apoyo supermin. Construye el dispositivo fijo en una plataforma que admite supermin
usando libguestfs-hacer-dispositivo-reparado(1), cópielo y utilícelo para ejecutar libguestfs.
Utilice guestfs-internals en línea utilizando los servicios de onworks.net
