virt-commands en Debian – Redes de Computadoras para las PYMES
El título de este post hace referencia a una serie de comandos de consola que comienzan con “virt-“ y que pueden ser útiles en determinadas circunstancias. Solamente daremos una pequeña descripción de cada uno, y algunos ejemplos de uso. Repetimos que: No podemos sustituir a los manuales que acompañan a cada comando. Sugerimos encarecidamente consulten esas páginas ejecutando man virt-comando.
- El objetivo fundamental de este artículo es continuar mostrando el amplio universo que es actualmente la Virtualización en Linux mediante el Hipervisor Qemu-KVM. Aunque en el título escribimos el nombre la distribución “Debian“, los principios generales son aplicables a cualquier otra distribución mediante los comandos específicos de cada una de ellas. Sobre todo los referentes a la búsqueda, descripción e instalación de paquetes, entre otros.
Antes de continuar con la lectura, recomendamos visiten el artículo anterior : Qemu-KVM + Virt-Manager en Debian – Redes de computadoras para las PYMES.
¿Cuándo utilizar los comandos?
En muchas ocasiones estamos administrando remotamente a un servidor soporte de virtualización con el Qemu-KVM instalado, y por alguna razón no disponemos de la interfaz gráfica del Gestor de Máquina Virtual – Virt-Manager:
- Caso típico, cuando accedemos al servidor remoto desde una estación con Windows vía PuTTy, o cualquier otra de las muchas alternativas que existen para conectarnos vía SSH con un servidor Debian GNU/Linux, y éste último no tiene instalado ningún soporte para las “X“, o soporte gráfico.
- Simplemente deseamos administrar las máquinas virtuales del servidor local o remoto mediante comandos de consola.
Instalados con libvirt-clients
En el artículo anterior instalamos el paquete libvirt-bin, y como parte del proceso se instaló libvirt-clients. Si ejecutamos en una consola:
buzz@sysadmin:~$ sudo dpkg -L libvirt-clients | grep /bin /usr/bin /usr/bin/virsh /usr/bin/virt-host-validate /usr/bin/virt-login-shell /usr/bin/virt-xml-validate /usr/bin/virt-pki-validate
- virsh: el programa virsh es la interfaz principal de usuario para la gestión completa de los Dominios Invitados – Guests. Se utiliza para listar, crear, pausar, y apagar los dominios. Este comando se debe invocar con permisos de root. Tiene dos formas de ejecutarse: en modo comando y en modo interactivo. A virsh le dedicaremos un próximo artículo.
- virt-host-validate: herramienta que permite validar la configuración del Anfitrión – Host, de forma que éste sea capaz de soportar todos los drivers del Hipervisor – Hypervisor. Para obtener resultados correctos, el comando se debe ejecutar con permisos de root.
- virt-login-shell: comando para ejecutar una shell personalizada para un usuario normal en un contenedor LXC, cuyo nombre es igual al del usuario que la invoca. Si no se encuentra en ejecución el contenedor, el comando virt-login-shell lo intentará iniciar. Este comando no se puede invocar con permisos del usuario root. El archivo de configuración -muy explícito- de éste programa es /etc/libvirt/virt-login-shell.conf.
- virt-xml-validate: valida los archivos XML de libvirt comparándolos con un esquema – schema válido. Una lista de los nombres de esquemas válidos la obtenemos si ejecutamos man virt-xml-validate.
- virt-pki-validate: se utiliza para validar sí los archivos PKI de libvirt están correctamente configurados, tanto del lado del servidor seguro, como del cliente que utilizará el protocolo de encriptación TLS para acceder remotamente al servidor. Su ejecución será necesaria si tenemos habilitada la administración remota sobre TLS y SSL. El capítulo 22.2 del documento Virtualization Deployment and Administration Guide, está dedicado a esta solución. Sugerimos que en nuestras redes empresariales se use la administración remota vía SSH, método más sencillo y seguro para una LAN Empresarial, a la cual le dedicaremos un artículo posterior.
Instalados con virtisnt
En el artículo anterior, también instalamos el paquete virt-manager. Como parte de ese proceso, se instaló el paquete virtinst. Si queremos conocer cuales comandos contiene éste último, ejecutamos:
byzz@sysadmin:~$ sudo dpkg -L virtinst | grep /bin /usr/bin /usr/bin/virt-convert /usr/bin/virt-image /usr/bin/virt-xml /usr/bin/virt-install /usr/bin/virt-clone
- virt-convert: comando que convierte las definiciones de máquinas virtuales en formatos VMX y OVF al formato nativo de libvirt XML. El formato VMX es típicamente utilizado por la VMware, mientras que el OVF “Open Virtualization Format” lo puede utilizar cualquier Hypervisor que lo soporte.
- virt-image: crea una máquina virtual a partir de un archivo descriptor de imágenes en formato XML. Esta herramienta en particular se eliminará de las futuras versiones de virtinst, por lo que No Sugerimos su uso.
- virt-xml: Permite la edición de archivos nativos XML utilizados por libvirt, mediante opciones de la línea de comando.
- virt-install: herramienta de línea de comandos que permite crear nuevas máquinas virtuales en Hipervisores como KVM, Xen o Contenedores Linux que utilicen la librería de gestión del hipervisor “libvirt”. Esta herramienta soporta la instalación gráfica si utilizamos, por ejemplo, el VNC Virtual Network Computing, o el SPICE. También soporta totalmente el modo consola o texto. Mediante su uso podemos crear una máquina virtual con uno o más discos duros, una o varias tarjetas de red, dispositivos de sonido, dispositivos físicos USB o PCI, etcétera. El medio de instalación puede ser local, remoto, publicado mediante el protocolo nativo de UNIX NFS Network File System, HTTP, FTP. etcétera.
- virt-clone: herramienta de línea de comandos para clonar máquinas virtuales existentes utilizando la librería de gestión del hipervisor “libvirt”. Básicamente copia la imagen de una máquina virtual y crea un nuevo Invitado – Guest con idéntica configuración de hardware. Los elementos de hardware que requieran ser únicos, por ejemplo, la dirección del hardware de una tarjeta de red, se actualizarán para evitar colisiones o ruidos entre el viejo y el nuevo Guest.
virt-viewer
Ésta herramienta se instala también al hacerlo el virt-manager. virt-viewer es un paquete independiente.
- virt-viewer: nos permite mostrar una consola gráfica, vía VNC o SPICE, de una determinada máquina virtual, esté ubicada local o remotamente. Podemos referirnos al Guest que queremos visualizar mediante su nombre, ID, o UUID. Si la máquina virtual no se encuentra en ejecución, virt-viewer esperará a que se inicie.
Otros comandos “virt-” que se pueden instalar a partir de paquetes independientes
- virt-goodies: colección de herramientas relacionadas con la virtualización. Incluye un plugin para “Munin“, y un script para convertir máquinas virtuales creadas con VMware Workstation o VMware Server, al formato utilizado en Qemu-KVM.
- virt-top: muestra las estadísticas de dominios virtualizados. Una especia de top o htop para las máquinas virtuales
Instalados con qemu-utils
Aunque el nombre de estas herramientas no comienzan con virt-, seguro tendremos que utilizar alguna de ellas en determinado momento, sobre todo la relacionada con las imágenes de los discos de las máquinas virtuales.
Las podremos invocar después de instalada la plataforma de virtualización Qemu-Kvm, como se indica en el artículo anterior. Si queremos conocer cuáles comandos dejó a nuestra disposición el paquete qemu-utils, solo necesitamos ejecutar:
buzz@sysadmin:~$ sudo dpkg -L qemu-utils | grep /bin /usr/bin /usr/bin/qemu-img /usr/bin/qemu-nbd /usr/bin/qemu-io
Si en vez de discriminar por /bin lo hubiéramos hecho por /sbin, obtendríamos otro resultado el cual lo dejamos a su consideración.
- qemu-img: nos permite crear, y convertir y/o modificar imágenes de discos que no estén en funcionamiento o que estén Fuera de Línea.
Sugerimos ejecuten el comando man qemu-img. Solamente haremos hincapié en que NUNCA debemos utilizar éste comando para modificar cualquier imagen que está en uso por cualquier máquina virtual o cualquier otro proceso, porque puede destruir la imagen. Tampoco debemos consultar los datos de una imagen que esté en el proceso de modificación, pues podemos encontrar inconsistencias en su estado.
Ejemplos de uso de algunos de los comandos
virt-host-validate
buzz@sysadmin:~$ virt-host-validate QEMU: Checking for hardware virtualization : PASS QEMU: Checking for device /dev/kvm : PASS QEMU: Checking for device /dev/vhost-net : WARN (Load the 'vhost_net' module to improve performance of virtio networking) QEMU: Checking for device /dev/net/tun : PASS LXC: Checking for Linux >= 2.6.26 : PASS buzz@sysadmin:~$ sudo virt-host-validate [sudo] password for buzz: QEMU: Checking for hardware virtualization : PASS QEMU: Checking for device /dev/kvm : PASS QEMU: Checking for device /dev/vhost-net : PASS QEMU: Checking for device /dev/net/tun : PASS LXC: Checking for Linux >= 2.6.26 : PASS
virt-xml-validate
buzz@sysadmin:~$ sudo virt-xml-validate /etc/libvirt/qemu/dns.xml /etc/libvirt/qemu/dns.xml validates buzz@sysadmin:~$ sudo virt-xml-validate /etc/libvirt/qemu/networks/default.xml /etc/libvirt/qemu/networks/default.xml validates
qemu-img
buzz@sysadmin:~$ qemu-img check /tera/vmware/omicron/omicron.vmdk
No errors were found on the image.
buzz@sysadmin:~$ qemu-img info /tera/vmware/omicron/omicron.vmdk
image: /tera/vmware/omicron/omicron.vmdk
file format: vmdk
virtual size: 20G (21474836480 bytes)
disk size: 3.6G
cluster_size: 65536
Format specific information:
cid: 1473577509
parent cid: 4294967295
create type: monolithicSparse
extents:
[0]:
virtual size: 21474836480
filename: /tera/vmware/omicron/omicron.vmdk
cluster size: 65536
format:
buzz@sysadmin:~$ qemu-img info /tera/vms/omicron.raw
image: /tera/vms/omicron.raw
file format: raw
virtual size: 20G (21474836480 bytes)
disk size: 3.4G
buzz@sysadmin:~$ qemu-img info /tera/vms/miweb.qcow2
image: /tera/vms/miweb.qcow2
file format: qcow2
virtual size: 10G (10737418240 bytes)
disk size: 4.5G
cluster_size: 65536
Format specific information:
compat: 1.1
lazy refcounts: false
buzz@sysadmin:~$ sudo qemu-img convert -p /tera/vms/omicron.raw -O qcow2 /tera/vms/omicron.qcow2
(27.56/100%)
buzz@sysadmin:~$ qemu-img info /tera/vms/omicron.qcow2
image: /tera/vms/omicron.qcow2
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 3.5G
cluster_size: 65536
Format specific information:
compat: 1.1
lazy refcounts: false
buzz@sysadmin:~$ sudo qemu-img create -f qcow2 /tera/vms/hyp2.qcow2 20G
Formatting '/tera/vms/hyp2.qcow2', fmt=qcow2 size=21474836480 encryption=off cluster_size=65536 lazy_refcounts=off
buzz@sysadmin:~$ sudo qemu-img info /tera/vms/hyp2.qcow2
image: /tera/vms/hyp2.qcow2
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 196K
cluster_size: 65536
Format specific information:
compat: 1.1
lazy refcounts: false
virt-xml
Primero, creamos un nuevo disco:
buzz@sysadmin:~$ sudo qemu-img create -f qcow2 /tera/vms/dns2.qcow2 10G
Luego lo unimos al dominio “dns” existente:
buzz@sysadmin:~$ virt-xml --connect qemu:///system dns --add-device --disk /tera/vms/dns2.qcow2 --confirm
--- Original XML
+++ Altered XML
@@ -128,5 +128,10 @@
<memballoon model="virtio">
<address type="pci" domain="0x0000" bus="0x00" slot="0x08" function="0x0"/>
</memballoon>
+ <disk type="file" device="disk">
+ <driver name="qemu" type="qcow2"/>
+ <source file="/tera/vms/dns2.qcow2"/>
+ <target dev="vdb"/>
+ </disk>
</devices>
</domain>
Define 'dns' with the changed XML? (y/n): y
Domain 'dns' defined successfully.
Al final del artículo damos la estructura completa del archivo /etc/libvirt/qemu/dns.xml recién modificado.
virt-convert
Convirtamos una máquina virtual creada mediante el VMware Workstation hacia el formato libvirt, no sin antes especificar que el formato del disco duro convertido sea qcow2, y además, que la nueva imagen de la máquina virtual se cree en el depósito principal /tera/vms. También queremos que la salida del comando sea lo más explícita, y por ello usamos la opción -d.
buzz@sysadmin:~$ sudo virt-convert -d /tera/vmware/miweb/ --disk-format qcow2 --destination /tera/vms
Después, el virt-viewer se conecta automáticamente al Guest recién convertido, y podemos ver todo su proceso de arranque.
virt-clone
Clonemos la máquina virtual “dns“:
buzz@sysadmin:~$ virt-clone --connect qemu:///system -o dns --auto-clone Asignando 'dns-clone.qcow2' | 10 GB 00:20 Asignando 'dns2-clone.qcow2' | 10 GB 00:01 El clon 'dns-clone' ha sido creado exitosamente.
Comprobamos mediante el comando virsh, lo cual es un adelanto del próximo artículo:
buzz@sysadmin:~$ sudo virsh list Id Name State ---------------------------------------------------- buzz@sysadmin:~$ sudo virsh list --all Id Name State ---------------------------------------------------- - dns shut off - dns-clone shut off - miweb shut off buzz@sysadmin:~$ sudo virsh start dns-clone Domain dns-clone started
buzz@sysadmin:~$ virt-viewer --connect qemu:///system dns-clone
virt-install
Deseamos crear una máquina virtual denominada “WordPress” para alojar el sitio de la Intranet Empresarial. No se publicará en Internet. Que posea unos 1024 megas de memoria RAM, un disco duro de 80 gigas de crecimiento dinámico, que se base en Debian Jessie, y quede conectada a la red “default“.
Para facilitarnos la vida, primero creamos la imagen de disco mediante qemu-img:
buzz@sysadmin:~$ sudo qemu-img create -f qcow2 /tera/vms/wordpress.qcow2 80G Formatting '/tera/vms/wordpress.qcow2', fmt=qcow2 size=85899345920 encryption=off cluster_size=65536 lazy_refcounts=off
A continuación, creamos la máquina y comenzamos el proceso de instalación:
buzz@sysadmin:~$ sudo virt-install --connect qemu:///system --virt-type=kvm \ --name wordpress --ram 1024 --vcpus=1 \ --disk /tera/vms/wordpress.qcow2 \ --cdrom /home/buzz/isos/Linux/debian-8/debian-8.0.0-amd64-CD-1.iso \ --os-type linux --network network=default \ --description wordpress.desdelinux.fan
virt-top
buzz@sysadmin:~$ virt-top --connect qemu:///system virt-top 15:39:21 - x86_64 2/2CPU 1600MHz 3863MB 2 domains, 2 active, 2 running, 0 sleeping, 0 paused, 0 inactive D:0 O:0 X:0 CPU: 0.7% Mem: 768 MB (768 MB by guests) ID S RDRQ WRRQ RXBY TXBY %CPU %MEM TIME NAME 22 R 0 0 104 0 0.3 6.0 0:11.49 dns 21 R 0 0 104 0 0.3 13.0 0:13.42 miweb
Estructura del archivo dns.xml
Al principio nos puede parecer un poco difícil entender la estructura del archivo de definición de una máquina virtual o Guest, tal y como lo entiende el hipervisor Qemu-KVM y librerías relacionadas como libvirt. El archivo tiene el formato estándar .xml. Está estructurado por bloques de definiciones, contenidos dentro del bloque principal “domain“.
<domain type='kvm'> .... </domain>
Dentro de ese bloque encontraremos las definiciones de toda la máquina virtual:
- nombre del equipo
- uuid del equipo
- cantidad de memoria RAM
- cantidad de procesadores
- tipo de sistema operativo y su arquitectura. dispositivo de booteo.
- características que soporta como el ACPI “Automatic Control Power Interface”, APM “Automatic Power Management”, y PAE.
- modelo de la(s) CPU(s) y sus características
- ajuste del reloj: si es UTC “United Time Cordinate” o no.
- respuesta a eventos como apagar, reiniciar, o fallo del sistema
- si el PM “Power Management” tiene habilitados los eventos “suspender escribiendo en memoria” y “suspender escribiendo en el disco duro”
- tipo de emulador de los diferentes dispositivos o KVM devices
- para todos los discos duros: driver, tipo de disco, ruta del archivo de la imagen, dispositivo de destino, tipo de bus, ranura “slot” pci al cual está conectado, etcétera, según sea el disco virtual: IDE, SATA, SCSI, USB o Virtio.
- dispositivos ópticos como CDR
- cantidad y tipo de conectores USB
- slot pci para disco IDE
- conector serie para comunicaciones
- conector paralelo para impresoras
- tarjetas de red con una MAC address única, tipo de trajeta de red, a cual slot pci está conectada, y a cual red virtual se conectará
- consolas serie tipo pty
- dispositivos de entrada como almohadilla “tablet“, teclado, ratón “mouse“, etcétera.
- tarjeta de vídeo y su RAM, tipo, modelo, slot, bus, etcétera.
- y otro largo etcétera
En fin, La Mar Océana de definiciones y dispositivos que sean necesarios y soportados por el hipervisor Qemu-KVM y librerías relacionadas, para tener una máquina virtual totalmente funcional como si fuera una máquina real.
buzz@sysadmin:~$ sudo cat /etc/libvirt/qemu/dns.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 dns
or other application using the libvirt API.
-->
<domain type='kvm'>
<name>dns</name>
<uuid>9e69ebc6-213e-42f7-99bf-83b333e93958</uuid>
<memory unit='KiB'>262144</memory>
<currentMemory unit='KiB'>262144</currentMemory>
<vcpu placement='static'>1</vcpu>
<os>
<type arch='x86_64' machine='pc-i440fx-2.1'>hvm</type>
<boot dev='hd'/>
</os>
<features>
<acpi/>
<apic/>
<pae/>
</features>
<cpu mode='custom' match='exact'>
<model fallback='allow'>Nehalem</model>
<vendor>Intel</vendor>
<feature policy='require' name='tsc-deadline'/>
<feature policy='require' name='dtes64'/>
<feature policy='require' name='xsave'/>
<feature policy='require' name='vmx'/>
<feature policy='require' name='erms'/>
<feature policy='require' name='xtpr'/>
<feature policy='require' name='smep'/>
<feature policy='require' name='pcid'/>
<feature policy='require' name='est'/>
<feature policy='require' name='monitor'/>
<feature policy='require' name='tm'/>
<feature policy='require' name='pclmuldq'/>
<feature policy='require' name='acpi'/>
<feature policy='require' name='vme'/>
<feature policy='require' name='osxsave'/>
<feature policy='require' name='tm2'/>
<feature policy='require' name='ht'/>
<feature policy='require' name='pdcm'/>
<feature policy='require' name='fsgsbase'/>
<feature policy='require' name='ds'/>
<feature policy='require' name='invtsc'/>
<feature policy='require' name='rdtscp'/>
<feature policy='require' name='ss'/>
<feature policy='require' name='pbe'/>
<feature policy='require' name='ds_cpl'/>
</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>restart</on_crash>
<pm>
<suspend-to-mem enabled='no'/>
<suspend-to-disk enabled='no'/>
</pm>
<devices>
<emulator>/usr/bin/kvm</emulator>
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2'/>
<source file='/tera/vms/dns.qcow2'/>
<target dev='vda' bus='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</disk>
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2'/>
<source file='/tera/vms/dns2.qcow2'/>
<target dev='vdb' bus='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
</disk>
<disk type='block' device='cdrom'>
<driver name='qemu' type='raw'/>
<target dev='hda' bus='ide'/>
<readonly/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>
<controller type='usb' index='0' model='ich9-ehci1'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x7'/>
</controller>
<controller type='usb' index='0' model='ich9-uhci1'>
<master startport='0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0' multifunction='on'/>
</controller>
<controller type='usb' index='0' model='ich9-uhci2'>
<master startport='2'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x1'/>
</controller>
<controller type='usb' index='0' model='ich9-uhci3'>
<master startport='4'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x2'/>
</controller>
<controller type='pci' index='0' model='pci-root'/>
<controller type='ide' index='0'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
</controller>
<controller type='virtio-serial' index='0'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
</controller>
<interface type='network'>
<mac address='52:54:00:08:07:5e'/>
<source network='default'/>
<model type='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>
<serial type='pty'>
<target port='0'/>
</serial>
<console type='pty'>
<target type='serial' port='0'/>
</console>
<channel type='spicevmc'>
<target type='virtio' name='com.redhat.spice.0'/>
<address type='virtio-serial' controller='0' bus='0' port='1'/>
</channel>
<input type='tablet' bus='usb'/>
<input type='mouse' bus='ps2'/>
<input type='keyboard' bus='ps2'/>
<graphics type='spice' autoport='yes'/>
<sound model='ich6'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</sound>
<video>
<model type='qxl' ram='65536' vram='65536' heads='1'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
</video>
<redirdev bus='usb' type='spicevmc'>
</redirdev>
<redirdev bus='usb' type='spicevmc'>
</redirdev>
<redirdev bus='usb' type='spicevmc'>
</redirdev>
<redirdev bus='usb' type='spicevmc'>
</redirdev>
<memballoon model='virtio'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
</memballoon>
</devices>
</domain>
Próximas entregas
- Comando virsh
- Administración remota de hipervisores y sus máquinas virtuales mediante SSH
Recuerden que esta será una serie de artículos de Redes de Computadoras para las PYMES. ¡Los estaremos esperando!.
El artículo virt-commands en Debian – Redes de Computadoras para las PYMES aparece primero en virt-commands en Debian – Redes de Computadoras para las PYMES.
