102.6 Lezione 1

Certificazione:

LPIC-1

Versione:

5.0

Argomento:

102 L’Installazione di Linux e la Gestione Pacchetti

Obiettivo:

102.6 Linux come guest virtualizzato

Lezione:

1 di 1

Introduzione

Uno dei grandi punti di forza di Linux è la sua versatilità. Un aspetto di questa versatilità è la capacità di utilizzare Linux come mezzo per ospitare altri sistemi operativi, o singole applicazioni, in un ambiente completamente isolato e sicuro. Questa lezione si concentrerà sui concetti di virtualizzazione e tecnologie container, insieme ad alcuni dettagli tecnici che dovrebbero essere presi in considerazione quando si distribuisce una macchina virtuale su una piattaforma cloud.

Concetti di Virtualizzazione

La virtualizzazione è una tecnologia che consente a una piattaforma software, denominata hypervisor, di eseguire processi che contengono un sistema informatico completamente emulato. L’hypervisor è responsabile della gestione delle risorse dell’hardware fisico che possono essere utilizzate dalle singole macchine virtuali. Queste macchine virtuali sono chiamate guest dell’hypervisor. Una macchina virtuale ha molti aspetti di un computer fisico emulato nel software, come il BIOS di un sistema e i controller del disco rigido. Una macchina virtuale utilizzerà spesso immagini del disco rigido archiviate come singoli file e avrà accesso alla RAM e alla CPU della macchina host tramite l’hypervisor. Quest’ultimo separa l’accesso alle risorse hardware del sistema host tra i vari guest, consentendo l’esecuzione di più sistemi operativi su un singolo sistema host.

Gli hypervisor comunemente usati per Linux sono:

Xen: Xen è un hypervisor di tipo 1 open source, il che significa che non si basa su un sistema operativo sottostante per funzionare. Un hypervisor di questo tipo è noto come hypervisor bare-metal poiché il computer può avviarsi direttamente nell’hypervisor.
KVM: Kernel Virtual Machine è un modulo del kernel Linux per la virtualizzazione. KVM è un hypervisor sia di tipo 1 che di tipo 2 perché, sebbene abbia bisogno di un sistema operativo Linux generico per funzionare, è in grado di funzionare come hypervisor integrandosi perfettamente con un’installazione Linux in esecuzione. Le macchine virtuali erogate tramite KVM usano il demone libvirt e le utility software associate per essere create e gestite.
VirtualBox: Una popolare applicazione desktop che semplifica la creazione e la gestione di macchine virtuali. Oracle VM VirtualBox è un’ambiente multipiattaforma e funziona su Linux, macOS e Microsoft Windows. Poiché VirtualBox richiede l’esecuzione di un sistema operativo sottostante, lo possiamo considerare come un hypervisor di tipo 2.

Alcuni hypervisor consentono il trasferimento dinamico di una macchina virtuale. Il processo di spostamento di una macchina virtuale da un’installazione hypervisor a un’altra si chiama migration e le tecniche coinvolte possono differire tra un hypervisor e l’altro. Alcune migrazioni possono essere eseguite solo quando il sistema guest è stato completamente spento, mentre altre possono essere eseguite mentre il guest è in esecuzione (live migration). Tali tecniche possono essere di aiuto durante le operazioni di manutenzione degli hypervisor, o per la resilienza di sistema quando un hypervisor smette di essere operativo e la VM Guest deve essere spostata su un hypervisor funzionante.

Tipi di Macchine Virtuali

Esistono tre tipi principali di macchine virtuali, le completamente virtualizzate, le paravirtualizzate e le ibride.

Completamente virtualizzate: Tutte le istruzioni che un sistema operativo guest esegue devono essere in grado di farlo all’interno del sistema operativo virtualizzato. La ragione di ciò è che nessun driver software aggiuntivo è installato all’interno del guest per tradurre le istruzioni in hardware simulato o reale. Un guest completamente virtualizzato è quello in cui il guest (o HardwareVM) non è consapevole di essere un’istanza di macchina virtuale in esecuzione. Affinché questo tipo di virtualizzazione avvenga su hardware x86, le estensioni della CPU Intel VT-x o AMD-V devono essere abilitate sul sistema su cui è installato l’hypervisor. Questo può essere fatto da un menu di configurazione del firmware BIOS o UEFI.
Paravirtualizzate: Un guest paravirtualizzato (o PVM) è quello in cui il sistema operativo guest è consapevole che si tratta di un’istanza di macchina virtuale in esecuzione. Questi tipi di guest faranno uso di un kernel modificato e di driver speciali (noti come guest drivers) che aiuteranno il sistema operativo guest a utilizzare le risorse software e hardware dell’hypervisor. Le prestazioni di un guest paravirtualizzato sono spesso migliori di quelle del guest completamente virtualizzato a causa del vantaggio offerto da questi driver software.
Ibride: La paravirtualizzazione e la virtualizzazione completa possono essere combinate per consentire ai sistemi operativi non modificati di ricevere prestazioni di I/O quasi native utilizzando driver paravirtualizzati su sistemi operativi completamente virtualizzati (HVM). I driver paravirtualizzati contengono driver di archiviazione e rete con prestazioni avanzate di I/O.

Le piattaforme di virtualizzazione spesso forniscono driver specifici per i sistemi operativi guest. KVM utilizza i driver del progetto Virtio, mentre Oracle VM VirtualBox utilizza Guest Extensions disponibili da un file immagine CD-ROM ISO scaricabile.

Esempio di una Virtual Machine gestita tramite `libvirt`

Vedremo un esempio di macchina virtuale gestita da libvirt e che utilizza l’hypervisor KVM. Una macchina virtuale è spesso costituita da un gruppo di file, principalmente un file XML che definisce la macchina virtuale (come la sua configurazione hardware, connettività di rete, funzionalità di visualizzazione e altro) e un file immagine del disco rigido che contiene l’installazione del sistema operativo e il relativo software.

Innanzitutto, iniziamo a esaminare un file di configurazione XML di esempio per una macchina virtuale e il suo ambiente di rete:

$ 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 del percorso della directory si riferisce al software su cui si basano le macchine virtuali basate su KVM. Il progetto QEMU fornisce all’hypervisor il software per emulare i dispositivi hardware che la macchina virtuale utilizzerà, come controller del disco, accesso alla CPU dell’host, emulazione della scheda di rete e altro ancora.

Da notare inoltre che esiste una directory denominata networks. Questa directory contiene i file (sempre di tipo XML) che definiscono le configurazioni di rete che possono essere utilizzate dalle macchine virtuali. Questo hypervisor utilizza solo una rete e quindi esiste un solo file di definizione che contiene una configurazione per un segmento di rete virtuale che verrà utilizzato da questi sistemi.

$ 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>

Questa definizione include una rete privata di classe C e un dispositivo hardware emulato per fungere da router per questa rete. Esiste anche un intervallo di indirizzi IP che l’hypervisor, svolgendo il ruolo di server DHCP, può assegnare alle macchine virtuali che utilizzano questa rete. Questa configurazione di rete utilizza anche il network address translation (NAT) per inoltrare i pacchetti ad altre reti, come la LAN dell’hypervisor.

Rivolgiamo ora la nostra attenzione a un file di definizione di una VM Red Hat Enterprise Linux 8. (le sezioni speciali sono in grassetto):

$ 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>

Questo file definisce una serie di impostazioni hardware utilizzate da questo guest, come la quantità di RAM che gli sarà assegnata, il numero di core della CPU dell’hypervisor a cui il guest avrà accesso, il file di immagine del disco rigido che è associato a questo guest (sotto la dicitura disk), le sue capacità di visualizzazione (tramite il protocollo SPICE) e l’accesso a dispositivi USB, nonché gli input di tastiera e mouse emulati.

Esempio di Archiviazione su Disco della Macchina Virtuale

L’immagine del disco rigido di questa macchina virtuale risiede in /var/lib/libvirt/images/rhel8. Ecco di seguito l’immagine del disco su questo hypervisor:

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

La dimensione corrente di questa immagine disco occupa solo 5,5 GB di spazio sull’hypervisor. Tuttavia, il sistema operativo all’interno di questo guest vede un disco di dimensioni 23,3 GB, come evidenziato dall’output del comando seguente dall’interno della macchina virtuale in esecuzione:

$ 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]

Ciò è dovuto al tipo di provisioning del disco utilizzato per questo guest. Esistono più tipi di immagini disco che una macchina virtuale può utilizzare. I due tipi principali sono:

COW: Copy-on-write (noto anche come thin-provisioning o sparse images) è un metodo in cui viene creato un file su disco con un limite di dimensione superiore predefinito. La dimensione dell’immagine del disco aumenta solo quando i nuovi dati vengono scritti sul disco. Proprio come nell’esempio precedente, il sistema operativo guest vede il limite predefinito del disco di 23,3 GB, ma ha scritto solo 5,5 GB di dati nel file del disco reale. Il formato dell’immagine del disco usato per la macchina virtuale di esempio è qcow2 che è un formato di file COW QEMU.
RAW: Un tipo di disco raw o full è un file che ha tutto il suo spazio pre-allocato. Per esempio, un file di immagine del disco raw da 10 GB occupa 10 GB di spazio sul disco effettivo sull’hypervisor. Vi è un vantaggio in termini di prestazioni in questo tipo di disco in quanto esiste già tutto lo spazio su disco necessario, quindi l’hypervisor sottostante può semplicemente scrivere i dati sul disco senza il calo di prestazioni dovuto al monitoraggio dell’immagine del disco e l’estensione della dimensione del file man mano che vengono scritti nuovi dati.

Esistono altre piattaforme di gestione della virtualizzazione come Red Hat Enterprise Virtualization e oVirt che possono utilizzare dischi fisici per fungere da storage di backend per il sistema operativo di una macchina virtuale. Questi sistemi possono utilizzare dispositivi SAN (Storage Area Network) o NAS (Network Attached Storage) per scrivere i loro dati e l’hypervisor tiene traccia di quali posizioni di archiviazione appartengono a quali macchine virtuali. Questi sistemi di archiviazione possono utilizzare tecnologie come la gestione del volume logico (LVM) per aumentare o ridurre le dimensioni dell’archiviazione su disco di una macchina virtuale in base alle esigenze e per facilitare la creazione e la gestione di snapshot.

Lavorare con i Template di Macchine Virtuali

Poiché le macchine virtuali sono in genere solo file in esecuzione su un hypervisor, è facile creare modelli (templates) che possono essere personalizzati per particolari scenari di distribuzione. Spesso una macchina virtuale avrà un’installazione di base del sistema operativo e alcune impostazioni di configurazione dell’autenticazione preconfigurate configurate per facilitare le esecuzioni future del sistema. Ciò riduce la quantità di tempo necessaria per installare un nuovo sistema riducendo la quantità di lavoro che viene spesso ripetuto, come l’installazione dei pacchetti di base e le impostazioni locali.

Questo modello di macchina virtuale potrebbe successivamente essere copiato per un nuovo sistema guest. In questo caso, il nuovo guest avrà un nuovo nome , un nuovo indirizzo MAC per la sua interfaccia di rete e altre modifiche possono essere fatte a seconda dell’uso previsto.

Il D-Bus Machine ID

Molte installazioni Linux utilizzano un numero di identificazione di macchina generatosi al momento dell’installazione, chiamato D-Bus machine ID. Tuttavia, se una macchina virtuale viene clonata per essere utilizzata come modello per altre installazioni di macchine virtuali, è necessario creare un nuovo D-Bus machine ID per garantire che le risorse di sistema dall’hypervisor vengano indirizzate al sistema guest appropriato..

Il seguente comando può essere utilizzato per convalidare l’esistenza di un D-Bus machine ID per il sistema in esecuzione:

$ dbus-uuidgen --ensure

Se non vengono visualizzati messaggi di errore, esiste un ID per il sistema. Per visualizzare il D-Bus machine ID corrente, eseguire quanto segue:

$ dbus-uuidgen --get
17f2e0698e844e31b12ccd3f9aa4d94a

La stringa di testo visualizzata è il numero ID corrente. Nessun sistema Linux in esecuzione su un hypervisor dovrebbe avere lo stesso D-Bus machine ID.

Il D-Bus machine ID si trova in /var/lib/dbus/machine-id ed è simbolicamente collegato a /etc/machine-id. La modifica di questo ID su un sistema in esecuzione è sconsigliata poiché si potrebbe verificate dell’instabilità di sistema e arresti anomali. Se due macchine virtuali hanno lo stesso D-Bus machine ID, seguire la procedura seguente per generarne uno nuovo:

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

Nel caso in cui /var/lib/dbus/machine-id non sia un collegamento simbolico a /etc/machine-id, sarà necessario rimuovere il file /var/lib/dbus/machine-id.

Distribuire Macchine Virtuali in Cloud

Sono disponibili numerosi provider IaaS (infrastructure as a service) che eseguono sistemi hypervisor e possono distribuire immagini guest virtuali per un’organizzazione. Praticamente tutti questi provider dispongono di strumenti che consentono a un amministratore di creare, distribuire e configurare macchine virtuali personalizzate basate su una varietà di distribuzioni Linux. Molte di queste aziende dispongono inoltre di sistemi che consentono l’implementazione e le migrazioni di macchine virtuali costruite all’interno delle infrastrutture dei clienti.

Quando si valuta il rilascio di un sistema Linux in un ambiente IaaS, ci sono alcuni elementi chiave che un amministratore dovrebbe conoscere:

Istanze di calcolo: Molti fornitori di servizi cloud addebiteranno i tassi di utilizzo in base a "istanze di elaborazione" o alla quantità di tempo della CPU che verrà utilizzata dall’infrastruttura in Cloud. Un’attenta pianificazione di quanto tempo di elaborazione richiederanno effettivamente le applicazioni aiuterà a mantenere gestibili i costi di una soluzione Cloud.

Le istanze di calcolo spesso faranno riferimento al numero di macchine virtuali fornite in un ambiente Cloud. Anche in questo caso, il numero maggiore di istanze di sistemi in esecuzione contemporaneamente determinerà anche il tempo complessivo delle CPU che verrà addebitato a un’organizzazione.
Archiviazione: I fornitori Cloud hanno anche vari livelli di storage a blocchi da utilizzare per un’organizzazione. Alcune offerte sono semplicemente intese come archiviazione di rete basata su soluzioni Web-based per i file e altre offerte riguardano l’archiviazione esterna per una macchina virtuale da utilizzare per l’hosting dei file.

Il costo per tali offerte varierà in base alla quantità di memoria utilizzata e alla velocità della memoria all’interno dei data center del provider. L’accesso più veloce all’archiviazione in genere avrà un costo maggiore e, al contrario, i dati “a riposo” (come nell’archiviazione) sono spesso molto economici.
Rete: Uno dei componenti principali del lavorare con un fornitore di soluzioni Cloud è la configurazione relativa alla rete virtuale. Molti provider IaaS disporranno di una qualche forma di utility basata su Web che può essere utilizzata per la progettazione e l’implementazione di differenti rotte di rete, sottoreti e configurazioni firewall. Alcuni forniranno persino soluzioni DNS in modo tale che nomi FQDN (fully qualified domain names) possano essere assegnati ai sistemi esposti su Internet. Esistono anche soluzioni “ibride” in grado di connettere un’infrastruttura di rete locale (on-premise) a un’infrastruttura basata su Cloud tramite una VPN (virtual private network), collegando così le due infrastrutture.

Accesso Sicuro ai Guest nel Cloud

Il metodo più diffuso in uso per accedere a un guest virtuale remoto su una piattaforma cloud è attraverso l’uso del software OpenSSH. Un sistema Linux che risiede nel cloud avrà il server OpenSSH in esecuzione, mentre l’amministratore usà un client OpenSSH con chiavi precondivise per l’accesso remoto.

Un amministratore eseguirà il seguente comando:

$ ssh-keygen

e a seguire le istruzioni per creare una coppia di chiavi SSH pubbliche e private. La chiave privata rimane sul sistema locale dell’amministratore (memorizzata in ~/.ssh/) e la chiave pubblica viene copiata sul sistema cloud remoto, esattamente lo stesso metodo che si dovrebbe utilizzare quando si lavora con macchine in rete su una LAN aziendale.

L’amministratore eseguirà quindi il seguente comando:

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

Questo copierà la chiave SSH pubblica, dalla coppia di chiavi appena generata, sul server cloud remoto. La chiave pubblica verrà registrata nel file ~/.ssh/authorized_keys del server cloud e imposterà le autorizzazioni appropriate sul file.

Note	Se c’è un solo file di chiave pubblica nella directory `~/.ssh/`, allora l’opzione `-i` può essere omessa, poiché il comando `ssh-copy-id` verrà impostato come predefinito sul file della chiave pubblica nella directory (in genere il file che termina con l’estensione `.pub`).

Alcuni provider cloud genereranno automaticamente una coppia di chiavi quando viene effettuato il provisioning di un nuovo sistema Linux. L’amministratore dovrà quindi scaricare la chiave privata per il nuovo sistema dal provider cloud e memorizzarla sul proprio sistema locale. Si noti che le autorizzazioni per le chiavi SSH devono essere 0600 per una chiave privata e 0644 per una chiave pubblica.

Preconfigurazione dei Sistemi Cloud

Uno strumento utile che semplifica l’implementazione di una macchina virtuale in Cloud è l’utilità cloud-init. Questo comando, insieme ai file di configurazione associati e all’immagine della macchina virtuale predefinita, è un metodo indipendente dal fornitore per distribuire un guest Linux su un gran numero di provider IaaS. Utilizzando semplici file di testo YAML (YAML Ain’t Markup Language) un amministratore può preconfigurare le impostazioni di rete, le selezioni dei pacchetti software, la configurazione della chiave SSH, la creazione di account utente, le impostazioni locali, insieme a una miriade di altre opzioni per creare rapidamente nuove sistemi.

Durante l’avvio iniziale di un nuovo sistema, cloud-init leggerà le impostazioni dai file di configurazione YAML e le applicherà. Questo processo deve essere applicato solo alla configurazione iniziale di un sistema e semplifica l’implementazione di flotte di nuovi sistemi sulla piattaforma di un provider cloud.

La sintassi del file YAML usata con cloud-init si chiama cloud-config. Ecco un esempio di file 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

Da notare che nella riga superiore non c’è spazio tra il simbolo hash (#) e il termine cloud-config.

Note	`cloud-init` non è solo per macchine virtuali. La suite di strumenti `cloud-init` può anche essere utilizzata per preconfigurare containers (come quelli LXD di Linux) prima della loro distribuzione.

I Container

La tecnologia dei container è simile in alcuni aspetti a una macchina virtuale, in cui si ottiene un ambiente isolato per distribuire facilmente un’applicazione. Mentre con una macchina virtuale viene emulato un intero computer, un container utilizza il software sufficiente per eseguire un’applicazione. In questo modo, le risorse generali necessarie alla sua esecuzione sono molto basse.

I container consentono una maggiore flessibilità rispetto a quella di una macchina virtuale. Un container di applicazioni può essere migrato da un host a un altro, proprio come una macchina virtuale può essere migrata da un hypervisor a un altro. Tuttavia, a volte una macchina virtuale dovrà essere spenta prima che possa essere migrata, mentre con un container, l’applicazione è sempre in esecuzione mentre viene migrata. I container semplificano inoltre la distribuzione di nuove versioni di applicazioni in tandem con una versione esistente. Man mano che gli utenti chiudono le sessioni con container in esecuzione, questi container possono essere rimossi automaticamente dal sistema dal software di orchestrazione dei container e sostituiti con la nuova versione, riducendo così i tempi di inattività.

Note	Esistono numerose tecnologie container disponibili per Linux, come Docker, Kubernetes, LXD / LXC, systemd-nspawn, OpenShift e altre. L’esatta implementazione di un pacchetto software container va oltre lo scopo dell’esame LPIC-1.

I container fanno uso del meccanismo control groups (meglio noto come cgroups) all’interno del kernel Linux. Il cgroup è un modo per partizionare risorse di sistema come memoria, tempo del processore e larghezza di banda del disco e della rete per una singola applicazione. Un amministratore può utilizzare direttamente i cgroup per impostare i limiti delle risorse di sistema su un’applicazione o un gruppo di applicazioni che potrebbero esistere all’interno di un singolo cgroup. In sostanza, questo è ciò che fa il software container per l’amministratore, oltre a fornire strumenti che facilitano la gestione e la distribuzione di cgroups.

Note	Attualmente, la conoscenza dei cgroups non è necessaria per superare l’esame LPIC-1. Il concetto di cgroup è menzionato qui in modo che il Candidato abbia almeno una conoscenza di base di come un’applicazione è separata per un miglior utilizzo delle risorse di sistema.

Esercizi Guidati

Quali estensioni della CPU sono necessarie su una piattaforma hardware basata su x86 che eseguirà guest completamente virtualizzati?
Un’installazione server mission-critical che richiederà le prestazioni più veloci probabilmente utilizzerà quale tipo di virtualizzazione?
Due macchine virtuali clonate dallo stesso template e che utilizzano D-Bus funzionano in modo irregolare. Entrambi hanno nomi host e impostazioni di configurazione di rete separati. Quale comando verrebbe utilizzato per determinare se ciascuna delle macchine virtuali ha D-Bus Machine ID diversi?

Esercizi Esplorativi

Esegui il comando seguente per vedere se il tuo sistema ha già le estensioni della CPU abilitate per eseguire una macchina virtuale (i risultati possono variare a seconda della CPU):

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

A seconda dell’output, è possibile che sia evidenziato vmx (per CPU con abilitate le estensioni Intel VT-x) o svm (per CPU con abilitate le estensioni AMD SVM). Se non si ottengono risultati, consultare le istruzioni del firmware BIOS o UEFI su come abilitare la virtualizzazione per il proprio processore.
Se il tuo processore supporta la virtualizzazione, cerca la documentazione della tua distribuzione per eseguire un hypervisor KVM.
- Installa i pacchetti necessari per eseguire un hypervisor KVM.
- Se si utilizza un ambiente desktop grafico, si consiglia di installare anche l’applicazione virt-manager che è un front-end grafico che può essere usato su un’installazione KVM. Ciò aiuterà nell’installazione e nella gestione di macchine virtuali.
- Scarica un’immagine ISO della distribuzione Linux di tua scelta e, seguendo la documentazione della tua distribuzione, crea una nuova macchina virtuale usando questa ISO.

Sommario

In questa lezione sono state illustrate le basi concettuali riguardo le macchine virtuali e container e come queste tecnologie possono essere utilizzate con Linux.

Abbiamo brevemente descritto i seguenti comandi:

dbus-uuidgen: Usato per verificare e visualizzare il DBus ID di un sistema.
ssh-keygen: Usato per generare una coppia di chiavi SSH pubbliche e private da usare quando si accede a sistemi remoti basati su cloud.
ssh-copy-id: Usato per copiare la chiave SSH pubblica di un sistema su un sistema remoto per facilitare l’autenticazione remota.
cloud-init: Usato per aiutare nella configurazione e distribuzione di macchine virtuali e container in un ambiente cloud..

Risposte agli Esercizi Guidati

Quali estensioni della CPU sono necessarie su una piattaforma hardware basata su x86 che eseguirà guest completamente virtualizzati?

VT-x per CPU Intel o AMD-V per CPU AMD.
Un’installazione server mission-critical che richiederà le prestazioni più veloci probabilmente utilizzerà quale tipo di virtualizzazione?

Un sistema operativo che utilizza la paravirtualizzazione come Xen, in quanto, il sistema operativo guest può fare un uso migliore delle risorse hardware disponibili anche attraverso l’uso di driver software progettati per funzionare con l’hypervisor.
Due macchine virtuali clonate dallo stesso template e che utilizzano D-Bus funzionano in modo irregolare. Entrambi hanno nomi host e impostazioni di configurazione di rete separati. Quale comando verrebbe utilizzato per determinare se ciascuna delle macchine virtuali ha D-Bus Machine ID diversi?

dbus-uuidgen --get

Risposte agli Esercizi Esplorativi

Esegui il comando seguente per vedere se il tuo sistema ha già le estensioni della CPU abilitate per eseguire una macchina virtuale (i risultati possono variare a seconda della CPU): grep --color -E "vmx|svm" /proc/cpuinfo. A seconda dell’output, è possibile che sia evidenziato vmx (per CPU con abilitate le estensioni Intel VT-x) o svm (per CPU con abilitate le estensioni AMD SVM). Se non si ottengono risultati, consultare le istruzioni del firmware BIOS o UEFI su come abilitare la virtualizzazione per il proprio processore.

I risultati varieranno a seconda della CPU che hai. Ecco un esempio di output da un computer con una CPU Intel con estensioni di virtualizzazione abilitate nel 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

Se il tuo processore supporta la virtualizzazione, cerca la documentazione della tua distribuzione per eseguire un hypervisor KVM.
- Installa i pacchetti necessari per eseguire un hypervisor KVM.
  
  Questo varierà a seconda della tua distribuzione, ma qui ci sono alcuni punti di partenza:
  
  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
- Se si utilizza un ambiente desktop grafico, si consiglia di installare anche l’applicazione virt-manager che è un front-end grafico che può essere usato su un’installazione KVM. Ciò aiuterà nelle installazioni e nella gestione di macchine virtuali.
  
  Ancora una volta, questo varierà in base alla distribuzione. Un esempio con Ubuntu è il seguente:
  $ sudo apt install virt-manager
- Scarica un’immagine ISO della distribuzione Linux di tua scelta e, seguendo la documentazione della tua distribuzione, crea una nuova macchina virtuale usando questa ISO.
  
  Questo compito è facilmente gestibile dal pacchetto virt-manager. Comunque una macchina virtuale può anche essere creata dalla CLI usando il comando virt-install. Prova entrambi i metodi per comprendere come vengono create le macchine virtuali..