https://manuais.iessanclemente.net/index.php?title=Virtualizaci%C3%B3n_en_GNU/Linux_con_KVM&feed=atom&action=historyVirtualización en GNU/Linux con KVM - Historial de revisiones2024-03-29T08:12:47ZHistorial de revisiones de esta página en el wikiMediaWiki 1.36.2https://manuais.iessanclemente.net/index.php?title=Virtualizaci%C3%B3n_en_GNU/Linux_con_KVM&diff=64193&oldid=prevJavierfp: /* Eliminación de una MV */2018-04-02T14:25:03Z<p><span dir="auto"><span class="autocomment">Eliminación de una MV</span></span></p>
<p><b>Página nueva</b></p><div>== Introducción ==<br />
<br />
'''KVM''' (Kernel-based Virtual Machine) es una tecnología de hipervisor integrada en el kernel de Linux. Con esta tecnología podemos crear y gestionar máquinas virtuales bajo el paradigma de la “full virtualization”.<br />
Aunque hablemos de KVM realmente deberíamos hablar de Qemu/KVM. '''Qemu''' es una plataforma de simulación de hardware virtual, funcionando de modo que, intercepta las instrucciones para la CPU virtual y utiliza el sistema operativo anfitrión para ejecutar esas instrucciones en la CPU real. Qemu es el encargado de proporcionar recursos, del nodo o host, a los domains, MVs o guests. KVM cumple una función similar, sin embargo ambos operan juntos por una cuestión de eficiencia y compatibilidad. Qemu es compatible con muchas arquitecturas y permite acceder a múltiple hardware; mientras que KVM ofrece el rendimiento necesario para ello, mejorando las características de velocidad del primero.<br />
<br />
Más específicamente '''KVM es el módulo del kernel''' de Linux que permite acelerar la ejecución de una máquina virtual. Sin esta aceleración la ejecución de las instrucciones de la MV en la CPU virtual tienen que ser traducidas por el hipervisor a la CPU física. KVM permite utilizar las características de algunas CPU modernas de mapear partes de la CPU físicas directamente a la máquina virtual. De este modo las instrucciones ejecutadas por la CPU virtual pasan sin la sobrecarga de traducción del hipervisor a la CPU física. Esta característica tiene como consecuencia que, para poder obtener todo el rendimiento de aceleración de KVM, '''la CPU virtual y la CPU física deben de tener la misma arquitectura'''. De no ser el caso, solo podríamos utilizar Qemu sin KVM, con la consiguiente pérdida de rendimiento asociada. La combinación de Qemu y KVM permite implementar un hipervisor de tipo 1, debido a las características de aceleración y mapeo directo de las instrucciones virtuales/físicas que este último proporciona.<br />
<br />
También conviene hablar de '''libvirt'''. Se trata de un API o librería de acceso a características de virtualización compatible con múltiples tecnologías de hipervisor, incluyendo por supuesto Qemu/KVM. A través de esta librería, y de su interfaz cliente virsh, podremos gestionar los recursos virtualizados y la creación y gestión de MVs.<br />
Podemos interpretar '''Qemu/KVM''' como una tecnología de base para implementar un '''hipervisor de tipo 1''' sobre el kernel de Linux. De este modo dispondremos de características que proporcionarán un rendimiento elevado, próximo al del entorno de ejecución “bare metal”.<br />
<br />
Con Qemu/KVM vamos a poder ejecutar cualquier tipo de sistema operativo, Windows, Linux, compatible con la arquitectura de la CPU.<br />
<br />
Para ejecutar Qemu/KVM necesitamos que '''el procesador soporte extensiones de virtualización''' en su juego de instrucciones, podemos comprobarlo ejecutando el comando<br />
<br />
<code>egrep 'svm|vmx' /proc/cpuinfo --color</code><br />
<br />
El resultado debería mostrar varias líneas con el texto buscado resaltado en color. Si este es el caso entonces nuestro procesador soporta KVM. Los procesadores Intel mostrarán el texto '''vmx''' resaltado y los procesadores AMD mostrarán el texto '''svm''' resaltado.<br />
<br />
'''NOTA''': Es importante comprobar que en la BIOS están activados las instrucciones virtuales VT/x, de lo contrario KVM no funcionará<br />
<br />
También deberíamos de comprobar si los módulos correspondientes están cargados<br />
<br />
<code>lsmod | grep kvm</code><br />
<br />
Debería mostrar una salida no vacía<br />
<br />
Por último el comando<br />
<br />
<code>virsh capabilities</code><br />
<br />
Mostraría un listado de las capacidades de virtualización de nuestro sistema<br />
<br />
== Plataformas ==<br />
<br />
Usaremos como base para la realización de las pruebas y los comandos explicados<br />
<br />
* '''Debian 9 (Stretch) versión desktop''': Podremos utilizar todos los comandos por consola, por tanto no es estrictamente necesario que sea una versión desktop, sin embargo, si queremos utilizar la interfaz gráfica de gestión virt-manager, sí sería necesario este requisito<br />
<br />
== Ejecución KVM nested ==<br />
<br />
Con esta característica se permite la ejecución de instrucciones KVM dentro de máquinas virtuales KVM, lo cual abre un abanico de posibilidades interesantes a la ejecución de máquinas virtuales dentro de máquinas virtuales, pudiendo resultar útil para pruebas y formación.<br />
Un ejemplo típico de lo anterior sería la posibilidad de ejecutar la plataforma Proxmox en una máquina virtual, de modo que podremos crear máquinas virtuales con KVM desde esa plataforma, no siendo necesario hacer una instalación “bare metal” de Proxmox.<br />
<br />
Veamos el procedimiento<br />
<br />
=== Activar KVM nested en el anfitrión ===<br />
<br />
Comprobamos la salida del comando<br />
<br />
<code>cat /sys/module/kvm_intel/parameters/nested</code><br />
<br />
Si es “N”, entonces activamos el soporte para que el procesador pueda ejecutar las instrucciones necesarias para KVM en la máquina virtual KVM. Ejecutamos como root:<br />
<br />
<code>echo 'options kvm_intel nested=1' >> /etc/modprobe.d/qemu-system-x86.conf</code><br />
<br />
Reiniciamos la máquina<br />
<br />
Para poder utilizar en una máquina virtual KVM la anterior característica debemos elegir la opción Copy host CPU Configuration a la hora de definir la CPU virtual de la máquina.<br />
<br />
== Virt-manager ==<br />
<br />
Virt-manager es una herramienta gráfica de gestión de máquinas virtuales. Es compatible con tecnología de tipo full virtualization KVM y Xen, pero también permite la gestión de containers basados en tecnología LXC y OpenVZ.<br />
<br />
El siguiente comando instala virt-manager<br />
<br />
<pre><br />
apt update<br />
apt install virt-manager<br />
</pre><br />
<br />
Tras su instalación podemos lanzarla, como root<br />
<br />
<code>virt-manager &</code><br />
<br />
'''NOTA'''<br />
<br />
Si queremos ejecutar virt-manager con un usuario no root debemos incluir al usuario en los grupos: libvirt, libvirt-qemu y kvm. Podemos usar el siguiente comando<br />
<br />
<pre>usermod -a -G libvirt,libvirt-qemu,kvm usuario</pre><br />
<br />
Muchos de los procedimientos ilustrados a continuación podrán ser realizados desde esta herramienta en modo gráfico<br />
<br />
== Creación de MV ==<br />
<br />
Existen varios modos para crear máquinas virtuales KVM, desde hacerlo con la interfaz gráfica proporcionada por la herramienta virt-manager, hasta, como veremos a continuación, utilizar algún comando específico<br />
<br />
=== Creación de MV con virt-install ===<br />
<br />
<pre>virt-install --name guest1-deb9 --memory 2048 --vcpus 2 --disk size=20 \ <br />
--cdrom /path/to/debian9.iso --network network=default --os-variant debian9</pre><br />
<br />
Las opciones son autoexplicativas<br />
* name: nombre de la máquina virtual<br />
* memory: cantidad de memoria asignada<br />
* vcpus: número de CPUs virtuales<br />
* disk: establece opciones de disco duro virtual<br />
* cdrom: indica los medios de instalación<br />
* network: indica a que red virtual se va a conectar la máquina. Por defecto usará la network default de tipo NAT. También se puede indicar que se cree el guest sin red, indicando --network none<br />
* os-variant: identifica el tipo de sistema operativo de la MV<br />
<br />
Existen otras muchas opciones y posibilidades a la hora de crear una máquina virtual con el comando virt-install. Desde importación de otra maquina, instalación a través de la red, uso de PXE, instalación desatendida, etc.<br />
<br />
=== Creación de MV a partir de archivo xml existente ===<br />
<br />
A veces nos interesa crear MV similares, o con características muy parecidas, las cuales pueden ser tomadas a partir de una MV ya existente. De este modo, duplicamos el xml original, hacemos las modificiones pertinentes en el nuevo archivo y ya podemos crear una nueva MV a partir de él. Veamos como hacerlo.<br />
En primer lugar, una aclaración. Cada MV en KVM tiene asociado un número único, UUID, de tipo hexadecimal. Este número debe de ser generado para poder ser utilizado en nuevas MV. Para ello utilizamos la herramienta uuid, sino la tenemos instalada procedemos a su instalación con<br />
<br />
<code>apt install uuid</code><br />
<br />
Tras lo cual podremos generar uuid nuevos con el comando<br />
<br />
<code>uuid</code><br />
<br />
Ahora vamos a volcar el contenido del archivo de configuración xml de alguna de las MV existentes en un nuevo archivo que será modificado apropiadamente, para luego servir como base para la creación de una nueva MV. Usaremos la herramienta virsh dumpxl<br />
<br />
<code>virsh dumpxml W10-CLIENTE > W10-CLIENTE-2.xml</code><br />
<br />
Ahora podremos editar el archivo W10-CLIENTE-2.xml con algún editor de texto. Es importante modificar al menos los 3 primeros campos del archivo<br />
<br />
<pre><name>W10-CLIENTE-2</name><br />
<uuid>d3212b52-bff8-11e7-84d9-63cfc2c59a3b</uuid><br />
<title>W10-CLIENTE-2</title></pre><br />
<br />
y también el campo, dentro de la sección disk, el cual hace referencia al volumen asociado<br />
<br />
<pre><br />
<source file='/var/lib/libvirt/images/win10_2.qcow2'/><br />
</pre><br />
<br />
El valor uuid del campo <uuid> deberá ser generado previamente con la herramienta uuid y copiado en ese campo.<br />
<br />
NOTA: Veremos más adelante como crear volúmenes nuevos a partir de otros<br />
<br />
Una vez modificado los elementos del archivo necesarios creamos la nueva MV<br />
<br />
<code>virsh create W10-CLIENTE-2.xml</code><br />
<br />
El comando anterior creará la MV a partir del archivo modificado<br />
<br />
== virsh ==<br />
<br />
virsh es una potente herramienta de línea de comandos que nos permite gestionar múltiples aspectos de la gestión de máquinas virtuales KVM.<br />
Dentro de la terminología de KVM hacemos referencia al anfitrión o host mediante el término node (nodo).<br />
Para la gestión con virsh se utiliza ampliamente el concepto de domain (dominio), un domain no es más que una máquina virtual. Veamos un ejemplo<br />
<br />
<code>virsh start guest1-win10</code><br />
<br />
El comando anterior inicia el domain (dominio o máquina virtual guest1-win10)<br />
Existen multitud de comandos virsh, los cuales pueden listarse con la opción --help<br />
<br />
<code>virsh --help</code><br />
<br />
Otra opción es entrar en el modo consola de virsh, desde donde pueden invocarse todos los comandos con posibilidad de autocomplección. Para entrar en la consola virsh:<br />
<br />
<code>virsh</code><br />
<br />
Con virsh podemos gestionar:<br />
<br />
* domains<br />
* host e hypervisor<br />
* interfaces<br />
* redes<br />
* dispositivos<br />
* almacenamiento (pools y volúmenes)<br />
* snapshots<br />
* secretos (passwords)<br />
<br />
== Comandos virsh básicos de gestión de MV ==<br />
<br />
=== Listado de MV ===<br />
<br />
<code>virsh list --all</code><br />
<br />
Mostrará todas las MV, estén activas o no, sino se incluye la opción --all entonces solo mostrará las iniciadas<br />
<br />
=== Ver el estado de una MV ===<br />
<br />
Como se ha mencionado anteriormente el concepto domain hace referencia a las MV. Para ver el estado de un domain ejecutamos el comando dominfo de virsh<br />
<br />
<code>virsh dominfo guest01-win10</code><br />
<br />
=== Arranque y parada de MV ===<br />
<br />
<code>virsh start guest01-w10</code><br />
<br />
Arrancaría el domain, MV, de nombre guest01-w10<br />
<br />
<code>virsh shutdown guest01-w10</code><br />
<br />
Detendría, de forma ordenada, el domain indicado<br />
<br />
Para ejecutar un apagado forzado<br />
<br />
<code>virsh destroy guest01-win10</code><br />
<br />
Para ver más comandos en relación a la gestión de domains con virsh<br />
<br />
<code>virsh help domain</code><br />
<br />
=== Algo de información sobre los dispositivos virtuales ===<br />
<br />
Existen múltiples comandos virsh para esto, veamos algunos ejemplos<br />
<br />
<code>virsh domiflist guest01-w10</code><br />
<br />
el comando anterior mostraría las interfaces de red usadas por el domain<br />
<br />
<code>virsh domblklist guest01-win10</code><br />
<br />
mostraría los dispositivos de bloques asociados al domain<br />
<br />
<code>virsh domblkinfo guest01-win10 hdb</code><br />
<br />
muestra la información del dispositivo hdb asociado al domain guest01-w10<br />
<br />
NOTA: La denominación de un dispositivo depende del tipo de interfaz de conexión, por ejemplo los volúmenes conectados a través del emulador IDE tienen nombres de tipo hdX. Los volúmenes conectados por SATA tienen nombres tipos sdX<br />
<br />
Para ver más información relativa a monitorización de un domain podemos ejecutar<br />
<code>virsh help monitor</code><br />
<br />
=== Editar la configuración de una MV ===<br />
<br />
La definición de los domains KVM se realiza mediante archivos XML en donde se declara los recursos de hardware virtual, en este caso simulados mediante qemu (por ese motivo se habla por lo general de virtualización KVM/qemu), usados por la MV.<br />
<br />
Para poder editar el archivo correspondiente usamos también el comando virsh<br />
<br />
<code>virsh edit guest01-w10</code><br />
<br />
Abriría, con nuestro editor de texto favorito, el archivo de configuración correspondiente sobre el que podremos realizar los cambios oportunos. Una vez realizados los cambios podemos reiniciar la MV con<br />
<br />
<code>virsh reboot guest01-w10</code><br />
<br />
=== Establecer autoarranque de MV ===<br />
<br />
Es posible configurar un domain (MV) para que se inicie cuando arranque el sistema. Esto resulta muy útil en entornos de producción cuando se inicia un servidor. Para ello es suficiente con ejecutar el comando<br />
<br />
<code>virsh autostart guest01-w10</code><br />
<br />
Al reiniciar la máquina veremos como inicia también el domain indicado. Para deshabilitarlo<br />
<br />
<code>virsh autostart --disable guest01-w10</code><br />
<br />
=== Eliminación de una MV ===<br />
<br />
En el lenguaje de virsh una máquina virtual es un domain. Para eliminar un domain podemos utilizar el comando<br />
<br />
<code>virsh undefine guest01-win7</code><br />
<br />
Este comando elimina el domain guest01-win7<br />
<br />
Sin embargo, antes de eliminar la MV es recomendable eliminar el disco virtual, para ello usaremos el comando<br />
<br />
<code>virsh vol-delete /var/lib/libvirt/images/guest01-w7.qcow2 --pool default</code><br />
<br />
== Acceso Remoto a MV ==<br />
<br />
Podemos acceder a las MV a través de varios medios y protocolos<br />
<br />
=== Acceso en modo gráfico con VNC ===<br />
<br />
Para poder acceder a través del protocolo VNC a una MV podemos, o bien hacerlo desde virt-manager, en las propiedades de la MV, Monitor VNC, ahí podremos configurar el puerto y las interfaces de acceso al servidor, o bien, editando el archivo de configuración xml de la MV<br />
<br />
<code>virsh edit guest01-win10</code><br />
<br />
Buscamos las líneas del elemento graphics y definimos sus parámetros, como por ejemplo<br />
<br />
<pre><br />
<graphics type='vnc' port='5900' autoport='no' listen='0.0.0.0' keymap='es'><br />
<listen type='address' address='0.0.0.0'/><br />
</graphics><br />
</pre><br />
<br />
En este caso podremos acceder desde cualquier interfaz de red, incluso desde la IP del anfitrión, a través del puerto 5900/tcp, mediante el protocolo VNC. El puerto puede modificarse e incluso ser asignado de forma automática, para poder acceder a distintas MV utilizando puertos diferentes. Podemos restringir el acceso a ciertas interfaces mediante el uso de la directiva listen anterior.<br />
Cuando esté habilitado el acceso mediante VNC en el mismo puerto 5900, podemos obtener el número de pantalla a partir del comando vncdisplay de virsh<br />
<br />
<code>virsh vncdisplay guest01-win10</code><br />
<br />
Mostraría el número de pantalla: :0, :1, etc. que deberá incorporarse después de la dirección o hostname del servidor VNC en la URL de acceso VNC<br />
<br />
=== Acceso en modo gráfico con Spice ===<br />
<br />
Spice es un protocolo de acceso remotoen modo gráfico a las MV, consta de 3 elementos, un servidor Spice, corriendo en el hipervisor, un agente Spice, corriendo en cada domain o MV y un cliente Spice, el programa que usaremos para acceder en remoto.<br />
<br />
Al igual que con VNC puede configurarse el modo de acceso desde virt-manager, en el apartado Monitor Spice en el que puede configurarse el acceso mediante Spice, o bien editando el archivo de configuración xml del domain, veamos un ejemplo<br />
<br />
<code>virsh edit guest01-win10</code><br />
<br />
Buscamos de nuevo el elemento graphics y definimos una configuración como la siguiente<br />
<br />
<pre><br />
<graphics type='spice' port='5900' autoport='no' listen='0.0.0.0' keymap='es'><br />
<listen type='address' address='0.0.0.0'/><br />
</graphics><br />
</pre><br />
<br />
Este caso es análogo al anterior, con la salvedad de que ahora accedemos a través del protocolo Spice<br />
<br />
=== Acceso en modo consola ===<br />
<br />
Una opción utilizada para acceder a sistemas GNU/Linux en modo consola<br />
<br />
<code>virsh console guest01-debian1</code><br />
<br />
Para poder acceder de este modo a una máquina GNU/Linux tenemos que añadir la consola a través de puerto serie en las opciones de grub. Para ello editamos el archivo /etc/default/grub y añadimos a la línea GRUB_CMDLINE_LINUX el texto console=ttyS0, de modo que la línea quedará<br />
<br />
<pre>GRUB_CMDLINE_LINUX=”console ttyS0”</pre><br />
<br />
Ahora actualizamos grub<br />
<br />
<code>update-grub</code><br />
<br />
Y reiniciamos<br />
<br />
<code>reboot</code><br />
<br />
Tras el reinicio podemos utilizar el comando anterior para acceder por consola a la MV<br />
<br />
<code>virsh console guest01-debian1</code><br />
<br />
== Clonación de MV ==<br />
<br />
Una funcionalidad interesante es poder clonar MV existentes, de modo que obtengamos una MV igual a la original. Para ello usamos la herramienta virt-clone<br />
<br />
<code>virt-clone --original=guest01-win10 --name=guest01-win10-CLONE --file=/var/lib/libvirt/images/guest01-win10-CLONE.qcow2</code><br />
<br />
El comando anterior clona el domain (MV) de nombre guest01-win10 en un nuevo domain de nombre guest01-win10-clone, además especifica que la ubicación de su volumen de almacenamiento tendrá la ruta indicada.<br />
<br />
== Gestión de volúmenes ==<br />
<br />
=== Listado de volúmenes ===<br />
<br />
<code>virsh vol-list --details default</code><br />
<br />
El comando anterior listará los volúmenes disponibles en el pool default. Un pool es una ubicación de almacenamiento de volúmenes. Es necesario indicar el pool para que el comando anterior funcione. Por defecto el volumen default, predefinido, está asociado al directorio /var/lib/libvirt/images. La opción --details muestra información detallada de los volúmenes. Mostraría una salida del tipo<br />
<br />
<pre><br />
Name Path Type Capacity Allocation<br />
w10_cliente.qcow2 /var/lib/libvirt/images/w10_cliente.qcow2 file 20,00 GiB 234,95 MiB<br />
w2016.qcow2 /var/lib/libvirt/images/w2016.qcow2 file 30,00 GiB 10,93 GiB<br />
w2016_server.qcow2 /var/lib/libvirt/images/w2016_server.qcow2 file 30,00 GiB 1,11 GiB<br />
win10.qcow2 /var/lib/libvirt/images/win10.qcow2 file 20,00 GiB 9,10 GiB<br />
</pre><br />
<br />
Notar como se especifica por un lado la Capacidad del volumen, como se define a la hora de crear el volumen, y el espacio que está siendo realmente utilizado por los datos del volumen.<br />
Obtener información de un volumen<br />
<br />
<code>virsh vol-info /var/lib/libvirt/images/w2016_server_clone.qcow2</code><br />
<br />
Mostraría la información del volumen indicado en el formato siguiente<br />
<br />
<pre><br />
Name: w2016_server.qcow2<br />
Type: file<br />
Capacity: 30,00 GiB<br />
Allocation: 1,11 GiB<br />
</pre><br />
<br />
Para obtener más información sobre comandos relacionados con volúmenes<br />
<br />
<code>virsh help volume</code><br />
<br />
=== Gestión de imágenes con qemu-img ===<br />
<br />
A continuación vamos a ver un comando de qemu específicamente creado para gestionar las imágenes de almacenamiento asociadas a los volúmenes de datos de las MV<br />
<br />
=== [[ Comando qemu-img ]] ===<br />
<br />
<br />
=== Clonación enlazada ===<br />
<br />
En el apartado anterior vimos como crear un clon de un domain. Este comando resulta útil cuando queremos realizar un clon “completo”, es decir, una copia exacta y totalmente independiente del domain original.<br />
<br />
Sin embargo, en ocasiones, es muy útil utilizar las ventajas del formato de volumen qcow2 (qemu copy on write), el cual permite, entre otras cosas, trabajar con volúmenes “enlazados”; en el sentido de que un volumen enlazado a otro, que le sirve de base, solo almacenará las modificaciones efectuadas respecto al volumen de base. De este modo conseguimos ahorrar mucho espacio de almacenamiento al trabajar con domains que utilizan volúmenes que se van construyendo “unos sobre otros”.<br />
<br />
Por ejemplo, supongamos que tengo un volumen, que sirve de disco virtual al domain guest01-w10. Ese volumen se almacena en la ruta /var/lib/libvirt/images/guest01-w10.qcow2. Vamos a crear un clon de este domain, de nombre guest01-w10-lclone, que además, hará uso de un volumen que opera de modo enlazado al original, el volumen se almacenará en /var/lib/libvirt/images/guest01-w10-lclone.qcow2.<br />
Lo primero es crear un volumen “enlazado” al original, es decir, no vamos a duplicar el volumen original, sino que vamos a crear un volumen que actúe tomando el volumen original “base”, de este modo solo se almacenarán las diferencias, y no el sistema de archivos completo, en el nuevo volumen, para ello usaremos la herramienta qemu-img<br />
<br />
<code>qemu-img create -f qcow2 -b /var/lib/libvirt/images/guest01-w10.qcow2 /var/lib/libvirt/images/guest01-w10-lclone.qcow2</code><br />
<br />
Para ver la información asociada al volumen recién creado<br />
<br />
<code>qemu-img info /var/lib/libvirt/images/guest01-w10-lclone.qcow2</code><br />
<br />
Mostraría la información siguiente<br />
<br />
<pre><br />
image: /var/lib/libvirt/images/guest01-w10-lclone.qcow2<br />
file format: qcow2<br />
virtual size: 20G (21474836480 bytes)<br />
disk size: 196K<br />
cluster_size: 65536<br />
backing file: /var/lib/libvirt/images/guest01-w10.qcow2<br />
Format specific information:<br />
compat: 1.1<br />
lazy refcounts: false<br />
refcount bits: 16<br />
corrupt: false<br />
</pre><br />
<br />
En la salida anterior podemos apreciar como el campo image indica la ruta del volumen recién creado, pero el campo backing file indica la ruta al archivo de imagen del volumen original. De este modo estamos trabajando con un volumen “enlazado”, que tendrá las características indicadas previamente.<br />
<br />
A continuación vamos a efectuar el clon mediante la herramienta virt-clone, pero especificando que tome el volumen que acabamos de crear con el comando anterior, sin modificar sus datos, con la opción --preserve-data<br />
<br />
<code>virt-clone --original=guest01-w10 --name=guest01-w10-lclone --preserve-data --file=/var/lib/libvirt/images/guest01-w10-lclone.qcow2</code><br />
<br />
Ahora vamos a ver la lista de volúmenes y sus tamaños<br />
<br />
<code>virsh vol-list --details default</code><br />
<br />
La salida mostraría<br />
<br />
<pre><br />
Name Path Type Capacity Allocation<br />
---------------------------------------------------------------------------------------------<br />
w2016.qcow2 /var/lib/libvirt/images/w2016.qcow2 file 30,00 GiB 10,93 GiB<br />
w2016_server.qcow2 /var/lib/libvirt/images/w2016_server.qcow2 file 30,00 GiB 1,11 GiB<br />
guest01-w10.qcow2 /var/lib/libvirt/images/win10.qcow2 file 20,00 GiB 9,10 GiB<br />
guest01-w10_lclone.qcow2 /var/lib/libvirt/images/win10_clone.qcow2 file 20,00 GiB 57,13 MiB<br />
</pre><br />
<br />
Podemos ver como el tamaño del volumen del nuevo clon ocupa solamente 57,13 MB, sin embargo el volumen que le sirve de base ocupa 9,10 GB.<br />
<br />
== Gestión de networks ==<br />
<br />
<br />
=== Introducción ===<br />
<br />
El tratamiento de las network por parte de qemu/KVM se basa en el concepto de Virtual Network. Este concepto se basa un Switch Virtual, es decir un dispositivo software que actúa como un conmutador o switch.<br />
<br />
Al mismo switch virtual se conectarán todas las MV, guests, asociadas a la misma virtual network. De este modo todas son visibles entre sí, porque además comparten el direccionamiento IP establecido en la virtual network. También es posible configurar un servicio DHCP para una virtual network, de modo que todas las MV conectadas a él puedan tener IPs asignadas de modo automático. Otra opción es la asignación de IP manual dentro del rango de direccionamiento asociado a la virtual network.<br />
<br />
Por defecto se crea una Virtual Network de nombre “default”, que opera en modo NAT, y que tiene asociado un dispositivo de tipo Switch Virtual de nombre “virbr0”. Por supuesto son posibles muchas más configuraciones.<br />
Respecto al modo en que las MV se conectan al exterior, a través del comportamiento de reenvío del tráfico en la virtual network, encontramos los siguientes modos de operación.<br />
<br />
=== Archivo de configuración de una network ===<br />
<br />
Vamos a ver a modo de ejemplo el archivo de configuración de la network default, para ello volcamos el contenido con el comando<br />
<br />
<code>virsh net-dumpxml default</code><br />
<br />
Lo cual arroja la salida<br />
<br />
<pre><br />
<network><br />
<name>default</name><br />
<uuid>3b6d6a45-a302-4641-974a-8379dbca58da</uuid><br />
<forward mode='nat'><br />
<nat><br />
<port start='1024' end='65535'/><br />
</nat><br />
</forward><br />
<bridge name='virbr0' stp='on' delay='0'/><br />
<mac address='52:54:00:60:56:f1'/><br />
<ip address='192.168.122.1' netmask='255.255.255.0'><br />
<dhcp><br />
<range start='192.168.122.2' end='192.168.122.254'/><br />
</dhcp><br />
</ip><br />
</network><br />
</pre><br />
<br />
Como podemos observar, el nombre de la network es “default”, opera en modo forward “nat”, utiliza como dispositivo bridge, o switch virtual, virbr0, teniendo asignada la MAC 52:54:00:60:56:f1, y la dirección IP del propio switch virtual es 192.168.122.1, es decir la IP más baja dentro del rango de direccionamiento asociado a la network. Por último, vemos que tiene asociado un rango de cesiones DHCP asignables las MVs conectadas a esa network.<br />
<br />
=== NAT Mode ===<br />
<br />
Esta es el modo de red por defecto para los domains (MVs). De hecho se dispone por defecto de una network de este tipo con nombre default<br />
Para ver las networks definidas<br />
<br />
<code>virsh net-list --all</code><br />
<br />
Mostraría las networks creadas. Sino se especifica el modificador --all solo se visualizan las network activas.<br />
<br />
Este tipo de network permite construir un entorno de red virtual en el cual las MVs conectadas a la network son visibles entre sí, además de poder comunicarse desde y hacia el anfitrión, a través de la primera IP del rango de direcciones de la subred asignada.<br />
<br />
Para ello utiliza una técnica de IP masquerade con la IP del adaptador físico del host. La limitación que tiene este modo de operación es que las MVs no son accesibles directamente desde fuera del host, aunque sí pueden comunicarse entre sí, con el anfitrión y salir hacia el exterior.<br />
<br />
Veamos la información de la red NAT network default<br />
<br />
<code>virsh net-dumpxml default</code><br />
<br />
<pre><br />
<network><br />
<name>default</name><br />
<uuid>3b6d6a45-a302-4641-974a-8379dbca58da</uuid><br />
<forward mode='nat'><br />
<nat><br />
<port start='1024' end='65535'/><br />
</nat><br />
</forward><br />
<bridge name='virbr0' stp='on' delay='0'/><br />
<mac address='52:54:00:60:56:f1'/><br />
<ip address='192.168.122.1' netmask='255.255.255.0'><br />
<dhcp><br />
<range start='192.168.122.2' end='192.168.122.254'/><br />
</dhcp><br />
</ip><br />
</network><br />
</pre><br />
<br />
Vemos como se indica el mode=’nat’, los parámetros del port forwarding, el nombre del dispositivo bridge utilizado por la network, la dirección MAC del dispositivo bridge y el rango de direccionamiento IP asignable por DHCP.<br />
<br />
Por defecto la network default viene deshabilitada, es decir hay que iniciarla explícitamente para que pueda ser utilizada. Para iniciarla:<br />
<br />
<code>virsh net-start default</code><br />
<br />
Si queremos que la network se inicie de modo automático en el arranque ejecutamos<br />
<code>virsh net-autostart default</code><br />
<br />
=== Bridged Mode ===<br />
<br />
En este modo los MVs (guests) son visibles en la misma LAN que el anfitrión, de modo que se visualizan transparentemente como hosts dentro de la misma LAN. No hay por tanto mecanismos NAT asociados, de modo que la configuración de la red se establece en el dominio de la LAN sobre la que se despliega el propio anfitrión.<br />
<br />
=== Routed Mode ===<br />
<br />
Este modo de operación es similar a NAT, con la salvedad de que las reglas de reenvío de tráfico son específicamente definidas en el switch virtual, el cual es susceptible de examinar el tráfico en tránsito y efectuar decisiones de enrutamiento. En esta modalidad el switch virtual actua, por lo tanto, como un enrutador, siendo necesario especificar todas las reglas de enrutamiento explícitamente.<br />
<br />
=== Isolated Mode ===<br />
<br />
Por último, el modo aislado solo permite conectar las MVs entre sí, pero sin ningún tipo de posibilidad de acceso al exterior a través del switch virtual. Es un modo adecuado si queremos un escenario de pruebas aislado en el que no influir.<br />
<br />
=== Creación de una network a partir de otra ===<br />
<br />
Podemos volcar en un archivo xml la información de definición de una network, modificar el archivo correspondiente y por último crear una nueva network a partir del archivo modificado. Veamos un ejemplo<br />
<br />
<code>virsh net-dumpxml default > red192.xml</code><br />
<br />
Editamos el archivo red192.xml resultante para que quede<br />
<br />
<pre><br />
<network><br />
<name>red192</name><br />
<uuid>bba275f0-8866-4580-ad86-eb42e94c07fd</uuid><br />
<forward mode='nat'><br />
<nat><br />
<port start='1024' end='65535'/><br />
</nat><br />
</forward><br />
<bridge name='virbr1' stp='on' delay='0'/><br />
<mac address='52:54:00:2f:a3:d9'/><br />
<domain name='red192'/><br />
<ip address='192.168.0.1' netmask='255.255.255.0'><br />
<dhcp><br />
<range start='192.168.0.128' end='192.168.0.254'/><br />
</dhcp><br />
</ip><br />
</network><br />
</pre><br />
<br />
Y ahora creamos la nueva network a partir el archivo anterior<br />
<br />
<code>virsh net-create red192.xml</code><br />
<br />
== Gestión de snapshots ==<br />
<br />
Las snapshots (instantáneas) permiten almacenar estados de ejecución de un domain. De este modo es posible restaurar un domain al estado de ejecución almacenado en la snapshot<br />
<br />
=== Creación de snapshot con virsh ===<br />
<br />
Para crear una snapshot podemos usar virsh<br />
<br />
<code>virsh snapshot-create-as guest01-win10 --name snap1</code><br />
<br />
crearía la snapshot snap1 para el domain guest01-win10<br />
<br />
=== Lista de snapshots de un domain ===<br />
<br />
Para ver la lista de snapshots de un domain<br />
<code>virsh snapshot-list guest01-win10</code><br />
<br />
=== Restaurar un domain al estado de una snapshot ===<br />
<br />
Debemos indicar el domain y el nombre de la snapshot que queremos restaurar<br />
<br />
<code>virsh snapshot-revert guest01-win10 snap1</code><br />
<br />
restauraría el domain al estado almacenado en la snapshot snap1<br />
<br />
=== Eliminar snapshot de domain ===<br />
<br />
<code>virsh snapshot-delete guest01-win10 snap1</code><br />
<br />
eliminaría la snapshot creada anteriormente<br />
<br />
=== Más acciones con snapshots ===<br />
<br />
Podemos ver más comandos virsh relacionados con snapshots ejecutando<br />
<br />
<code>virsh help snapshot</code><br />
<br />
== Uso de drivers KVM paravirtualizados (virtio) ==<br />
<br />
Los drivers paravirtualizados son drivers de dispositivos modificados para utilizar las características de rendimiento avanzado del hipervisor KVM. Cuando utilizamos drivers emulados el rendimiento es bastante menor, pues el hipervisor tiene que simular esos dispositivos. Al utilizar drivers paravirtualizados, mediante el estándar virtio, el propio driver coopera con el hipervisor, aprovechando las características de rendimiento avanzado.<br />
<br />
Se dispone de drivers paravirtualizados para los dispositivos de bloques y tarjetas de red. En el caso de guests Linux éstos vienen integrados en KVM y son integrables en los kernel del guest.<br />
<br />
Para guest windows podemos descargar los correspondientes binarios, a través de una .iso que será utilizada durante el proceso de instalación de la máquina virtual.<br />
<br />
=== Activar virtio para dispositivos de bloques en guest Linux ===<br />
<br />
Vamos a activar el uso de virtio para dispositivos de almacenamiento de bloques. Para ello usaremos el comando virsh edit usado para modificar la configuración de una MV<br />
<br />
<code>virsh edit guets01-debian1</code><br />
<br />
Sustituimos en el elemento disk correspondiente el atributo bus dentro del elemento target, tal que así<br />
<br />
<pre><br />
<disk type='...' device='disk'><br />
...<br />
<target dev='vda' bus='virtio'/><br />
</disk><br />
</pre><br />
<br />
Si todo va bien al iniciar el guest con virsh start no deberíamos obtener ningún error<br />
<br />
=== Activar virtio para dispositivo de red en guest Linux ===<br />
<br />
De un modo similar al procedimiento anterior activamos el bus virtio en el dispositivo correspondiente<br />
<br />
<code>virsh edit guets01-debian1</code><br />
<br />
Sustituimos en el elemento interface correspondiente el atributo type dentro del elemento model, tal que así<br />
<br />
<pre><br />
<interface type='network'><br />
...<br />
<model type='virtio' /><br />
</interface><br />
</pre><br />
<br />
== LABORATORIO DE MVs ==<br />
<br />
A continuación vamos a desarrollar una práctica de construcción de un pequeño laboratorio de máquinas virtuales utilizando Qemu/KVM<br />
<br />
=== [[ LABORATORIO DE MVs ]] ===<br />
<br />
== Referencias ==<br />
<br />
=== virt-install man page ===<br />
https://linux.die.net/man/1/virt-install<br />
<br />
=== Guía de Administración de KVM en RHEL ===<br />
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/virtualization_deployment_and_administration_guide/sect-guest_virtual_machine_installation_overview-creating_guests_with_virt_install<br />
<br />
=== linux-kvm.org ===<br />
https://www.linux-kvm.org/page/Documents<br />
<br />
=== virtio ===<br />
https://wiki.libvirt.org/page/Virtio<br />
<br />
[[ Virtualización | Volver ]]<br />
<br />
JavierFP 20:17 7 nov 2017 (CET)</div>Javierfp