Next: , Previous: , Up: Servicios   [Contents][Index]


11.9.30 Servicios de virtualización

El módulo (gnu services virtualization) proporciona servicios para los daemon libvirt y virtlog, así como otros servicios relacionados con la virtualización.

Daemon de Libvirt

libvirtd is the server side daemon component of the libvirt virtualization management system. This daemon runs on host servers and performs required management tasks for virtualized guests. To connect to the libvirt daemon as an unprivileged user, it must be added to the ‘libvirt’ group, as shown in the example below.

Variable: libvirt-service-type

Este es el tipo para el daemon de libvirt. Su valor debe ser un objeto libvirt-configuration.

(users (cons (user-account
              (name "user")
              (group "users")
              (supplementary-groups '("libvirt"
                                      "audio" "video" "wheel")))
             %base-user-accounts))
(service libvirt-service-type
         (libvirt-configuration
          (tls-port "16555")))

Los campos disponibles de libvirt-configuration son:

parámetro de libvirt-configuration: package libvirt

Paquete libvirt.

parámetro de libvirt-configuration: boolean listen-tls?

Opción para la escucha de conexiones seguras TLS en el puerto TCP/IP público. Debe haberse proporcionado valor a listen para que tenga algún efecto.

Es necesario configurar una autoridad de certificación (CA) y emitir certificados de servidor antes de usar esta característica.

El valor predeterminado es ‘#t

parámetro de libvirt-configuration: boolean listen-tcp?

Escucha de conexiones TCP sin cifrar en el puerto TCP/IP público. Debe haberse proporcionado valor a listen para que tenga algún efecto.

El uso del socket TCP necesita de manera predeterminada identificación SASL. Únicamente se permiten mecanismos SASL que implementen cifrado de datos. Estos son DIGEST_MD5 y GSSAPI (Kerberos5).

El valor predeterminado es ‘#f

parámetro de libvirt-configuration: string tls-port

Puerto en el que se aceptan conexiones seguras. Puede ser un número de puerto o un nombre de servicio.

El valor predeterminado es ‘"16514"’.

parámetro de libvirt-configuration: string tcp-port

Puerto en el que se aceptan conexiones inseguras. Puede ser un número de puerto o un nombre de servicio.

El valor predeterminado es ‘"16509"’.

parámetro de libvirt-configuration: string listen-addr

Dirección IP o nombre de máquina usado para las conexiones de clientes.

El valor predeterminado es ‘"0.0.0.0"’.

parámetro de libvirt-configuration: boolean mdns-adv?

Opción que determina el anuncio mDNS del servicio libvirt.

De manera alternativa puede desactivarse para todos los servicios en una máquina parando el daemon Avahi.

El valor predeterminado es ‘#f

parámetro de libvirt-configuration: string mdns-name

Nombre predeterminado del anuncio mDNS. Debe ser único en la red de distribución inmediata.

El valor predeterminado es ‘"Virtualization Host <hostname>"’.<

parámetro de libvirt-configuration: string unix-sock-group

Grupo propietario del socket de dominio de UNIX. Puede usarse para permitir a un conjunto de usuarias “de confianza” acceso a las funcionalidades de gestión sin convertirse en root.

Defaults to ‘"libvirt"’.

parámetro de libvirt-configuration: string unix-sock-ro-perms

Permisos del socket UNIX de sólo lectura43. Se usa únicamente para monitorizar el estado de las máquinas virtuales.

El valor predeterminado es ‘"0777"’.

parámetro de libvirt-configuration: string unix-sock-rw-perms

Permisos del socket UNIX de lectura/escritura44. El valor predeterminado únicamente permite acceso a root. Si PolicyKit se encuentra activo en el socket, el valor predeterminado cambiará para permitir acceso universal (es decir, 0777).

El valor predeterminado es ‘"0770"’.

parámetro de libvirt-configuration: string unix-sock-admin-perms

Permisos del socket UNIX de administración. El valor predeterminado únicamente permite acceso a la propietaria (root), no lo cambie a menos que esté completamente segura de a quién expone el acceso.

El valor predeterminado es ‘"0777"’.

parámetro de libvirt-configuration: string unix-sock-dir

Directorio en el que los sockets se encuentran/crean.

El valor predeterminado es ‘"/var/run/libvirt"’.

parámetro de libvirt-configuration: string auth-unix-ro

Esquema de identificación para los sockets de solo-lectura de UNIX. Los permisos predeterminados del socket permiten la conexión de cualquier usuaria.

El valor predeterminado es ‘"polkit"’.

parámetro de libvirt-configuration: string auth-unix-rw

Esquema de identificación para los sockets de lectura/escritura de UNIX. Los permisos predeterminados del socket permiten la conexión únicamente a root. Si se activó en la compilación de libvirt la interoperabilidad con PolicyKit, el valor predeterminado es usar la identificación “policykit”.

El valor predeterminado es ‘"polkit"’.

parámetro de libvirt-configuration: string auth-tcp

Esquema de identificación para los sockets TCP. Si no activa SASL, todo el tráfico TCP estará en texto plano. No lo haga más allá de un escenario de desarrollo/pruebas.

El valor predeterminado es ‘"sasl"’.

parámetro de libvirt-configuration: string auth-tls

Esquema de identificación para los sockets TLS. Los sockets TLS ya se encuentran cifrados gracias a la capa TLS, y una identificación limitada se realiza con los certificados.

También es posible hacer uso de cualquier mecanismo de identificación SASL proporcionando “sasl” en esta opción.

El valor predeterminado es ‘"none"’.

parámetro de libvirt-configuration: lista-opcional access-drivers

Esquema de la API de control de acceso.

De manera predeterminada una usuaria identificada puede acceder a todas las API. Los controladores de acceso pueden incluir restricciones de acceso sobre ello.

El valor predeterminado es ‘'()’.

parámetro de libvirt-configuration: string key-file

Ruta del archivo con la clave del servidor. Si se proporciona una cadena vacía, no se carga ninguna clave privada.

El valor predeterminado es ‘""’.

parámetro de libvirt-configuration: string cert-file

Ruta del archivo con la clave del servidor. Si se proporciona una cadena vacía, no se carga ningún certificado.

El valor predeterminado es ‘""’.

parámetro de libvirt-configuration: string ca-file

Ruta del archivo con la clave del servidor. Si se proporciona una cadena vacía, no se carga ningún certificado de CA.

El valor predeterminado es ‘""’.

parámetro de libvirt-configuration: string crl-file

Ruta de la lista de revocaciones de certificado. Si se proporciona una cadena vacía, no se carga ninguna lista.

El valor predeterminado es ‘""’.

parámetro de libvirt-configuration: boolean tls-no-sanity-cert

Desactiva la verificación de los propios certificados del servidor.

Cuando libvirtd arranca, realiza algunas comprobaciones básicas sobre sus propios certificados.

El valor predeterminado es ‘#f

parámetro de libvirt-configuration: boolean tls-no-verify-cert

Desactiva la verificación de certificados de clientes.

La verificación de certificados de cliente es el mecanismo primario de identificación. Se rechazará cualquier cliente que no presente un certificado firmado por la autoridad de certificación (CA).

El valor predeterminado es ‘#f

parámetro de libvirt-configuration: lista-opcional tls-allowed-dn-list

Lista de nombres distinguidos (DN) x509 permitidos.

El valor predeterminado es ‘'()’.

parámetro de libvirt-configuration: lista-opcional sasl-allowed-usernames

Lista de nombres de usuaria SASL permitidos. El formato para el nombre de la usuaria depende del mecanismo de identificación SASL.

El valor predeterminado es ‘'()’.

parámetro de libvirt-configuration: string tls-priority

Cambia el valor de la cadena de prioridad de TLS predeterminada en tiempo de compilación. El valor predeterminado habitualmente es ‘"NORMAL"’ a menos que se cambiase en tiempo de compilación. Proporcione este valor únicamente si desea que libvirt se desvíe de la configuración global predeterminada.

El valor predeterminado es ‘"NORMAL"’.

parámetro de libvirt-configuration: integer max-clients

Número máximo de conexiones concurrentes de clientes permitidas en todos los sockets combinados.

El valor predeterminado es ‘5000’.

parámetro de libvirt-configuration: integer max-queued-clients

Longitud máxima de la cola de conexiones a la espera de ser aceptadas por el daemon. Fíjese que algunos protocolos que implementan la retransmisión pueden obedecer esto de manera que un intento posterior de conexión tenga éxito.

El valor predeterminado es ‘1000’.

parámetro de libvirt-configuration: integer max-anonymous-clients

Longitud máxima de la cola de clientes aceptados pero no identificados todavía. Proporcione el valor cero para desactivar esta característica.

El valor predeterminado es ‘20’.

parámetro de libvirt-configuration: integer min-workers

Número de procesos de trabajo que se lanzarán inicialmente.

El valor predeterminado es ‘5’.

parámetro de libvirt-configuration: integer max-workers

Número máximo de hilos de trabajo.

Si el número de clientes excede min-workers, se lanzan más hilos, hasta el límite max-workers. Habitualmente se desea que max-workers sea igual al número máximo de clientes permitido.

El valor predeterminado es ‘20’.

parámetro de libvirt-configuration: integer prio-workers

Número de procesos de trabajo prioritarios. Si todos los hilos de trabajo del conjunto previo se encuentran bloqueados, algunas llamadas marcadas como de alta prioridad (notablemente domainDestroy) pueden ejecutarse en este conjunto de hilos.

El valor predeterminado es ‘5’.

parámetro de libvirt-configuration: integer max-requests

Límite global total de llamadas RPC concurrentes.

El valor predeterminado es ‘20’.

parámetro de libvirt-configuration: integer max-client-requests

Límite de peticiones concurrentes desde una única conexión de cliente. Para evitar que un cliente monopolice el servidor esto debe ser una pequeña fracción de los parámetros globales “max_requests” y “max_workers”.

El valor predeterminado es ‘5’.

parámetro de libvirt-configuration: integer admin-min-workers

Igual que min-workers pero para la interfaz de administración.

El valor predeterminado es ‘1’.

parámetro de libvirt-configuration: integer admin-max-workers

Igual que max-workers pero para la interfaz de administración.

El valor predeterminado es ‘5’.

parámetro de libvirt-configuration: integer admin-max-clients

Igual que max-clients pero para la interfaz de administración.

El valor predeterminado es ‘5’.

parámetro de libvirt-configuration: integer admin-max-queued-clients

Igual que max-queued-clients pero para la interfaz de administración.

El valor predeterminado es ‘5’.

parámetro de libvirt-configuration: integer admin-max-client-requests

Igual que max-client-requests pero para la interfaz de administración.

El valor predeterminado es ‘5’.

parámetro de libvirt-configuration: integer log-level

Nivel de registro. 4 errores, 3 avisos, 2 información, 1 depuración.

El valor predeterminado es ‘3’.

parámetro de libvirt-configuration: string log-filters

Filtros del registro.

Un filtro permite la selección de un nivel de registro diferente para una categoría dada de registros. El formato del filtro es uno de los siguientes:

  • x:nombre
  • x:+nombre

donde nombre es una cadena contra la que se compara la categoría proporcionada en la llamada VIR_LOG_INIT() al principio de cada archivo de fuentes de libvirt, por ejemplo ‘"remote"’, ‘"qemu"’ o ‘"util.json"’ (el nombre en el filtro puede ser una subcadena del nombre completo de la categoría, para aceptar múltiples categorías con nombres similares), el prefijo opcional ‘"+"’ indica a libvirt que registre la pila de llamadas en cada mensaje con el nombre correspondiente, y x es el nivel mínimo de los mensajes que deben registrarse:

  • 1: DEBUG (depuración)
  • 2: INFO (información)
  • 3: WARNING (aviso)
  • 4: ERROR

Se pueden definir en una única sentencia múltiples filtros, únicamente hace falta separarlos por espacios.

El valor predeterminado es ‘"3:remote 4:event"’.

parámetro de libvirt-configuration: string log-outputs

Salidas de log.

Una salida es uno de esos lugares para almacenar información de logging. El formato para una salida puede ser:

x:stderr

la salida va a stderr

x:syslog:nombre

usa syslog para la salida y usa el nombre proporcionado como identificador

x:file:ruta_archivo

encamina la salida a un archivo, con la ruta proporcionada

x:journald

usa el sistema de logging journald

En todos los casos el prefijo x es el nivel mínimo, que actúa como filtro

  • 1: DEBUG (depuración)
  • 2: INFO (información)
  • 3: WARNING (aviso)
  • 4: ERROR

Se pueden definir salidas múltiples, únicamente deben separarse por espacios.

El valor predeterminado es ‘"3:stderr"’.

parámetro de libvirt-configuration: integer audit-level

Permite la alteración del uso del sistema de auditoría.

  • 0: desactiva la auditoría
  • 1: activa la auditoría, únicamente si está activado en la máquina
  • 2: activa la auditoría, y sale si está desactivada en la máquina.

El valor predeterminado es ‘1’.

parámetro de libvirt-configuration: boolean audit-logging

Envía los mensajes de auditoría a través de la infraestructura de registro de libvirt.

El valor predeterminado es ‘#f

parámetro de libvirt-configuration: string-opcional host-uuid

Host UUID. UUID must not have all digits be the same.

El valor predeterminado es ‘""’.

parámetro de libvirt-configuration: string host-uuid-source

Fuente de lectura del UUID de la máquina anfitriona.

  • smbios: obtiene el UUID de dmidecode -s system-uuid
  • machine-id: obtiene el UUID de /etc/machine-id

Si dmidecode no proporciona un UUID válido, se generará un UUID temporal.

El valor predeterminado es ‘"smbios"’.

parámetro de libvirt-configuration: integer keepalive-interval

Un mensaje “keepalive” se envía al cliente tras keepalive_interval segundos de inactividad para comprobar si el cliente todavía responde. Si se proporciona el valor -1, libvirtd nunca enviará peticiones “keepalive”; no obstante los clientes todavía pueden mandarlas y el daemon enviará las respuestas.

El valor predeterminado es ‘5’.

parámetro de libvirt-configuration: integer keepalive-count

Número máximo de mensajes “keepalive” que se permite enviar a un cliente sin obtener respuesta antes de considerar que se ha roto la conexión.

En otras palabras, la conexión se cierra automáticamente tras keepalive_interval * (keepalive_count + 1) segundos tras la última recepción de un mensaje desde el cliente. Cuando keepalive_count tiene valor 0, las conexiones se cerrarán automáticamente tras keepalive-interval segundos de inactividad sin mandar ningún mensaje “keepalive”.

El valor predeterminado es ‘5’.

parámetro de libvirt-configuration: integer admin-keepalive-interval

Igual que la opción anterior pero para la interfaz de administración.

El valor predeterminado es ‘5’.

parámetro de libvirt-configuration: integer admin-keepalive-count

Igual que la opción anterior pero para la interfaz de administración.

El valor predeterminado es ‘5’.

parámetro de libvirt-configuration: integer ovs-timeout

Plazo máximo para las llamadas a Open vSwitch.

La utilidad ovs-vsctl se usa para la configuración y su opción de plazo máximo (timeout) tiene un valor de 5 segundos de manera predeterminada para evitar que esperas potencialmente infinitas bloqueen libvirt.

El valor predeterminado es ‘5’.

Daemon Virtlog

El servicio virtlogd es un daemon del que se compone el lado servidor de libvirt cuya finalidad es la gestión del registro de las consolas de las máquinas virtuales.

This daemon is not used directly by libvirt client applications, rather it is called on their behalf by libvirtd. By maintaining the logs in a standalone daemon, the main libvirtd daemon can be restarted without risk of losing logs. The virtlogd daemon has the ability to re-exec() itself upon receiving SIGUSR1, to allow live upgrades without downtime.

Variable: virtlog-service-type

Este es el tipo del daemon virtlog. Su valor debe ser un objeto virtlog-configuration.

(service virtlog-service-type
         (virtlog-configuration
          (max-clients 1000)))
libvirt parameter: package libvirt

Paquete libvirt.

parámetro de virtlog-configuration: integer log-level

Nivel de registro. 4 errores, 3 avisos, 2 información, 1 depuración.

El valor predeterminado es ‘3’.

parámetro de virtlog-configuration: string log-filters

Filtros del registro.

Un filtro permite la selección de un nivel de registro diferente para una categoría dada de registros. El formato del filtro es uno de los siguientes:

  • x:nombre
  • x:+nombre

donde nombre es una cadena contra la que se compara la categoría proporcionada en la llamada VIR_LOG_INIT() al principio de cada archivo de fuentes de libvirt, por ejemplo "remote", "qemu" o "util.json" (el nombre en el filtro puede ser una subcadena del nombre completo de la categoría, para aceptar múltiples categorías con nombres similares), el prefijo opcional "+" indica a libvirt que registre la pila de llamadas en cada mensaje con el nombre correspondiente, y x es el nivel mínimo de los mensajes que deben registrarse:

  • 1: DEBUG (depuración)
  • 2: INFO (información)
  • 3: WARNING (aviso)
  • 4: ERROR

Se pueden definir en una única sentencia múltiples filtros, únicamente hace falta separarlos por espacios.

El valor predeterminado es ‘"3:remote 4:event"’.

parámetro de virtlog-configuration: string log-outputs

Salidas de log.

Una salida es uno de esos lugares para almacenar información de logging. El formato para una salida puede ser:

x:stderr

la salida va a stderr

x:syslog:nombre

usa syslog para la salida y usa el nombre proporcionado como identificador

x:file:ruta_archivo

encamina la salida a un archivo, con la ruta proporcionada

x:journald

usa el sistema de logging journald

En todos los casos el prefijo x es el nivel mínimo, que actúa como filtro

  • 1: DEBUG (depuración)
  • 2: INFO (información)
  • 3: WARNING (aviso)
  • 4: ERROR

Se pueden definir salidas múltiples, únicamente deben separarse por espacios.

El valor predeterminado es ‘"3:stderr"’.

parámetro de virtlog-configuration: integer max-clients

Número máximo de conexiones concurrentes de clientes permitidas en todos los sockets combinados.

El valor predeterminado es ‘1024’.

parámetro de virtlog-configuration: integer max-size

Tamaño máximo del archivo antes de pasar al siguiente.

El valor predeterminado es ‘2MB’.

parámetro de virtlog-configuration: integer max-backups

Número máximo de archivos de backup que se deben mantener.

El valor predeterminado es ‘3’.

Emulación transparente con QEMU

qemu-binfmt-service-type proporciona la capacidad de emular transparentemente programas binarios construidos para arquitecturas diferentes—por ejemplo, le permite ejecutar de manera transparente un programa de ARMv7 en una máquina x86_64. Esto se consigue mediante la combinación del emulador QEMU y la característica binfmt_misc del núcleo Linux. Esta característica únicamente le permite emular GNU/Linux en una arquitectura diferente, pero más adelante puede ver como implementar también GNU/Hurd.

Variable: qemu-binfmt-service-type

Este es el tipo del servicio de emulación transparente QEMU/binfmt. Su valor debe ser un objeto qemu-binfmt-configuration, que especifica el paquete QEMU usado así como las arquitecturas que se desean emular:

En este ejemplo se activa la emulación transparente para las plataformas ARM y aarch64. La ejecución de herd stop qemu-binfmt la desactiva, y la ejecución de herd start qemu-binfmt la vuelve a activar (see the herd command in The GNU Shepherd Manual).

Tipo de datos: qemu-binfmt-configuration

Esta es la configuración para el servicio qemu-binfmt.

platforms (predeterminadas: '())

Lista de plataformas de QEMU emuladas. Cada elemento debe ser un objeto de plataforma como los devueltos por lookup-qemu-platforms (véase a continuación).

Por ejemplo, supongamos que está en una máquina x86_64 y tiene este servicio:

Puede ejecutar:

guix build -s armhf-linux inkscape

and it will build Inkscape for ARMv7 as if it were a native build, transparently using QEMU to emulate the ARMv7 CPU. Pretty handy if you’d like to test a package build for an architecture you don’t have access to!

qemu (predeterminado: qemu)

El paquete QEMU usado.

Procedimiento: lookup-qemu-platforms plataformas…

Devuelve la lista de objetos de plataforma de QEMU que corresponden a plataformas…. plataformas debe ser una lista de cadenas que correspondan con nombres de plataforma, como "arm", "sparc", "mips64el", etcétera.

Procedimiento: qemu-platform? obj

Devuelve verdadero si obj es un objeto de plataforma.

Procedimiento: qemu-platform-name plataforma

Devuelve el nombre de plataforma—una cadena como "arm".

QEMU Guest Agent

The QEMU guest agent provides control over the emulated system to the host. The qemu-guest-agent service runs the agent on Guix guests. To control the agent from the host, open a socket by invoking QEMU with the following arguments:

qemu-system-x86_64 \
	-chardev socket,path=/tmp/qga.sock,server=on,wait=off,id=qga0 \
	-device virtio-serial \
	-device virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 \
	...

This creates a socket at /tmp/qga.sock on the host. Once the guest agent is running, you can issue commands with socat:

$ guix shell socat -- socat unix-connect:/tmp/qga.sock stdio
{"execute": "guest-get-host-name"}
{"return": {"host-name": "guix"}}

See QEMU guest agent documentation for more options and commands.

Variable: qemu-guest-agent-service-type

Service type for the QEMU guest agent service.

Data Type: qemu-guest-agent-configuration

Configuration for the qemu-guest-agent service.

qemu (predeterminado: qemu-minimal)

El paquete QEMU usado.

device (default: "")

File name of the device or socket the agent uses to communicate with the host. If empty, QEMU uses a default file name.

Virtual Build Machines

Virtual build machines or “build VMs” let you offload builds to a fully controlled environment. “How can it be more controlled than regular builds? And why would it be useful?”, you ask. Good questions.

Builds spawned by guix-daemon indeed run in a controlled environment; specifically the daemon spawns build processes in separate namespaces and in a chroot, such as that build processes only see their declared dependencies and a well-defined subset of the file system tree (see Configuración del entorno de construcción, for details). A few aspects of the environments are not controlled though: the operating system kernel, the CPU model, and the date. Most of the time, these aspects have no impact on the build process: the level of isolation guix-daemon provides is “good enough”.

However, there are occasionally cases where those aspects do influence the build process. A typical example is time traps: build processes that stop working after a certain date45. Another one is software that optimizes for the CPU microarchitecture it is built on or, worse, bugs that manifest only on specific CPUs.

To address that, virtual-build-machine-service-type lets you add a virtual build machine on your system, as in this example:

(use-modules (gnu services virtualization))

(operating-system
  ;; …
  (services (append (list (service virtual-build-machine-service-type))
                    %base-services)))

By default, you have to explicitly start the build machine when you need it, at which point builds may be offloaded to it (see Uso de la facilidad de delegación de trabajo):

herd start build-vm

With the default setting shown above, the build VM runs with its clock set to a date several years in the past, and on a CPU model that corresponds to that date—a model possibly older than that of your machine. This lets you rebuild today software from the past that would otherwise fail to build due to a time trap or other issues in its build process. You can view the VM’s config like this:

herd configuration build-vm

You can configure the build VM, as in this example:

(service virtual-build-machine-service-type
         (virtual-build-machine
          (cpu "Westmere")
          (cpu-count 8)
          (memory-size (* 1 1024))
          (auto-start? #t)))

The available options are shown below.

Variable: virtual-build-machine-service-type

This is the service type to run virtual build machines. Virtual build machines are configured so that builds are offloaded to them when they are running.

Data Type: virtual-build-machine

This is the data type specifying the configuration of a build machine. It contains the fields below:

name (default: 'build-vm)

The name of this build VM. It is used to construct the name of its Shepherd service.

image

The image of the virtual machine (see Creating System Images). This notably specifies the virtual disk size and the operating system running into it (see Referencia de operating-system). The default value is a minimal operating system image.

qemu (predeterminado: qemu-minimal)

The QEMU package to run the image.

cpu

The CPU model being emulated as a string denoting a model known to QEMU.

The default value is a model that matches date (see below). To see what CPU models are available, run, for example:

qemu-system-x86_64 -cpu help
cpu-count (default: 4)

The number of CPUs emulated by the virtual machine.

memory-size (default: 2048)

Size in mebibytes (MiB) of the virtual machine’s main memory (RAM).

date (default: a few years ago)

Date inside the virtual machine when it starts; this must be a SRFI-19 date object (see SRFI-19 Date in GNU Guile Reference Manual).

port-forwardings (default: 11022 and 11004)

TCP ports of the virtual machine forwarded to the host. By default, the SSH and secrets ports are forwarded into the host.

systems (default: (list (%current-system)))

List of system types supported by the build VM—e.g., "x86_64-linux".

auto-start? (default: #f)

Whether to start the virtual machine when the system boots.

In the next section, you’ll find a variant on this theme: GNU/Hurd virtual machines!

Hurd en una máquina virtual

El servicio hurd-vm implementa la ejecución de GNU/Hurd en una máquina virtual (VM), llamado childhurd. Este servicio está destinado para su uson GNU/Linux y la configuración de sistema operativo de GNU/Hurd se compila de manera cruzada. La máquina virtual es un servicio de Shepherd al que se puede hacer referencia a través de los nombres hurd-vm y childhurd y se puede controlar mediante órdenes como las siguientes:

herd start hurd-vm
herd stop childhurd

Cuando el servicio se encuentra en ejecución, puede ver su consola a través de una conexión con un cliente VNC, por ejemplo con:

guix shell tigervnc-client -- vncviewer localhost:5900

The default configuration (see hurd-vm-configuration below) spawns a secure shell (SSH) server in your GNU/Hurd system, which QEMU (the virtual machine emulator) redirects to port 10022 on the host. By default, the service enables offloading such that the host guix-daemon automatically offloads GNU/Hurd builds to the childhurd (see Uso de la facilidad de delegación de trabajo). This is what happens when running a command like the following one, where i586-gnu is the system type of 32-bit GNU/Hurd:

guix build emacs-minimal -s i586-gnu

childhurd es volátil y carece de estado: comienza con un sistema de archivos raíz creado de cero cada vez que lo reinicia. No obstante de manera predeterminada todos los archivos en la ruta /etc/childhurd de la máquina anfitriona se copian al sistema de archivos raíz de childhurd cuando arranca. Esto permite que configure “secretos” dentro de la máquina virtual: claves de SSH de la máquina, claves de sustituciones autorizadas, etcétera—véase la explicación de secret-root a continuación.

You will probably find it useful to create an account for you in the GNU/Hurd virtual machine and to authorize logins with your SSH key. To do that, you can define the GNU/Hurd system in the usual way (see Uso de la configuración del sistema), and then pass that operating system as the os field of hurd-vm-configuration, as in this example:

(define childhurd-os
  ;; Definition of my GNU/Hurd system, derived from the default one.
  (operating-system
    (inherit %hurd-vm-operating-system)

    ;; Add a user account.
    (users (cons (user-account
                  (name "charlie")
                  (comment "This is me!")
                  (group "users")
                  (supplementary-groups '("wheel"))) ;for 'sudo'
                 %base-user-accounts))

    (services
     ;; Modify the SSH configuration to allow login as "root"
     ;; and as "charlie" using public key authentication.
     (modify-services (operating-system-user-services
                       %hurd-vm-operating-system)
       (openssh-service-type
        config => (openssh-configuration
                   (inherit config)
                   (authorized-keys
                    `(("root"
                       ,(local-file
                         "/home/charlie/.ssh/id_rsa.pub"))
                      ("charlie"
                       ,(local-file
                         "/home/charlie/.ssh/id_rsa.pub"))))))))))

(operating-system
  ;; …
  (services
    ;; Add the 'hurd-vm' service, configured to use the
    ;; operating system configuration above.
    (append (list (service hurd-vm-service-type
                           (hurd-vm-configuration
                             (os %childhurd-os))))
            %base-services)))

That’s it! The remainder of this section provides the reference of the service configuration.

Variable: hurd-vm-service-type

El tipo del servicio que ejecuta Hurd en una máquina virtual. Su valor debe ser un objeto hurd-vm-configuration, que especifica el sistema operativo (see Referencia de operating-system) y el tamaño del disco para la máquina virtual de Hurd, el paquete de QEMU usado así como las opciones de ejecución.

Por ejemplo:

(service hurd-vm-service-type
         (hurd-vm-configuration
          (disk-size (* 5000 (expt 2 20))) ;5G
          (memory-size 1024)))             ;1024MiB

crearía una imagen de disco suficientemente grande para construir GNU Hello, con algo de memoria adicional.

Tipo de datos: hurd-vm-configuration

Tipo de datos que representa la configuración de hurd-vm-service-type.

os (predeterminado: %hurd-vm-operating-system)

El sistema operativo instanciado. El valor predeterminado es un sistema mínimo con un daemon del intérprete de comandos seguro OpenSSH configurado de forma permisiva asociado al puerto 2222 (see openssh-service-type).

qemu (predeterminado: qemu-minimal)

El paquete QEMU usado.

image (predeterminado: hurd-vm-disk-image)

The image object representing the disk image of this virtual machine (see Creating System Images).

disk-size (predeterminado: 'guess)

El tamaño de la imagen de disco.

memory-size (predeterminado: 512)

El tamaño de la memoria de la máquina virtual en mebibytes.

options (predeterminadas: '("--snapshot"))

Opciones adicionales para ejecutar QEMU.

id (predeterminado: #f)

Si se proporciona un valor, debe ser un entero positivo no nulo usado para parametrizar las instancias Childhurd. Se añade al nombre del servicio, por ejemplo childhurd1.

net-options (predeterminado: hurd-vm-net-options)

El procedimiento usado para producir la lista de opciones de red para QEMU.

De manera predeterminada produce

'("--device" "rtl8139,netdev=net0"
  "--netdev" (string-append
              "user,id=net0,"
              "hostfwd=tcp:127.0.0.1:secrets-port-:1004,"
              "hostfwd=tcp:127.0.0.1:ssh-port-:2222,"
              "hostfwd=tcp:127.0.0.1:vnc-port-:5900"))

con los siguientes puertos redirigidos:

secrets-port: (+ 11004 (* 1000 ID))
ssh-port: (+ 10022 (* 1000 ID))
vnc-port: (+ 15900 (* 1000 ID))
offloading? (default: #t)

Whether to automatically set up offloading of builds to the childhurd.

When enabled, this lets you run GNU/Hurd builds on the host and have them transparently offloaded to the VM, for instance when running a command like this:

guix build coreutils -s i586-gnu

This option automatically sets up offloading like so:

  1. Authorizing the childhurd’s key on the host so that the host accepts build results coming from the childhurd, which can be done like so (see guix archive --authorize, for more on that).
  2. Creating a user account called offloading dedicated to offloading in the childhurd.
  3. Creating an SSH key pair on the host and making it an authorized key of the offloading account in the childhurd.
  4. Añadir childhurd a /etc/guix/machines.scm (see Uso de la facilidad de delegación de trabajo).
secret-root (predeterminado: /etc/childhurd)

El directorio raíz que contiene los secretos fuera-de-banda que serán instalados en childhurd cuando se ejecute. Los childhurd son volátiles lo que significa que cada arranque los secretos como las claves de SSH de la máquina y la clave de firma de Guix se regeneran.

Si el directorio /etc/childhurd no existe, el servicio secret-service que se ejecuta en childhurd recibirá una lista vacía de secretos.

De manera predeterminada el servicio crea /etc/childhurd con los siguientes secretos no volátiles, a no ser que ya existan:

/etc/childhurd/etc/guix/acl
/etc/childhurd/etc/guix/signing-key.pub
/etc/childhurd/etc/guix/signing-key.sec
/etc/childhurd/etc/ssh/authorized_keys.d/offloading
/etc/childhurd/etc/ssh/ssh_host_ed25519_key
/etc/childhurd/etc/ssh/ssh_host_ecdsa_key
/etc/childhurd/etc/ssh/ssh_host_ed25519_key.pub
/etc/childhurd/etc/ssh/ssh_host_ecdsa_key.pub

Tenga en cuenta que la imagen de la máquina virtual es volátil, es decir, los contenidos se pierden cuando se para. Si desea una imagen que mantenga el estado puede modificar la configuración de image y options sin la opción --snapshot usando algo parecido a esto:

(service hurd-vm-service-type
         (hurd-vm-configuration
          (image   (const "/no/almacen/y/perm/escritura/hurd.img"))
          (options '())))

Ganeti

Nota: Este servicio se considera experimental. Las opciones de configuración pueden cambiar de manera incompatible con versiones previas, y no todas las características han sido probadas en profundidad. Se recomienda a quienes usen este servicio que compartan su experiencia en guix-devel@gnu.org.

Ganeti is a virtual machine management system. It is designed to keep virtual machines running on a cluster of servers even in the event of hardware failures, and to make maintenance and recovery tasks easy. It consists of multiple services which are described later in this section. In addition to the Ganeti service, you will need the OpenSSH service (see openssh-service-type), and update the /etc/hosts file (see hosts-service-type) with the cluster name and address (or use a DNS server).

Todos los nodos que participan en el cluster de Ganeti deben tener la misma configuración de Ganeti y en el archivo /etc/hosts. A continuación se encuentra un ejemplo de configuración para un nodo del cluster de Ganeti que implementa varios motores de almacenamiento, e instala los proveedores de sistema operativo debootstrap y guix:

(use-package-modules virtualization)
(use-service-modules base ganeti networking ssh)
(operating-system
  ;; …
  (host-name "node1")

  ;; Install QEMU so we can use KVM-based instances, and LVM, DRBD and Ceph
  ;; in order to use the "plain", "drbd" and "rbd" storage backends.
  (packages (append (map specification->package
                         '("qemu" "lvm2" "drbd-utils" "ceph"
                           ;; Add the debootstrap and guix OS providers.
                           "ganeti-instance-guix" "ganeti-instance-debootstrap"))
                    %base-packages))
  (services
   (append (list (service static-networking-service-type
                          (list (static-networking
                                 (addresses
                                  (list (network-address
                                         (device "eth0")
                                         (value "192.168.1.201/24"))))
                                 (routes
                                  (list (network-route
                                         (destination "default")
                                         (gateway "192.168.1.254"))))
                                 (name-servers '("192.168.1.252"
                                                 "192.168.1.253")))))

                 ;; Ganeti uses SSH to communicate between nodes.
                 (service openssh-service-type
                          (openssh-configuration
                           (permit-root-login 'prohibit-password)))

                 (simple-service 'ganeti-hosts-entries hosts-service-type
                                 (list
                                   (host "192.168.1.200" "ganeti.example.com")
                                   (host "192.168.1.201" "node1.example.com"
                                         '("node1"))
                                   (host "192.168.1.202" "node2.example.com"
                                         '("node2"))))

                 (service ganeti-service-type
                          (ganeti-configuration
                           ;; Esta lista especifica las rutas del
                           ;; sistema de archivos permitidas para el
                           ;; almacenamiento de imágenes de máquinas
                           ;; viruales.
                           (file-storage-paths '("/srv/ganeti/almacenamiento"))
                           ;; Esta variable configura una única
                           ;; "variación" tanto para Debootstrap como
                           ;; Guix que funciona con KVM.
                           (os %default-ganeti-os))))
           %base-services)))

Users are advised to read the Ganeti administrators guide to learn about the various cluster options and day-to-day operations. There is also a blog post describing how to configure and initialize a small cluster.

Variable: ganeti-service-type

Tipo de servicio que incluye todos los distintos servicios que los nodos Ganeti deben ejecutar.

Su valor es un objeto ganeti-configuration que define usado para las operaciones de línea de órdenes, así como la configuración para varios daemon. Las rutas de almacenamiento permitidas y los sistemas operativos disponibles para hospedar también se configuran a través de este tipo de datos.

Tipo de datos: ganeti-configuration

El servicio ganeti proporciona las siguientes opciones de configuración:

ganeti (predeterminado: ganeti)

El paquete ganeti usado. Dicho paquete se instala en el perfil del sistema y hace que las órdenes gnt-cluster, gnt-instance, etcétera, estén disponibles. Tenga en cuenta que el valor especificado aquí no afecta a otros servicios ya que cada uno hace referencia a su paquete ganeti específico (véase a continuación).

noded-configuration (predeterminado: (ganeti-noded-configuration))
confd-configuration (predeterminado: (ganeti-confd-configuration))
wconfd-configuration (predeterminado: (ganeti-wconfd-configuration))
luxid-configuration (predeterminado: (ganeti-luxid-configuration))
rapi-configuration (predeterminado: (ganeti-rapi-configuration))
kvmd-configuration (predeterminado: (ganeti-kvmd-configuration))
mond-configuration (predeterminado: (ganeti-mond-configuration))
metad-configuration (predeterminado: (ganeti-metad-configuration))
watcher-configuration (predeterminado: (ganeti-watcher-configuration))
cleaner-configuration (predeterminado: (ganeti-cleaner-configuration))

Estas opciones controlan los distintos daemon y trabajos de cron que se distribuyen con Ganeti. Los posibles valores se describen en detalle a continuación. Para modificar el valor de un elemento de la configuración se debe usar el tipo de configuración para dicho servicio:

(service ganeti-service-type
         (ganeti-configuration
          (rapi-configuration
           (ganeti-rapi-configuration
            (interface "eth1"))))
          (watcher-configuration
           (ganeti-watcher-configuration
            (rapi-ip "10.0.0.1"))))
file-storage-paths (predeterminada: '())

Lista de directorios permitidos para el motor de almacenamiento de archivos.

hooks (default: #f)

When set, this should be a file-like object containing a directory with cluster execution hooks.

os (predeterminado: %default-ganeti-os)

Lista de registros <ganeti-os>.

En esencia ganeti-service-type es una abreviación para declara cada uno de los servicios individualmente:

Además de una extensión del servicio etc-service-type que configura el motor de almacenamiento de archivos y las variantes de sistema operativo.

Tipo de datos: ganeti-os

Tipo de datos adecuado para proporcionarse como parámetro os de ganeti-configuration. Tiene los siguientes parámetros:

name

Nombre para este proveedor de sistema operativo. Solo se usa para especificar dónde termina la configuración. Proporcionar el valor “debootstrap” indica la creación de /etc/ganeti/instance-debootstrap.

extension (default: #f)

The file extension for variants of this OS type. For example .conf or .scm. It will be appended to the variant file name if set.

variants (predeterminadas: '())

This must be either a list of ganeti-os-variant objects for this OS, or a “file-like” object (see file-like objects) representing the variants directory.

To use the Guix OS provider with variant definitions residing in a local directory instead of declaring individual variants (see guix-variants below), you can do:

(ganeti-os
 (name "guix")
 (variants (local-file "ganeti-guix-variants"
                       #:recursive? #true)))

Note that you will need to maintain the variants.list file (see ganeti-os-interface(7)) manually in this case.

Tipo de datos: ganeti-os-variant

Tipo de datos que representa una variante de SO Ganeti. Este tipo tiene los siguientes parámetros:

name

El nombre de esta variación.

configuration

Un archivo de configuración para esta variación.

Variable: %default-debootstrap-hooks

Esta variable contiene extensiones (“hook”) para la configuración de la red y el cargador de arranque GRUB.

Variable: %default-debootstrap-extra-pkgs

Esta variable contiene una lista de paquetes adecuada para una máquina completamente virtualizada.

Tipo de datos: debootstrap-configuration

Este tipo de datos crea archivos de configuración adecuados para la orden de generación de sistemas operativos debootstrap.

hooks (predeterminada: %default-debootstrap-hooks)

Cuando no es #f debe ser una expresión-G que especifique el directorio con los guiones que deberán ejecutarse cuando se instale el sistema operativo. También puede ser una lista de pares (nombre . obj-tipo-archivo). Por ejemplo:

`((99-hola-mundo . ,(plain-file "#!/bin/sh\necho '¡Hola mundo!'")))

Esto crea un directorio con un ejecutable que se llama 99-hola-mundo y se ejecuta cada vez que se instale esta variación. Si se proporciona #f, se usarán los archivos del directorio /etc/ganeti/instance-debootstrap/hooks, si existe alguno.

proxy (predeterminado: #f)

Valor opcional de la pasarela HTTP usada.

mirror (predeterminado: #f)

El servidor espejo de Debian. Habitualmente es algo como http://ftp.no.debian.org/debian. El valor predeterminado cambia dependiendo de la distribución.

arch (predeterminada: #f)

La arquitectura de dpkg. Proporcione armhf para generar con debootstrap una instancia de ARMv7 en una máquina AArch64. El valor predeterminado corresponde a la arquitectura del sistema en uso.

suite (predeterminada: "stable")

Si se proporciona debe ser el identificador de una entrega o “suite” de distribución de Debian, como por ejemplo buster o focal. Si se proporciona #f, se usael valor predeterminado del proveedor de sistema operativo.

extra-pkgs (predeterminados: %default-debootstrap-extra-pkgs)

Lista de paquetes adicionales que dpkg instala junto al sistema mínimo.

components (predeterminado: #f)

Si se proporciona un valor debe ser una lista de “componentes” de repositorio de Debian. Por ejemplo '("main" "contrib").

generate-cache? (predeterminado: #t)

Determina si se almacena en caché de manera automática el archivo de debootstrap que se haya generado.

clean-cache (predeterminado: 14)

Descarta el contenido de la caché tras este número de días. Use #f para no descartar contenido de la caché nunca.

partition-style (predeterminado: 'msdos)

Tipo de partición creado. Cuando se proporciona un valor debe ser 'msdos, 'none o una cadena.

partition-alignment (predeterminada: 2048)

Alineación de la partición en sectores.

Procedimiento: debootstrap-variant nombre configuración

Procedimiento auxiliar que crea un registro ganeti-os-variant. Toma dos parámetros: un nombre y un objeto debootstrap-configuration.

Procedimiento: debootstrap-os variantes…

Procedimiento auxiliar que crea un registro ganeti-os. Toma como parámetro una lista de variaciones creada con debootstrap-variant.

Procedimiento: guix-variant nombre configuración

Procedimiento auxiliar que crea un registro ganeti-os-variant para ser usado por el proveedor de sistema operativo Guix. Toma como parámetros un nombre y una expresión-G que devuelve un objeto “tipo-archivo” (see objetos “tipo-archivo”) que contiene configuración para el sistema Guix.

Procedimiento: guix-os variantes…

Procedimiento auxiliar que crea un registro ganeti-os. Toma como parámetros una lista de variaciones producida por guix-variant.

Variable: %default-debootstrap-variants

Variable de conveniencia para que el proveedor debootstrap funcione “automágicamente” sin que quienes lo usan tengan que declarar variaciones manualmente. Contiene una única variación de debootstrap con la configuración predeterminada:

Variable: %default-guix-variants

Variable de conveniencia para que el proveedor de sistema operativo Guix funcione sin ninguna configuración adicional. Crea una máquina virtual que tiene un servidor SSH, consola serie y autoriza las claves de SSH de las máquinas de Ganeti.

(list (guix-variant
       "default"
       (file-append ganeti-instance-guix
                    "/share/doc/ganeti-instance-guix/examples/dynamic.scm")))

Se pueden implementar proveedores de SO no disponibles en Guix mediante la extensión de los registros ganeti-os y ganeti-os-variant de manera apropiada. Por ejemplo:

(ganeti-os
 (name "personalizado")
 (extension ".conf")
 (variants
  (list (ganeti-os-variant
         (name "cosa")
         (configuration (plain-file "archivo" "Esto va bien"))))))

Este ejemplo crearía /etc/ganeti/instance-personalizado/variants/cosa.conf, el cual apunta a un archivo en el almacén cuyo contenido es esto va bien. También se crearía /etc/ganeti/instance-personalizado/variants/variants.list con el contenido cosa.

Obviamente es posible que esto no funcione con todos los proveedores de sistema operativo existentes. Si está interfaz le está limitando en su implementación, por favor, contacte con guix-devel@gnu.org.

El resto de esta sección documenta los distintos servicios incluidos en ganeti-service-type.

Variable: ganeti-noded-service-type

ganeti-noded es el daemon responsable de las funciones específicas del nodo dentro del sistema Ganeti. El valor de este servicio debe ser un objeto ganeti-noded-configuration.

Tipo de datos: ganeti-noded-configuration

Esta es la configuración para el servicio ganeti-noded.

ganeti (predeterminado: ganeti)

El paquete ganeti usado para este servicio.

port (predeterminado: 1811)

Puerto TCP en el que escucha el daemon del nodo a la espera de peticiones a través de la red.

address (predeterminado: "0.0.0.0")

La dirección de red a la que el daemon se enlaza. La dirección predeterminada significa que el daemon se enlaza a todas las direcciones disponibles.

interface (predeterminado: #f)

En caso de proporcionarse un valor, debe especificar el nombre de la interfaz de red (por ejemplo, eth0 a la que el daemon se enlaza.

max-clients (predeterminado: 20)

Establece un límite en el número máximo de conexiones simultaneas de clientes que el daemon manejará. Las conexiones que excedan dicho número se aceptan, pero no se envía respuesta hasta que hayan cerrado suficientes conexiones.

ssl? (predeterminado: #t)

Determina si se usa SSL/TLS para cifrar las comunicaciones a través de la red. El cluster proporciona automáticamente el certificado y se puede rotar con gnt-cluster renew-crypto.

ssl-key (predeterminado: "/var/lib/ganeti/server.pem")

Puede usarse para proporcionar una clave de cifrado específica para comunicaciones TLS.

ssl-cert (predeterminado: "/var/lib/ganeti/server.pem")

Puede usarse para proporcionar un certificado específico para comunicaciones TLS.

debug? (predeterminado: #f)

Cuando es verdadero, el daemon almacena registros adicionales con propósitos de depuración. Tenga en cuenta que esto puede exponer detalles de cifrado en los archivos de registro, por lo que debe usarse con precaución.

Variable: ganeti-confd-service-type

ganeti-confd responde a las consultas relacionadas con la configuración del cluster Ganeti. El propósito de este daemon es tener una forma rápida y con alta disponibilidad de consultar los valores de configuración del cluster. Se activa de manera automática en todas las máquinas candidatas de ser coordinadoras. El valor de este servicio debe ser un objeto ganeti-confd-configuration.

Tipo de datos: ganeti-confd-configuration

Esta es la configuración para el servicio ganeti-confd.

ganeti (predeterminado: ganeti)

El paquete ganeti usado para este servicio.

port (predeterminado: 1814)

El puerto UDP en el que esperarán peticiones a través de la red.

address (predeterminado: "0.0.0.0")

Dirección de red a la que el daemon se asocia.

debug? (predeterminado: #f)

Cuando es verdadero, el daemon almacena registros adicionales con propósitos de depuración.

Variable: ganeti-wconfd-service-type

ganeti-wconfd es el daemon que proporciona una autoridad de conocimiento sobre la configuración del cluster y es la única entidad que puede aceptar cambios sobre ella. Todos las trabajos que necesiten modificar la configuración deben hacerlo enviando las peticiones adecuadas a este daemon. Únicamente se ejecuta en el nodo coordinador y se desactiva automáticamente en otros nodos.

El valor de este servicio debe ser un objeto ganeti-wconfd-configuration.

Tipo de datos: ganeti-wconfd-configuration

Esta es la configuración para el servicio ganeti-wconfd.

ganeti (predeterminado: ganeti)

El paquete ganeti usado para este servicio.

no-voting? (predeterminado: #f)

El daemon se negará a arrancar si la mayoría de los nodos del cluster no coinciden en que se está ejecutando en el nodo coordinador. Proporcione #t para arrancar incluso cuando no se puede alcanzar dicha mayoría (peligroso, úsese con precaución).

debug? (predeterminado: #f)

Cuando es verdadero, el daemon almacena registros adicionales con propósitos de depuración.

Variable: ganeti-luxid-service-type

ganeti-luxid es un daemon que responde a las peticiones relacionadas con la configuración del estado actual del cluster Ganeti. De manera adicional, es el daemon que tiene el control sobre la cola de trabajos de Ganeti. Los trabajos se pueden emitir a través de este daemon y éste los planifica y arranca.

Recibe un objeto ganeti-luxid-configuration.

Tipo de datos: ganeti-luxid-configuration

This is the configuration for the ganeti-luxid service.

ganeti (predeterminado: ganeti)

El paquete ganeti usado para este servicio.

no-voting? (predeterminado: #f)

El daemon se negará a arrancar si no puede verificar que la mayoría de los nodos del cluster creen que éste se está ejecutando en el nodo coordinador. Proporcione #t para ignorar dichas comprobaciones y arrancar en cualquier caso (puede ser peligroso).

debug? (predeterminado: #f)

Cuando es verdadero, el daemon almacena registros adicionales con propósitos de depuración.

Variable: ganeti-rapi-service-type

ganeti-rapi proporciona una API remota para cluster de Ganeti. Se ejecuta en el nodo coordinador y se puede usar para realizar programática acciones en el cluster a través de un protocolo de llamada de procedimientos remotos (RPC) basado en JSON.

Se permiten la mayoría de las operaciones de consulta sin identificación (a no ser que se especifique require-authentication?), mientras que las operaciones de escritura necesitan autorización explícita a través del archivo /var/lib/ganeti/rapi/users. Véase la documentación de la API remota de Ganeti para obtener más información.

El valor de este servicio debe ser un objeto ganeti-rapi-configuration.

Tipo de datos: ganeti-rapi-configuration

Configuración para el servicio ganeti-rapi.

ganeti (predeterminado: ganeti)

El paquete ganeti usado para este servicio.

require-authentication? (predeterminado: #f)

Determina si se requiere identificación incluso para operaciones únicamente de lectura.

port (predeterminado: 5080)

El puerto TCP en el que esperarán peticiones de la API.

address (predeterminado: "0.0.0.0")

La dirección de red a la que se asocia el servicio. De manera predeterminada el servicio se asocia a todas las direcciones configuradas.

interface (predeterminado: #f)

Si se proporciona un valor, debe especificar el nombre de la interfaz de red, como por ejemplo eth0, a la que el daemon se asocia.

max-clients (predeterminado: 20)

Número máximo de conexiones simultaneas de clientes que se manejan. Las conexiones que excedan dicho número se aceptan, pero no se envía respuesta hasta que hayan cerrado suficientes conexiones.

ssl? (predeterminado: #t)

Determina si se usa cifrado SSL/TLS en el puerto de la API remota.

ssl-key (predeterminado: "/var/lib/ganeti/server.pem")

Puede usarse para proporcionar una clave de cifrado específica para comunicaciones TLS.

ssl-cert (predeterminado: "/var/lib/ganeti/server.pem")

Puede usarse para proporcionar un certificado específico para comunicaciones TLS.

debug? (predeterminado: #f)

Cuando es verdadero, el daemon almacena registros adicionales con propósitos de depuración. Tenga en cuenta que esto puede exponer detalles de cifrado en los archivos de registro, por lo que debe usarse con precaución.

Variable: ganeti-kvmd-service-type

ganeti-kvmd es responsable de determinar si una instancia KVM determinada ha sido apagada por una usuaria o una administradora. Normalmente Ganeti reiniciará una instancia que no se haya parado a través de Ganeti. Si la opción del cluster user_shutdown es verdadera, este daemon monitoriza el puerto QMP que proporciona QEMU y escucha eventos de apagado en él, y marca la instancia como USER_down en vez de ERROR_down cuando el daemon la apaga de manera adecuada.

Recibe un objeto ganeti-kvmd-configuration.

Tipo de datos: ganeti-kvmd-configuration
ganeti (predeterminado: ganeti)

El paquete ganeti usado para este servicio.

debug? (predeterminado: #f)

Cuando es verdadero, el daemon almacena registros adicionales con propósitos de depuración.

Variable: ganeti-mond-service-type

ganeti-mond es un daemon opcional que proporciona la funcionalidad de monitorización de Ganeti. Es responsable de la ejecución de los recolectores de datos y la publicación de la información obtenida a través de una interfaz HTTP.

Recibe un objeto ganeti-mond-configuration.

Tipo de datos: ganeti-mond-configuration
ganeti (predeterminado: ganeti)

El paquete ganeti usado para este servicio.

port (predeterminado: 1815)

Puerto en el que el daemon espera conexiones.

address (predeterminado: "0.0.0.0")

La dirección de red a la que se asocia el daemon. De manera predeterminada se asocia a todas las interfaces disponibles.

debug? (predeterminado: #f)

Cuando es verdadero, el daemon almacena registros adicionales con propósitos de depuración.

Variable: ganeti-metad-service-type

ganeti-metad es un daemon opcional que se puede usar para proporcionar información del cluster a instancias o guiones de instalación de sistema operativo.

Recibe un objeto ganeti-metad-configuration.

Tipo de datos: ganeti-metad-configuration
ganeti (predeterminado: ganeti)

El paquete ganeti usado para este servicio.

port (predeterminado: 80)

Puerto en el que el daemon espera conexiones.

address (predeterminada: #f)

Si se proporciona un valor el daemon se asociará únicamente a esta dirección. Si no se proporciona valor el comportamiento depende de la configuración del cluster.

debug? (predeterminado: #f)

Cuando es verdadero, el daemon almacena registros adicionales con propósitos de depuración.

Variable: ganeti-watcher-service-type

ganeti-watcher es un guión diseñado para su ejecución periódica en la que comprueba el estado la salud del cluster. Reinicia automáticamente las instancias que se han parado sin el consentimiento de Ganeti, y repara los enlaces DRBD en caso de que un nodo se haya reiniciado. También archiva los trabajos antiguos del cluster y reinicia los daemon de Ganeti si no se están ejecutando. Si se ha proporcionado valor al parámetro del cluster ensure_node_health, este proceso también apagará las instancias y dispositivos DRBD si el nodo que las ejecute se ha declarado fuera de línea por alguna de las máquinas candidatas de coordinación conocidas.

Se puede pausar en todos los nodos con gnt-cluster watcher pause.

Este servicio toma como valor un objeto ganeti-watcher-configuration.

Tipo de datos: ganeti-watcher-configuration
ganeti (predeterminado: ganeti)

El paquete ganeti usado para este servicio.

schedule (predeterminado: '(next-second-from (next-minute (range 0 60 5))))

Cada cuanto se ejecuta el guión. El valor predeterminado es cada 5 minutos.

rapi-ip (predeterminada: #f)

Esta opción se debe especificar únicamente si el daemon de API remota se ha configurado para usar una interfaz o dirección de red concreta. De manera predeterminada se usa la dirección del cluster.

job-age (predeterminados: (* 6 3600))

Archiva los trabajos del cluster cuya antigüedad sea mayor que el el número de segundos proporcionado. El valor predeterminado son 6 horas. Esto mantiene la lista proporcionada gnt-job list dentro de límites gestionables.

verify-disks? (predeterminado: #t)

Si es #f, el proceso de vigilancia (“watcher”) no intentará reparar los enlaces de DRBD rotos de manera automática. Esto significa que quienes administren el sistema deberán usar gnt-cluster verify-disks manualmente para realizar dicha tarea.

debug? (predeterminado: #f)

Cuando es #t, el guión registra información adicional para facilitar la depuración.

Variable: ganeti-cleaner-service-type

ganeti-cleaner es un guión diseñado para su ejecución periódica en la que elimina archivos antiguos del cluster. Este tipo de servicio controla dos trabajos de cron: uno para el nodo coordinador que elimina de manera permanente trabajos antiguos del cluster, y otro para todos los nodos que elimina certificados X509 y claves que hayan expirado así como información desactualizada de ganeti-watcher. Como todos los servicios de Ganeti, se puede incluir también en los nodos que no son coordinadores y se desactivará por si mismo si es necesario.

Recibe un objeto ganeti-cleaner-configuration.

Tipo de datos: ganeti-cleaner-configuration
ganeti (predeterminado: ganeti)

El paquete ganeti usado para la orden gnt-cleaner.

master-schedule (predeterminado: "45 1 * * *")

Cada cuanto se ejecuta el trabajo principal de limpieza. El valor predeterminado representa su ejecución una vez al día, a las 01:45:00.

node-schedule (predeterminada: "45 2 * * *")

La frecuencia del trabajo de limpieza del nodo. El valor predeterminado es una vez al día, a las 02:45:00.


Footnotes

(43)

R/O: Read-Only en inglés.

(44)

R/W: Read-Write en inglés.

(45)

The most widespread example of time traps is test suites that involve checking the expiration date of a certificate. Such tests exists in TLS implementations such as OpenSSL and GnuTLS, but also in high-level software such as Python.


Next: Servicios de control de versiones, Previous: Servicios de audio, Up: Servicios   [Contents][Index]