.. _libvirt-create: Creación ======== Nos centraremos en crear y gestionar máquinas con las herramientas |CLI|, porque la interfaz gráfica, una vez que se entiende el funcionamiento general de la aplicación no tiene excesivos secretos e, incluso, guarda ciertas semejanzas con la de :ref:`Virtualbox `. Hay dos órdenes fundamentales: + :manpage:`virt-install`, que nos permite definir la máquina virtual y el anfitrión que se alojará en ella. + :manpage:`virsh`, que nos permitirá consultarla, gestionarla y modificarla. .. note:: Este epigrafe se centra exclusivamente en cómo crear máquinas virtuales y no en cómo comprobar que se han creado y cómo se arrancan. Probar y consultar las máquinas se hará bajo el :ref:`próximo epígrafe `. Para crear (e instalar) una máquina podemos empezar haciendo lo siguiente:: $ virt-install --osinfo debian11 -n bullseye --metadata title="Debian Bullseye" --memory 1024 --vcpus 2 \ --network user --disk disco.qcw,size=4,format=qcow2 --cdrom debian-11.6.0-amd64.iso La orden creará una máquina de nombre "*Bullseye*" con sistema *Debian 11* (:kbd:`--osinfo`)\ [#]_, una memoria de 1GiB, 2 procesadores y :ref:`red de usuario `. El disco será :file:`disco.qcw` y es nuevo porque junto a la ruta especificamos su tamaño y su formato. La orden nos obliga a indicar el método de instalación, así que añadimos un disco de instalación con :kbd:`--cdrom`. Crear una máquina se traduce en generar un |XML| con las características de la máquina virtual (:ref:`ya veremos dónde `) que con sólo referir su nombre permitirá arrancarla en el futuro conservando tales caracterísicas (:ref:`ya veremos cómo `). Ahora, sin embargo, tendrá por efecto abrir una ventana gráfica dentro de la que veremos el huésped y podremos realizar la instalación. Podemos variar la creación introduciendo variantes a esta orden que afectan a distintos aspectos: Punto de partida ---------------- Un primer aspecto es el *punto de partida*, esto es, de qué partimos cuando creamos la máquina virtual. El ejemplo anterior presenta un punto en el que no disponemos de nada, de ahí que la orden cree el disco y haya que facilitarle los parámetros mínimos (tamaño y formato). Hay otras variantes: * Que el disco, aunque creado (p.e. con :ref:`qemu-img create `), esté vacío. En ese caso, la orden será exactamente la misma, pero sin incluir tamaño y formato. * Que el disco ya contenga un sistema, por lo que no necesita proceso de instalación. En tal caso, sobrará la opción :kbd:`--cdrom` a cambio de la cual habrá que incluir un par más:: $ virt-install --osinfo debian11 -n bullseye --metadata title="Debian Bullseye" --memory 1024 --vcpus 2 \ --network user --disk disco.qcw --import --noreboot --autoconsole none :kbd:`--import` advierte de que importamos un disco ya preparado, :kbd:`--noreboot` impide que arranque la máquina (por lo que sólo se creará el |XML| que la define), y :kbd:`--autoconsole none` no abrirá el visor :manpage:`virt-viewer`. * Que dispongamos del disco y el |XML| de configuración (p.e. porque los trajimos de otro anfitrión). En este caso, primero debimos haber obtenido el |XML|, lo cual se consigue con:: $ virsh dumpxml bullseye > bullseye.xml En el nuevo anfitrión deberemos copiar :file:`disco.qcw` y :file:`bullseye.xml`, quizás editar este último para adecuar la ruta donde se encuentre el disco e importar el |XML|:: $ vim /tmp/bullseye.xml # Ajustamos la ruta a donde hemos copiado disco.qcw $ virsh define bullseye.xml El resultado será una máquina con exactamente la misma definición en el nuevo anfitrión. * Que queramos directamente clonar una máquina para crear otra:: $ virt-clone -o bullseye --auto-clone que creará una nueva máquina llamada "*bullseye-clone*" con un disco que compartirá ruta con el original pero añadirá :kbd:`-clone` a su nombre. Si se quiere afinar un poco más:: $ virt-clone -o bullseye -n nuevabulls.eye -f nuevodisco.qcw orden a la que se le pueden seguir añadiendo más características para modificar las originales (véase :manpage:`virt-clone`). .. _virt-install-hipervisor: Hipervisor ---------- Ya se ha apuntado que :program:`libvirt` es capaz de servir para la gestión de varios hipervisores, aunque nosotros nos centraremos en el caso de que sea :ref:`QEmu `. Para expresar qué hipervisor queremos utilizar, las órdenes (:command:`virt-install`, :command:`virsh`) tienen una opción :kbd:`--connect` a la que hay que indicar el hipervisor en forma de |URI|: | :code:`qemu:///session` | :code:`qemu:///system` | :code:`vbox:///session` | :code:`lxc:///` | etc... La diferencia entre las dos variantes de :program:`QEmu` presentes es que la primera no gozará de permisos extraordinarios al del propio usuario, con lo que puede haber acciones que no se puedan hacer. Por ejemplo, no se podrán crear interfaces de red adicionales\ [#]_. Además, la primera almacenará la configuración de las máquinas en el directorio de usuario :file:`~/.config/libvirt/qemu` mientras que la segunda en el global :file:`/etc/libvirt/qemu`. Si no se especifica ninguno expresamente, se tomará :code:`qemu:///session` (al menos en mi sistema *Debian*):: $ virsh uri qemu:///session pero este valor prefijado se puede manipular por dos vías: o definiendo la variable de ambiente *LIBVIRT_DEFAULT_URI*. o añadiendo la definición al archivo :file:`~/.config/libvirt/libvirt.cont`:: $ echo "uri_default = qemu:///system" >> ${XDG_CONFIG_HOME:-~/.config}/libvirt/libvirt.conf En cualquier caso, la orden de creación podríamos haberla escrito así:: $ virt-install --conect 'qemu:///system' --osinfo debian11 -n bullseye --metadata title="Debian Bullseye" \ --memory 1024 --vcpus 2 --network user --disk disco.qcw,size=4,format=qcow2 --cdrom debian-11.6.0-amd64.iso Téngase presente que esto también es aplicable a :command:`virsh` y :command:`virt-clone`, de modo que la clonación deberíamos haberla hecho así:: $ virt-clone --connect 'qemu:///system' -o bullseye -n nuevabulls.eye -f nuevodisco.qcw porque de lo contrario no se habría podido encontrar la máquina "*bullseye*". .. _libvirt-install-firmware: Firmware -------- Como no se ha indicado nada al respecto la máquina usará un *firmware* |BIOS|. Para |EFI| bastará con añadir :code:`--boot uefi`:: $ virt-install --osinfo debian11 -n bullseye --metadata title="Debian Bullseye" --memory 1024 --vcpus 2 \ --network user --disk disco.qcw,size=4,format=qcow2 --cdrom debian-11.6.0-amd64.iso --boot uefi .. _libvirt-install-video: Acceso al huésped ----------------- A los huésped anteriores, tal como los hemos definido, se tendrá acceso a través de una ventana gráfica :ref:`como la descrita cuando tratamos QEmu `. Es posible, no obstante, definir accesos distintos utilizando la opción :kbd:`--graphics`: .. _libvirt-install-video-vnc: |VNC| Para definir un acceso mediante una conexión |VNC| podemos añadir:: $ virt-install --osinfo debian11 -n bullseye --metadata title="Debian Bullseye" --memory 1024 --vcpus 2 \ --network user --disk disco.qcw,size=4,format=qcow2 --cdrom debian-11.6.0-amd64.iso --graphics vnc .. _libvirt-install-video-spice: *Spice* En este caso el añadido debe ser el siguiente:: $ virt-install --osinfo debian11 -n bullseye --metadata title="Debian Bullseye" --memory 1024 --vcpus 2 \ --network user --disk disco.qcw,size=4,format=qcow2 --cdrom debian-11.6.0-amd64.iso \ --graphics spice --video qxl --channel spicevmc .. _libvirt-install-video-texto: *Texto* Para un huésped sin entorno gráfico es interesante, simplemente, no definir salida gráfica y ofrecer una consola a través del puerto serie. En este caso, el huésped debemos prepararlo tal como :ref:`se explica para QEmu ` y la máquina deberá definirse así:: $ virt-install --osinfo debian11 -n bullseye --metadata title="Debian Bullseye" --memory 1024 --vcpus 2 \ --network user --disk disco.qcw,size=4,format=qcow2 --cdrom debian-11.6.0-amd64.iso \ --graphics none --console pty,target.type=virtio --serial pty Red --- :program:`libvirt` ofrece cuatro alternativas para la red definida a través de :kbd:`--network` (forma larga) o :kbd:`-w` (forma corta): *none* (:code:`-w none`) esto es, no definir ninguna interfaz, porque de forma predeterminada se crea una. *Red de usuario* (:code:`-w user`) Equivalente a :ref:`la red de usuario de QEmu `. Es la que hemos utilizado en los ejemplo con :command:`virt-install`, aunque su expresión sobraba, porque es la que se usa cuando el hipervisor es :kbd:`qemu:///session` en caso de que no se haya :ref:`manipulado la configuración de la red `. .. note:: No parece haber una forma nativa de redirigir puertos al huésped con esta modalidad (p.e. para el acceso al servidor |SSH|). La única posibilidad consiste en no definir red (*none*) y editar el |XML| para añadir expresamente los argumentos de :program:`QEmu` que definen la red de usuario (véase `esta respuesta en stackexchange.com `_). *Puente* (:code:`-w bridge=nombre_interfaz_puente`) Consiste en incorporar la interfaz de red de la máquina virtual a una interfaz puente preexistente en el anfitrión y es equivalente al :ref:`puente que se trató con QEmu `. La interfaz puente no se crea al crear la máquina o arrancarla, sino que debe crearse antes manualmente o bien definirse como una red con nombre al :ref:`configurar la red `\ [#]_. Obviamente, esta segunda forma es más limpia y la preferible y permite expresar la red mediante el nombre que se le dé en vez de mediante el nombre de la interfaz puente: :code:`-w network=nombre`:: $ virt-install --osinfo debian11 -n bullseye --metadata title="Debian Bullseye" --memory 1024 --vcpus 2 \ --network network=interna1 --disk disco.qcw,size=4,format=qcow2 --cdrom debian-11.6.0-amd64.iso supuesto que se hubiera creado previamente una red de nombre "*interna1*". Para el hipervisor :kbd:`qemu:///system` existe ya una red predefinida ("*default*") que usa una interfaz puente llamada *virbr0* y es a esta red a la que se pertenecerá la interfaz del anfitrión si no expresa red al crear la máquina con :program:`virt-install`. *Directa* (:code:`-w direct,source=interfaz_fisca`) Equivalente al :ref:`puente con interfaz macvtap de QEmu `, por lo que es aplicable todo lo que se explicó entonces: si el anfitrión usa la propia interfaz física, será incapaz de comunicar con el huésped. No necesita preparación previa, a diferencia del anterior, porque la interfaz macvtap se creará (o destruirá) *ex profeso* al arrancar (o parar) la máquina virtual:: $ virt-install --osinfo debian11 -n bullseye --metadata title="Debian Bullseye" --memory 1024 --vcpus 2 \ --network direct,source=eth0 --disk disco.qcw,size=4,format=qcow2 --cdrom debian-11.6.0-amd64.iso Deberá usarse :kbd:`qemu:///system`, porque con :kbd:`qemu:///session` no se tendrán permisos suficientes. .. rubric:: Notas al pie .. [#] El argumento de :kbd:`--osinfo` no es arbitrario, sino restringido a una lista que puede consultar con:: $ virt-install --osinfo list .. [#] Todo esto se entiende mejor, si ha echado una lectura detenida a la :ref:`red de QEmu `: podremos hacer todo lo que podríamos hacer utilizando :command:`qemy-system-x86_64` con el usuario sin privilegios. Y esto podría incluir crear interfaces *TAP* dentro de una interfaz puente ya existente si hubiéramos :ref:`configurado convenientemente el helper `. .. [#] Estas redes, sin embargo, no pueden crearse con el hiperrvisor :kbd:`qemu:///session`. .. |CLI| replace:: :abbr:`CLI (Command Line Interface)` .. |XML| replace:: :abbr:`XML (eXtensible Markup Language)` .. |URI| replace:: :abbr:`URI (Uniform Resource Identifier)` .. |VNC| replace:: :abbr:`VNC (Virtual Network Computing)` .. |BIOS| replace:: :abbr:`BIOS (Basic I/O System)` .. |EFI| replace:: :abbr:`EFI (Extensible Firmware Interface)`