Cambiando a virt-manager

Antecedentes

Desde que me metí en el mundo de Linux me he dado cuenta de que existen estos
varios "agujeros de conejo" (como me gusta llamarlo) en los que podría meterme. yo
defina estos "agujeros de conejo" como el período en el que dedica su tiempo a adoptar
cierta tecnología en su flujo de trabajo. La mayoría de estos flujos de trabajo son a veces
muy poco común Por ejemplo, uno de mis primeros "agujeros de conejo" fue cambiar a un
administrador de ventanas de mosaico. Ya no hay un gran porcentaje de personas que usan
Linux en sus escritorios y mucho menos tener una configuración de administrador de ventanas en mosaico. Uno de
los "agujeros de conejo" en los que me he metido recientemente, de ahí el título de este
artículo:está cambiando de VirtualBox a virt-manager. ya habia visto
Ya hay muchos videos y artículos sobre esta cosita de QEMU/KVM. Y asi fue
predecible para mí finalmente retomar esto.

Introducción

En un blog anterior, hemos cubierto las cajas de gnomos. Sin embargo, hay
también otro administrador de máquinas virtuales que es bastante popular llamado
virt-gerente. Si bien es muy fácil de usar, descubrí que gnome-boxes
no nos proporciona un montón de configuraciones en comparación con virt-manager .
Además, virt-manager también proporciona un mejor rendimiento como
en comparación con VirtualBox ya que estamos utilizando KVM. En este artículo deseo
para compartir algunas de mis experiencias y lo que he aprendido de esto
madriguera de conejo.

Sin embargo, antes de entrar en materia, quiero aclarar algunas cosas:

• Hipervisor :Un hipervisor es una pieza de software que nos permite ejecutar y
  administrar múltiples sistemas operativos diferentes en una sola máquina. Tipo 1
  El hipervisor se ejecuta en el hardware directamente mientras que los hipervisores de tipo 2 se ejecutan en
  parte superior de un sistema operativo instalado en el hardware.
• KVM – Este es el módulo kernel de bajo nivel que se encarga de traducir
  las instrucciones de la CPU de los sistemas operativos invitados en algo que el anfitrión
  núcleo puede entender. Esto es básicamente lo que permite que el kernel de Linux actúe
  como hipervisor (tipo 1)[1].
• QEMU – QEMU significa emulador rápido. Emula varios hardware y CPU.
  arquitecturas QEMU puede funciona con KVM pero también se puede usar solo
  [2]. Sin embargo, eso impone varios problemas de rendimiento a medida que se realiza la emulación.
  íntegramente a través del software. Ahora, KVM por sí mismo tampoco puede emular muchos
  hardware. Por lo tanto, la pila QEMU+KVM se usa más comúnmente como hipervisor.
• libvirt – libvirt es una API que se puede usar para administrar máquinas virtuales a través de QEMU.
  Tiene un demonio llamado libvirtd y una utilidad de línea de comandos llamada virsh [3].
  Sin embargo, no he llegado a usar virsh así que esa es otra madriguera de conejo para mí.
• virt-manager – Finalmente, este es el programa GUI para administrar máquinas virtuales. Usa
  libvirt para interactuar con los componentes de nivel inferior de nuestra pila de virtualización.
  Principalmente interactuaremos con esto como usuario.
  

Instalando virt-manager

Normalmente, intentar instalar virt-manager debería extraer automáticamente los componentes de libvirt como
dependencias Sin embargo, qemu es una dependencia opcional, por lo que debemos especificarla explícitamente.
En Arch Linux, solo necesitaba estos dos paquetes:

Asegúrese de verificar que los paquetes requeridos se muestran en la captura de pantalla anterior
se están introduciendo durante la instalación en su sistema.

Uso de virt-manager

virt-manager es un programa GUI. Como tal, su interfaz de usuario no debería requerir mucha explicación.

Una cosa a tener en cuenta es que debe tener libvirtd servicio ejecutándose para usar virt-manager.

# systemctl start libvirtd

En una pequeña nota, iniciando libvirt también inicia algunos otros servicios, así que ejecuto lo siguiente
comando cuando termine de usar mis máquinas virtuales:

# systemctl stop "libvirt*" "virt*"

Discos virtuales

virt-manager usa el qcow2 formato de almacenamiento para sus discos virtuales. Desde esto
artículo trata sobre la migración a virt-manager, probablemente tengamos algunos
máquinas con sus discos ocupados. Afortunadamente, tenemos el qemu-img utilidad.

Por ejemplo, para convertir una imagen de vdi formato a qcow2 :

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

También se admiten otros formatos que se pueden ver invocando:

qemu-img --help

Las imágenes de VirtualBox también vienen en ova formato. Y no encontrarás ese formato
enumerados en la salida de ayuda del comando anterior.
Sin embargo, al inspeccionar un ova archivo:

Evidentemente, es solo un archivo tar, que se puede extraer fácilmente usando tar :

Ahí tenemos nuestro vmdk disco virtual que se puede convertir fácilmente a qcow2 .

SSH en máquinas virtuales

Cada vez que creaba una máquina virtual en VirtualBox, la configuraba para tener un puente
adaptador. De esa manera, la máquina virtual también estaría en mi LAN doméstica y podría ingresar a ella mediante SSH como cualquier otra.
otra maquina Sin embargo, de forma predeterminada, las máquinas virtuales en virt-manager se conectarán al
red virtual (NAT). Las IPs serán asignadas internamente por el hipervisor que su
el enrutador doméstico no sabrá nada. Así que cuando intentas ssh en la VM usando esa IP,
la puerta de enlace no tendrá idea de cuál es esa IP y, por lo tanto, no funcionará.

La forma en que pude hacer que el enrutador también asignara una IP a mi máquina virtual
es creando primero un puente de red y luego editando la configuración de red del
VM como se muestra en la captura de pantalla para ser de la fuente Bridge y cuando la VM se inicia
obtiene una IP a la que pueden acceder otros dispositivos en la LAN.

La configuración de un puente de red está bien documentada en sitios como Arch Wiki [4].
Uso Network Manager y el procedimiento fue tan simple como ingresar algunos
comandos El nombre del puente es br0 y la interfaz asignada como esclava a ese
el puente es 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

De esta manera, puedo copiar y pegar fácilmente cosas hacia y desde la VM y tampoco tengo
para escapar constantemente del teclado/mouse cuando uso la VM y mi host tanto en
al mismo tiempo.

Después de resolver todo eso, finalmente pude comenzar a usar virt-manager como mi principal
administrador de máquinas virtuales. Eso es todo por ahora, espero que este artículo le haya resultado útil.

Referencias

1. Máquina virtual basada en kernel
2. KVM frente a QEMU
3. Preguntas frecuentes de Libvirt
4. Puente de red | ArchWiki