102.6 Lección 1

Certificación:

LPIC-1

Versión:

5.0

Tema:

102 Instalación de Linux y Administración de Paquetes

Objectivo:

102.6 Linux como huésped de virtualización

Lección:

1 de 1

Introducción

Una de las grandes fortalezas de Linux es su versatilidad. Un aspecto de esta versatilidad es la capacidad de usar Linux como medio para alojar otros sistemas operativos, o aplicaciones individuales, en un entorno completamente aislado y seguro. Esta lección se centrará en los conceptos de virtualización y tecnologías de contenedor, junto con algunos detalles técnicos que deben tenerse en cuenta al implementar una máquina virtual en una plataforma en la nube.

Descripción general de virtualización

La virtualización es una tecnología que permite que una plataforma de software, llamada hipervisor (hypervisor), ejecute procesos que contienen un sistema informático completamente emulado. El hipervisor es responsable de administrar los recursos del hardware físico que pueden ser utilizados por máquinas virtuales individuales. Estas máquinas virtuales se denominan guests del hipervisor. Una máquina virtual tiene muchos aspectos de una computadora física emulada en software, como el BIOS del sistema y los controladores de disco del disco duro. Una máquina virtual a menudo usará imágenes de disco duro que se almacenan como archivos individuales, y tendrá acceso a la RAM y CPU de la máquina host a través del software del hipervisor. El hipervisor separa el acceso a los recursos de hardware del sistema host entre los guest, lo que permite que múltiples sistemas operativos se ejecuten en un solo sistema host.

Los hipervisores de uso común en Linux son:

Xen: Xen es un hipervisor de código abierto de tipo 1, lo que significa que no depende de un sistema operativo subyacente para funcionar. Un hipervisor de este tipo se conoce como un hipervisor de bare-metal hypervisor, ya que la computadora puede arrancar directamente en el hipervisor.
KVM: Kernel Virtual Machine es un módulo de kernel de Linux para virtualización. KVM es un hipervisor tanto del hipervisor Tipo 1 como del Tipo 2 porque, aunque necesita un sistema operativo Linux genérico para funcionar, puede funcionar perfectamente como hipervisor al integrarse con una instalación Linux en ejecución. Las máquinas virtuales implementadas con KVM usan el demonio libvirt y las utilidades de software asociadas para ser creadas y administradas.
VirtualBox: Una aplicación de escritorio popular que facilita la creación y administración de máquinas virtuales. Oracle VM VirtualBox es multiplataforma y funciona en Linux, macOS y Microsoft Windows. Como VirtualBox requiere de un sistema operativo subyacente para ejecutarse, es un hipervisor de tipo 2.

Algunos hipervisores permiten la reubicación dinámica de una máquina virtual. El proceso de mover una máquina virtual de una instalación de hipervisor a otra se llama migration, y las técnicas involucradas difieren entre las implementaciones de hipervisor. Algunas migraciones solo se pueden realizar cuando el sistema invitado se ha apagado por completo, y otras se pueden realizar mientras el invitado se está ejecutando (denominado live migration). Dichas técnicas pueden ser útiles durante los mantenimientos de los hipervisores, o para la resistencia del sistema cuando un hipervisor deja de funcionar y el huésped puede ser trasladado a un hipervisor que esté funcionando.

Tipos de Máquinas Virtuales

Hay tres tipos principales de máquinas virtuales: el fully virtualized guest (un invitado totalmente virtualizado), el paravirtualized guest (un invitado paravirtualizado) y el hybrid guest (un invitado híbrido).

Totalmente virtualizado (Fully Virtualized): Todas las instrucciones que se espera que ejecute un sistema operativo invitado deben poder ejecutarse dentro de una instalación de sistema operativo totalmente virtualizada. La razón de esto es que no se instalan controladores de software adicionales dentro del huésped para traducir las instrucciones a hardware simulado o real. Un invitado totalmente virtualizado es aquel en el que el invitado (o HardwareVM) desconoce que es una instancia de máquina virtual en ejecución. Para que este tipo de virtualización tenga lugar en hardware basado en x86, las extensiones de CPU Intel VT-x o AMD-V deben estar habilitadas en el sistema que tiene instalado el hipervisor. Esto se puede hacer desde un menú de configuración de firmware BIOS o UEFI.
Paravirtualizado (Paravirtualized): Un invitado paravirtualizado (o PVM) es aquel en el que el sistema operativo invitado es consciente de que es una instancia de máquina virtual en ejecución. Este tipo de invitados utilizará un kernel modificado y controladores especiales (conocidos como "controladores invitados") que ayudarán al sistema operativo invitado a utilizar los recursos de software y hardware del hipervisor. El rendimiento de un huésped paravirtualizado es a menudo mejor que el del huésped totalmente virtualizado debido a la ventaja que proporcionan estos controladores de software.
Híbrido (Hybrid): La paravirtualización y la virtualización completa se pueden combinar para permitir que los sistemas operativos no modificados reciban un rendimiento de E/S casi nativo mediante el uso de controladores paravirtualizados en sistemas operativos completamente virtualizados. Los controladores paravirtualizados contienen controladores de almacenamiento y dispositivos de red con disco mejorado y rendimiento de E/S de red.

Las plataformas de virtualización a menudo proporcionan controladores invitados empaquetados para sistemas operativos virtualizados. El KVM utiliza controladores del proyecto Virtio, mientras que Oracle VM VirtualBox utiliza Guest Extensions disponibles desde un archivo de imagen de CD-ROM ISO descargable.

Ejemplo de máquina virtual `libvirt`

Veremos un ejemplo de máquina virtual que es administrada por libvirt y usa el hipervisor KVM. Una máquina virtual a menudo consiste en un grupo de archivos, principalmente un archivo XML que define la máquina virtual (como su configuración de hardware, conectividad de red, capacidades de visualización y más) y un archivo de imagen de disco duro asociado que contiene la instalación del sistema operativo y su software.

Primero, comencemos a examinar un archivo de configuración XML de ejemplo para una máquina virtual y su entorno de red:

$ ls /etc/libvirt/qemu
total 24
drwxr-xr-x 3 root root 4096 Oct 29 17:48 networks
-rw------- 1 root root 5667 Jun 29 17:17 rhel8.0.xml

Note

La parte qemu de la ruta del directorio se refiere al software subyacente en el que confían las máquinas virtuales basadas en KVM. El proyecto QEMU proporciona software para que el hipervisor emule dispositivos de hardware que usará la máquina virtual, como controladores de disco, acceso a la CPU del host, emulación de tarjeta de red y más.

Tenga en cuenta que hay un directorio llamado networks. Este directorio contiene archivos de definición (también usando XML) que crean configuraciones de red que las máquinas virtuales pueden usar. Este hipervisor solo utiliza una red, por lo que solo hay un archivo de definición que contiene una configuración para un segmento de red virtual que utilizarán estos sistemas.

$ ls -l /etc/libvirt/qemu/networks/
total 8
drwxr-xr-x 2 root root 4096 Jun 29 17:15 autostart
-rw------- 1 root root  576 Jun 28 16:39 default.xml
$ sudo cat /etc/libvirt/qemu/networks/default.xml
<!--
WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE
OVERWRITTEN AND LOST. Changes to this xml configuration should be made using:
  virsh net-edit default
or other application using the libvirt API.
-->

<network>
  <name>default</name>
  <uuid>55ab064f-62f8-49d3-8d25-8ef36a524344</uuid>
  <forward mode='nat'/>
  <bridge name='virbr0' stp='on' delay='0'/>
  <mac address='52:54:00:b8:e0:15'/>
  <ip address='192.168.122.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.122.2' end='192.168.122.254'/>
    </dhcp>
  </ip>
</network>

Esta definición incluye una red privada de Clase C y un dispositivo de hardware emulado para actuar como enrutador para esta red. También hay un rango de direcciones IP para que el hipervisor las use con una implementación de servidor DHCP que puede asignarse a las máquinas virtuales que usan esta red. Esta configuración de red también utiliza la traducción de direcciones de red (NAT) para reenviar paquetes a otras redes, como la LAN del hipervisor.

Ahora dirigimos nuestra atención a un archivo de definición de máquina virtual Red Hat Enterprise Linux 8. (las secciones de nota especial están en negrita):

$ sudo cat /etc/libvirt/qemu/rhel8.0.xml
<!--
WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE
OVERWRITTEN AND LOST. Changes to this xml configuration should be made using:
  virsh edit rhel8.0
or other application using the libvirt API.
-->

<domain type='kvm'>
  <name>rhel8.0</name>
  <uuid>fadd8c5d-c5e1-410e-b425-30da7598d0f6</uuid>
  <metadata>
    <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
      <libosinfo:os id="http://redhat.com/rhel/8.0"/>
    </libosinfo:libosinfo>
  </metadata>
  <memory unit='KiB'>4194304</memory>
  <currentMemory unit='KiB'>4194304</currentMemory>
  <vcpu placement='static'>2</vcpu>
  <os>
    <type arch='x86_64' machine='pc-q35-3.1'>hvm</type>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <vmport state='off'/>
  </features>
  <cpu mode='host-model' check='partial'>
    <model fallback='allow'/>
  </cpu>
  <clock offset='utc'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='hpet' present='no'/>
  </clock>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</on_crash>
  <pm>
    <suspend-to-mem enabled='no'/>
    <suspend-to-disk enabled='no'/>
  </pm>
  <devices>
    <emulator>/usr/bin/qemu-system-x86_64</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/rhel8'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
    </disk>
    <controller type='usb' index='0' model='qemu-xhci' ports='15'>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/>
    </controller>
    <controller type='sata' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/>
    </controller>
    <controller type='pci' index='0' model='pcie-root'/>
    <controller type='pci' index='1' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='1' port='0x10'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0' multifunction='on'/>
    </controller>
    <controller type='pci' index='2' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='2' port='0x11'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x1'/>
    </controller>
    <controller type='pci' index='3' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='3' port='0x12'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x2'/>
    </controller>
    <controller type='pci' index='4' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='4' port='0x13'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x3'/>
    </controller>
    <controller type='pci' index='5' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='5' port='0x14'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x4'/>
    </controller>
    <controller type='pci' index='6' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='6' port='0x15'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x5'/>
    </controller>
    <controller type='pci' index='7' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='7' port='0x16'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x6'/>
    </controller>
    <controller type='virtio-serial' index='0'>
      <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/>
    </controller>
    <interface type='network'>
      <mac address='52:54:00:50:a7:18'/>
      <source network='default'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
    </interface>
    <serial type='pty'>
      <target type='isa-serial' port='0'>
        <model name='isa-serial'/>
      </target>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
    <channel type='unix'>
      <target type='virtio' name='org.qemu.guest_agent.0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    </channel>
    <channel type='spicevmc'>
      <target type='virtio' name='com.redhat.spice.0'/>
      <address type='virtio-serial' controller='0' bus='0' port='2'/>
    </channel>
    <input type='tablet' bus='usb'>
      <address type='usb' bus='0' port='1'/>
    </input>
    <input type='mouse' bus='ps2'/>
    <input type='keyboard' bus='ps2'/>
    <graphics type='spice' autoport='yes'>
      <listen type='address'/>
      <image compression='off'/>
    </graphics>
    <sound model='ich9'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1b' function='0x0'/>
    </sound>
    <video>
      <model type='virtio' heads='1' primary='yes'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/>
    </video>
    <redirdev bus='usb' type='spicevmc'>
      <address type='usb' bus='0' port='2'/>
    </redirdev>
    <redirdev bus='usb' type='spicevmc'>
      <address type='usb' bus='0' port='3'/>
    </redirdev>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/>
    </memballoon>
    <rng model='virtio'>
      <backend model='random'>/dev/urandom</backend>
      <address type='pci' domain='0x0000' bus='0x06' slot='0x00' function='0x0'/>
    </rng>
  </devices>
</domain>

Este archivo define una serie de configuraciones de hardware que utiliza el sistema invitado (guest), como la cantidad de RAM que le habrá asignado, el número de núcleos de CPU del hipervisor al que tendrá acceso el invitado, el archivo de imagen del disco duro que está asociado (bajo la etiqueta disk), sus capacidades de visualización (a través del protocolo SPICE) y el acceso del invitado a dispositivos USB, así como a la entrada emulada de teclado y mouse.

Ejemplo de almacenamiento en disco de una máquina virtual

La imagen del disco duro de esta máquina virtual reside en /var/lib/libvirt/images/rhel8. Aquí está la imagen de disco en este hipervisor:

$ sudo ls -lh /var/lib/libvirt/images/rhel8
-rw------- 1 root root 5.5G Oct 25 15:57 /var/lib/libvirt/images/rhel8

El tamaño actual de esta imagen de disco ocupa solo 5,5 GB de espacio en el hipervisor. Sin embargo, el sistema operativo dentro de este invitado ve un disco de 23,3 GB de tamaño, como lo demuestra la salida del siguiente comando desde la máquina virtual en ejecución:

$ lsblk
NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
vda           252:0    0 23.3G  0 disk
├─vda1        252:1    0    1G  0 part /boot
└─vda2        252:2    0 22.3G  0 part
  ├─rhel-root 253:0    0   20G  0 lvm  /
  └─rhel-swap 253:1    0  2.3G  0 lvm  [SWAP]

Esto se debe al tipo de aprovisionamiento de disco utilizado para este invitado. Hay varios tipos de imágenes de disco que una máquina virtual puede usar, pero los dos tipos principales son:

COW: Copy-on-write (también conocido como thin-provisioning o sparse images) es un método en el que se crea un archivo de disco con un límite de tamaño superior predefinido. El tamaño de la imagen del disco solo aumenta a medida que se escriben nuevos datos en el disco. Al igual que en el ejemplo anterior, el sistema operativo invitado ve el límite de disco predefinido de 23,3 GB, pero solo ha escrito 5,5 GB de datos en el archivo del disco. El formato de imagen de disco utilizado para la máquina virtual de ejemplo es qcow2, que es un formato de archivo QEMU COW.
RAW: Un tipo de disco raw o full es un archivo que tiene todo su espacio preasignado. Por ejemplo, un archivo de imagen de disco sin formato de 10 GB consume 10 GB de espacio real en el hipervisor. Hay un beneficio de rendimiento para este estilo de disco, ya que todo el espacio en disco necesario ya existe, por lo que el hipervisor subyacente puede simplemente escribir datos en el disco sin el impacto del rendimiento de monitorear la imagen del disco para asegurarse de que aún no ha alcanzado su límite y extender el tamaño del archivo a medida que se escriben nuevos datos.

Existen otras plataformas de administración de virtualización como Red Hat Enterprise Virtualization y oVirt que pueden usar discos físicos para actuar como ubicaciones de almacenamiento de respaldo para el sistema operativo de una máquina virtual. Estos sistemas pueden utilizar la red de área de almacenamiento (SAN) o dispositivos de almacenamiento conectados a la red (NAS) para escribir sus datos, y el hipervisor realiza un seguimiento de qué ubicaciones de almacenamiento pertenecen a qué máquinas virtuales. Estos sistemas de almacenamiento pueden usar tecnologías como la administración de volumen lógico (LVM) para aumentar o reducir el tamaño del almacenamiento en disco de una máquina virtual según sea necesario, y para ayudar en la creación y administración de instantáneas de almacenamiento.

Trabajando con plantillas de máquinas virtuales

Dado que las máquinas virtuales generalmente son solo archivos que se ejecutan en un hipervisor, es fácil crear plantillas que se pueden personalizar para escenarios de implementación particulares. A menudo, una máquina virtual tendrá una instalación básica del sistema operativo y algunos ajustes de configuración de autenticación preconfigurados para facilitar futuros lanzamientos del sistema. Esto reduce la cantidad de tiempo que lleva construir un nuevo sistema al reducir la cantidad de trabajo que a menudo se repite, como la instalación de paquetes base y la configuración regional.

Esta plantilla de máquina virtual podría copiarse luego a un nuevo sistema invitado (guest). En este caso, se cambiaría el nombre del nuevo invitado (guest), se generaría una nueva dirección MAC para su interfaz de red y se podrían realizar otras modificaciones dependiendo de su uso previsto.

El D-Bus Machine ID

Muchas instalaciones de Linux utilizarán un número de identificación de máquina generado en el momento de la instalación, llamado D-Bus machine ID. Sin embargo, si una máquina virtual se clona para ser utilizada como plantilla para otras instalaciones de máquinas virtuales, se necesitaría crear una nueva ID de máquina D-Bus para garantizar que los recursos del sistema del hipervisor se dirijan al sistema invitado (guest) apropiadamente.

El siguiente comando se puede usar para validar que existe una ID de máquina D-Bus para el sistema en ejecución:

$ dbus-uuidgen --ensure

Si no se muestran mensajes de error, existe una ID para el sistema. Para ver la ID actual de la máquina D-Bus, ejecute lo siguiente:

$ dbus-uuidgen --get
17f2e0698e844e31b12ccd3f9aa4d94a

La cadena de texto que se muestra es el número de identificación actual. No hay dos sistemas Linux que se ejecuten en un hipervisor que tengan la misma ID de máquina D-Bus.

La ID de la máquina D-Bus se encuentra en /var/lib/dbus/machine-id y está simbólicamente vinculada a /etc/machine-id. Se desaconseja cambiar este número de identificación en un sistema en ejecución, ya que es probable que ocurran inestabilidades y fallas del sistema. Si dos máquinas virtuales tienen la misma ID de máquina D-Bus, siga el procedimiento a continuación para generar una nueva:

$ sudo rm -f /etc/machine-id
$ sudo dbus-uuidgen --ensure=/etc/machine-id

En el caso de que /var/lib/dbus/machine-id no sea un enlace simbólico a /etc/machine-id, entonces será necesario eliminar /var/lib/dbus/machine-id.

Implementación de máquinas virtuales en la nube

Hay una multitud de proveedores de IaaS (infrastructure as a service) disponibles que ejecutan sistemas de hipervisor y que pueden implementar imágenes virtuales de invitados (guest) para una organización. Prácticamente todos estos proveedores cuentan con herramientas que permiten a un administrador construir, implementar y configurar máquinas virtuales personalizadas basadas en una variedad de distribuciones de Linux. Muchas de estas compañías también tienen sistemas que permiten el despliegue y las migraciones de máquinas virtuales creadas desde la organización de un cliente.

Al evaluar la implementación de un sistema Linux en un entorno IaaS, hay algunos elementos claves que un administrador debe tener en cuenta:

Instancias de computación: Muchos proveedores de la nube cobrarán tasas de uso basadas en “instancias de computación”, o cuánto tiempo de CPU utilizará su infraestructura basada en la nube. Una planificación cuidadosa de cuánto tiempo de procesamiento requerirán realmente las aplicaciones ayudará a mantener manejables los costos de una solución en la nube.

Las instancias de computación a menudo también se refieren a la cantidad de máquinas virtuales que se aprovisionan en un entorno de nube. Una vez más, la mayor cantidad de instancias de sistemas que se ejecutan a la vez también influirá en la cantidad de tiempo total de CPU que se le cobrará a una organización.
Bloque de almacenamiento: Los proveedores de la nube también tienen varios niveles de almacenamiento en bloque disponibles para que una organización los use. Algunas ofertas están destinadas simplemente a ser un almacenamiento de red basado en la web para archivos, y otras ofertas se relacionan con el almacenamiento externo para una máquina virtual aprovisionada en la nube para usar y alojar archivos.

El costo de tales ofertas variará según la cantidad de almacenamiento utilizado y la velocidad del almacenamiento dentro de los centros de datos del proveedor. El acceso al almacenamiento más rápido generalmente costará más y, por el contrario, los datos "en reposo" (como en el almacenamiento de archivos) a menudo son muy económicos.
Redes: Uno de los componentes principales de trabajar con un proveedor de soluciones en la nube es cómo se configurará la red virtual. Muchos proveedores de IaaS tendrán alguna forma de utilidades basadas en la web que pueden utilizarse para el diseño e implementación de diferentes rutas de red, subredes y configuraciones de firewall. Algunos incluso proporcionarán soluciones de DNS para que se puedan asignar FQDN de acceso público (nombres de dominio completos) a sus sistemas orientados a Internet. Incluso hay soluciones “híbridas” disponibles que pueden conectarse de una infraestructura de red existente en las instalaciones de su empresa a una infraestructura basada en la nube a través de una VPN (virtual private network), uniendo las dos infraestructuras.

Acceso seguro a los invitados (guest) en la nube

El método más frecuente para acceder a un invitado virtual remoto en una plataforma en la nube es mediante el uso del software OpenSSH. Un sistema Linux que reside en la nube tendría el servidor OpenSSH ejecutándose, mientras que un administrador usaría un cliente OpenSSH con claves precompartidas para acceso remoto.

Un administrador ejecutaría el siguiente comando

$ ssh-keygen

y seguiría las instrucciones para crear un par de claves SSH públicas y privadas. La clave privada permanece en el sistema local del administrador (almacenado en ~/.ssh/) y la clave pública se copia en el sistema remoto de la nube, exactamente el mismo método que se usaría al trabajar con máquinas en red en una LAN corporativa.

El administrador entonces ejecutaría el siguiente comando:

$ ssh-copy-id -i <public_key> user@cloud_server

Esto copiará la clave SSH pública del par de claves recién generadas en el servidor remoto de la nube. La clave pública se registrará en el archivo ~/.ssh/authorized_keys del servidor de la nube y establecerá los permisos apropiados en el archivo.

Note	Si solo hay un archivo de clave pública en el directorio `~/.ssh/`, entonces se puede omitir el modificador `-i`, ya que el comando `ssh-copy-id` pasará por defecto al archivo de clave pública en el directorio (normalmente el archivo que termina con la extensión `.pub`).

Algunos proveedores de la nube generarán automáticamente un par de claves cuando se aprovisione un nuevo sistema Linux. El administrador deberá descargar la clave privada para el nuevo sistema desde el proveedor de la nube y almacenarla en su sistema local. Tenga en cuenta que los permisos para las claves SSH deben ser 0600 para una clave privada y 0644 para una clave pública.

Preconfigurar sistemas en la nube

Una herramienta útil que simplifica los despliegues de máquinas virtuales basadas en la nube es la utilidad cloud-init. Este comando, junto con los archivos de configuración asociados y la imagen de máquina virtual predefinida, es un método independiente del proveedor para implementar un invitado (guest) Linux en una gran cantidad de proveedores de IaaS. Utilizando archivos de texto plano YAML (YAML Ain’t Markup Language), un administrador puede preconfigurar configuraciones de red, selecciones de paquetes de software, configuración de claves SSH, creaciones de cuentas de usuario, configuraciones regionales, junto con una miríada de otras opciones para construir rápidamente nuevas sistemas.

Durante el arranque inicial de un nuevo sistema, cloud-init leerá la configuración de los archivos de configuración de YAML y los aplicará. Este proceso solo necesita aplicarse a la configuración inicial de un sistema y facilita la implementación de una flota de nuevos sistemas en la plataforma de un proveedor de la nube.

La sintaxis del archivo YAML utilizada con cloud-init se llama cloud-config. Aquí hay un archivo de ejemplo cloud-config:

#cloud-config
timezone: Africa/Dar_es_Salaam
hostname: test-system

# Update the system when it first boots up
apt_update: true
apt_upgrade: true

# Install the Nginx web server
packages:
 - nginx

Tenga en cuenta que en la línea superior no hay espacio entre el símbolo hash (#) y el término cloud-config.

Note	`cloud-init` no es solo para máquinas virtuales. El conjunto de herramientas `cloud-init` también se puede usar para preconfigurar contenedores (como los contenedores LXD Linux) antes de la implementación.

Contenedores

La tecnología de contenedores es similar en algunos aspectos a una máquina virtual, donde se obtiene un entorno aislado para implementar fácilmente una aplicación. Mientras que con una máquina virtual se emula una computadora completa, un contenedor utiliza el software suficiente para ejecutar una aplicación. De esta manera, hay mucho menos gastos generales.

Los contenedores permiten una mayor flexibilidad sobre la de una máquina virtual. Un contenedor de aplicaciones se puede migrar de un host a otro, al igual que una máquina virtual se puede migrar de un hipervisor a otro. Sin embargo, a veces una máquina virtual necesitará apagarse antes de que pueda migrarse, mientras que con un contenedor la aplicación siempre se está ejecutando mientras se migra. Los contenedores también facilitan la implementación de nuevas versiones de aplicaciones en conjunto con una versión existente. A medida que los usuarios cierran sus sesiones con contenedores en ejecución, el software de orquestación de contenedores puede eliminar automáticamente estos contenedores del sistema y reemplazarlos con la nueva versión, lo que reduce el tiempo de inactividad.

Note	Existen numerosas tecnologías de contenedor disponibles para Linux, como Docker, Kubernetes, LXD/LXC, systemd-nspawn, OpenShift y más. La implementación exacta de un paquete de software contenedor está más allá del alcance del examen LPIC-1.

Los contenedores utilizan el mecanismo control groups (mejor conocido como cgroups) dentro del kernel de Linux. El cgroup es una forma de particionar los recursos del sistema, como la memoria, el tiempo del procesador y el ancho de banda del disco y la red para una aplicación individual. Un administrador puede usar cgroups directamente para establecer límites de recursos del sistema en una aplicación, o un grupo de aplicaciones que podrían existir dentro de un solo cgroup. En esencia, esto es lo que hace el software contenedor para el administrador, además de proporcionar herramientas que facilitan la administración y la implementación de cgroups.

Note	Actualmente, el conocimiento de cgroups no es necesario para aprobar el examen LPIC-1. El concepto de cgroup se menciona aquí para que el candidato tenga al menos algunos conocimientos previos de cómo se segrega una aplicación en aras de la utilización de los recursos del sistema.

Ejercicios Guiados

¿Qué extensiones de CPU son necesarias en una plataforma de hardware basada en x86 que ejecutará invitados (guest) totalmente virtualizados?
¿Una instalación de un servidor de misión crítica que requerirá el rendimiento más rápido probablemente usará qué tipo de virtualización?
Dos máquinas virtuales que se han clonado a partir de la misma plantilla y que utilizan D-Bus funcionan de manera irregular. Ambos tienen nombres de host y configuraciones de red separadas. ¿Qué comando se usaría para determinar si cada una de las máquinas virtuales tienen diferentes ID de máquina D-Bus?

Ejercicios Exploratorios

Ejecute el siguiente comando para ver si su sistema ya tiene extensiones de CPU habilitadas para ejecutar una máquina virtual (sus resultados pueden variar según su CPU):

grep --color -E "vmx|svm" /proc/cpuinfo

Dependiendo de la salida, puede tener resaltado vmx (para CPU habilitadas con Intel VT-x) o svm resaltado (para CPU habilitadas con AMD SVM). Si no obtiene resultados, consulte las instrucciones de su BIOS o firmware UEFI sobre cómo habilitar la virtualización para su procesador.
Si su procesador admite virtualizaciones, busque la documentación de su distribución para ejecutar un hipervisor KVM.
- Instale los paquetes necesarios para ejecutar un hipervisor KVM.
- Si está utilizando un entorno de escritorio gráfico, se recomienda instalar también la aplicación virt-manager, que es una interfaz gráfica que se puede utilizar en una instalación de KVM. Esto ayudará en la instalación y gestión de máquinas virtuales.
- Descargue una imagen ISO de la distribución de Linux de su elección y, siguiendo la documentación de su distribución, cree una nueva máquina virtual utilizando esta ISO.

Resumen

En esta lección cubrimos los conceptos básicos de máquinas virtuales y contenedores, y cómo estas tecnologías se pueden usar con Linux.

Describimos brevemente los siguientes comandos:

dbus-uuidgen: Se utiliza para verificar y ver la ID de DBus de un sistema.
ssh-keygen: Se utiliza para generar un par de claves SSH públicas y privadas para usar cuando se accede a sistemas remotos basados en la nube.
ssh-copy-id: Se utiliza para copiar la clave SSH pública de un sistema en un sistema remoto para facilitar la autenticación remota.
cloud-init: Se utiliza para ayudar en la configuración e implementación de máquinas virtuales y contenedores en un entorno de nube.

Respuestas a los ejercicios guiados

¿Qué extensiones de CPU son necesarias en una plataforma de hardware basada en x86 que ejecutará invitados (guest) totalmente virtualizados?

VT-x para Intel CPUs o AMD-V para AMD CPUs
¿Una instalación de un servidor de misión crítica que requerirá el rendimiento más rápido probablemente usará qué tipo de virtualización?

Un sistema operativo que utiliza la paravirtualización, como Xen, ya que el sistema operativo invitado puede hacer un mejor uso de los recursos de hardware disponibles es mediante el uso de controladores de software diseñados para trabajar con el hipervisor.
Dos máquinas virtuales que se han clonado a partir de la misma plantilla y que utilizan D-Bus funcionan de manera irregular. Ambos tienen nombres de host y configuraciones de red separadas. ¿Qué comando se usaría para determinar si cada una de las máquinas virtuales tienen diferentes ID de máquina D-Bus?

dbus-uuidgen --get

Respuestas a ejercicios exploratorios

Ejecute el siguiente comando para ver si su sistema ya tiene extensiones de CPU habilitadas para ejecutar una máquina virtual (sus resultados pueden variar según su CPU): grep --color -E "vmx|svm" /proc/cpuinfo. Dependiendo de la salida, puede tener "vmx" resaltado (para CPU habilitadas con Intel VT-x) o "svm" resaltado (para CPU habilitadas con AMD SVM). Si no obtiene resultados, consulte las instrucciones de su BIOS o firmware UEFI sobre cómo habilitar la virtualización para su procesador.

Los resultados variarán según la CPU que tenga. Aquí hay un ejemplo de salida de una computadora con una CPU Intel con extensiones de virtualización habilitadas en el firmware UEFI:

$ grep --color -E "vmx|svm" /proc/cpuinfo
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d

Si su procesador admite virtualizaciones, busque la documentación de su distribución para ejecutar un hipervisor KVM.
- Instale los paquetes necesarios para ejecutar un hipervisor KVM.
  
  Esto variará dependiendo de su distribución, pero aquí hay algunos puntos de partida:
  
  Ubuntu — https://help.ubuntu.com/lts/serverguide/libvirt.html
  
  Fedora — https://docs.fedoraproject.org/en-US/quick-docs/getting-started-with-virtualization/
  
  Arch Linux — https://wiki.archlinux.org/index.php/KVM
- Si está utilizando un entorno de escritorio gráfico, se recomienda instalar también la aplicación virt-manager, que es una interfaz gráfica que se puede utilizar en una instalación de KVM. Esto ayudará en la instalación y gestión de máquinas virtuales.
  
  Nuevamente, esto variará según la distribución. Un ejemplo usando Ubuntu se ve así:
  $ sudo apt install virt-manager
- Descargue una imagen ISO de la distribución de Linux de su elección y, siguiendo la documentación de su distribución, cree una nueva máquina virtual utilizando esta ISO.
  
  Esta tarea es manejada fácilmente por el paquete virt-manager. Sin embargo, se puede crear una máquina virtual desde la línea de comandos utilizando el comando virt-install. Pruebe ambos métodos para comprender cómo se implementan las máquinas virtuales.