Passaggio a virt-manager

Sfondo

Da quando sono entrato nel mondo di Linux, mi sono reso conto che esistono questi
vari “buchi di coniglio” (come mi piace chiamarli) in cui potrei infilarmi. io
definisci queste "buche di coniglio" come il periodo in cui passi il tuo tempo ad adottare
una certa tecnologia nel tuo flusso di lavoro. La maggior parte di questi flussi di lavoro a volte lo sono
molto raro. Ad esempio uno dei miei primi "buchi di coniglio" è stato il passaggio a a
gestore di finestre di piastrellatura. Non c'è già una grande percentuale di persone che usano
Linux sui loro desktop per non parlare di avere una configurazione di gestione delle finestre di piastrellatura. Uno di
le "buche dei conigli" in cui sono entrato di recente - da qui il titolo di questo
articolo – sta passando da VirtualBox a virt-manager. avevo già visto
già molti video e articoli su questa cosa QEMU/KVM. Così è stato
prevedibile per me che alla fine lo raccolga.

Introduzione

In un blog precedente, abbiamo trattato le scatole degli gnomi. Tuttavia, c'è
anche un altro gestore di macchine virtuali che è abbastanza popolare chiamato
virt-manager. Sebbene sia molto facile da usare, ho trovato che gnome-boxes
non ci fornisce un sacco di configurazioni rispetto a virt-manager .
Inoltre, virt-manager fornisce anche prestazioni migliori come
rispetto a VirtualBox poiché utilizziamo KVM. In questo articolo, vorrei
per condividere alcune delle mie esperienze e ciò che ho imparato da questo
tana del coniglio.

Prima di entrare nel merito, però, voglio chiarire alcune cose:

• Ipervisore :Un hypervisor è un software che ci consente di eseguire e
  gestire più sistemi operativi diversi su una singola macchina. Tipo 1
  l'hypervisor viene eseguito direttamente sull'hardware mentre gli hypervisor di tipo 2 sono in esecuzione
  superiore di un sistema operativo installato sull'hardware.
• KVM – Questo è il modulo del kernel di basso livello responsabile della traduzione
  le istruzioni della CPU dei sistemi operativi guest in qualcosa che l'host
  il kernel può capire. Questo è fondamentalmente ciò che consente al kernel Linux di agire
  come hypervisor (tipo 1)[1].
• QEMU – QEMU sta per Quick Emulator. Emula vari hardware e CPU
  architetture. QEMU può funziona con KVM ma può anche essere utilizzato da solo
  [2]. Tuttavia, ciò impone vari problemi di prestazioni durante l'emulazione
  interamente tramite software. Ora, anche KVM da solo non può emulare molto
  hardware. Pertanto, lo stack QEMU+KVM è più comunemente usato come hypervisor.
• libvirt – libvirt è un'API che può essere utilizzata per gestire macchine virtuali tramite QEMU.
  Ha un demone chiamatolibvirtd e un'utilità da riga di comando chiamata virsh [3].
  Tuttavia, non ho iniziato a usare virsh quindi questa è un'altra tana del coniglio per me.
• gestore virtuale – Infine, questo è il programma GUI per la gestione delle macchine virtuali. Utilizza
  libvirt per interagire con i componenti di livello inferiore del nostro stack di virtualizzazione.
  Interagiremo principalmente con questo come utente.
  

Installazione di virt-manager

Normalmente, il tentativo di installare virt-manager dovrebbe caricare automaticamente i componenti di libvirt come
dipendenze. Tuttavia, qemu è una dipendenza facoltativa, quindi è necessario specificarla in modo esplicito.
Su Arch Linux, avevo bisogno solo di questi due pacchetti:

Assicurati di controllare che i pacchetti richiesti siano mostrati nella schermata sopra
vengono inseriti durante l'installazione sul sistema.

Utilizzo di virt-manager

virt-manager è un programma GUI. In quanto tale, la sua interfaccia utente non dovrebbe richiedere molte spiegazioni.

Una cosa da notare è che devi avere libvirtd servizio in esecuzione per utilizzare virt-manager.

# systemctl start libvirtd

Con una piccola nota, avviando libvirt avvia anche alcuni altri servizi, quindi eseguo quanto segue
comando quando ho finito di usare le mie VM:

# systemctl stop "libvirt*" "virt*"

Dischi virtuali

virt-manager usa il qcow2 formato di archiviazione per i suoi dischi virtuali. Da questo
l'articolo riguarda la migrazione a virt-manager, probabilmente ne abbiamo alcuni virtuali
macchine con i loro dischi popolati. Fortunatamente, abbiamo il qemu-img utilità.

Ad esempio, per convertire un'immagine da vdi formattare in qcow2 :

qemu-img convert -O qcow2 -f vdi <image.vdi> <output_file.qcow2>

Sono supportati anche altri formati che possono essere visualizzati invocando:

qemu-img --help

Le immagini di VirtualBox sono disponibili anche in ova formato. E non troverai quel formato
elencato nell'output della guida del comando precedente.
Tuttavia, durante l'ispezione di un ova file:

Evidentemente è solo un archivio tar, che può essere facilmente estratto usando tar :

Ecco il nostro vmdk disco virtuale che può essere facilmente convertito in qcow2 .

SSH nelle macchine virtuali

Ogni volta che creavo una macchina virtuale in VirtualBox, la configurerei per avere un bridge
adattatore. In questo modo, la VM sarebbe anche sulla mia LAN domestica e potrei accedervi tramite SSH come qualsiasi altra
altra macchina. Tuttavia, per impostazione predefinita, le VM in virt-manager saranno connesse a
rete virtuale (NAT). Gli IP verranno assegnati internamente dall'hypervisor che il tuo
il router di casa non lo saprà. Quindi, quando provi a ssh nella VM usando quell'IP,
il gateway non avrà idea di quale sia quell'IP e quindi non funziona.

Il modo in cui sono riuscito a convincere il router ad assegnare un IP anche alla mia macchina virtuale
consiste nel creare prima un bridge di rete e quindi modificare la configurazione di rete del
VM come mostrato nello screenshot per essere dell'origine Bridge e quando la VM si avvia
ottiene un IP accessibile ad altri dispositivi sulla LAN.

La configurazione di un bridge di rete è ben documentata su siti come Arch Wiki [4].
Uso Network Manager e la procedura è stata semplice come inserirne alcuni
comandi. Il nome del ponte è br0 e l'interfaccia assegnata come slave a quello
bridge è eth0 .

nmcli connection add type bridge ifname br0 stp no
nmcli connection add type bridge-slave ifname eth0 master br0
nmcli connection down eth0
nmcli connection up bridge-br0

In questo modo posso facilmente copiare e incollare cose da e verso la VM e non ho
per sfuggire costantemente alla tastiera/mouse quando si utilizza la macchina virtuale e il mio host entrambi su
allo stesso tempo.

Dopo aver capito tutto questo, sono finalmente riuscito a usare virt-manager come principale
gestore di macchine virtuali. Quindi per ora è tutto, spero che tu abbia trovato utile questo articolo.

Riferimenti

1. Macchina virtuale basata su kernel
2. KVM vs QEMU
3. Domande frequenti su Libvirt
4. Ponte di rete | Arch Wiki