virt-commands en Debian – Redes de Computadoras para las PYMES

Índice general de la serie: Redes de Computadoras para las PYMES: Introducción

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!.



Ingeniero Termo Energético de profesión. Administrador de Redes desde hace ya varios años. Programador en Visual FoxPro. Debianero de Corazón, y "OldFashion Man". Contacto: federicotoujague@gmail.com / +53 5 5005735

15 comentarios

  1.   Diego dijo

    Me has pedido feedback y acá va… 🙂

    Muy interesante la serie, muy completa. Estoy aprendiendo mucho con ella, aunque todavía no he probado “en producción”.

    En estos momentos estoy terminando un proyecto que me tiene muy ocupado, pero seguramente voy a usar esta serie como referencia. Gracias por el enorme esfuerzo.

    1.    federico dijo

      Gracias Diego por el feedback. Al menos me entero de que te es útil lo publicado. Y razón tienes en lo del gran esfuerzo que hacemos en DesdeLinux para entregarle a Ustedes artículos de calidad en la lengua española. Sabemos que no abundan éste tipo de posts y por eso los escribimos.

  2.   Zodiac Carburus dijo

    Abarcador y didáctico artículo amigo fico, que recoge en un post los comandos virt-* usados en KVM. Es muy difícil encontrar materiales como este en lenguaje español. Creo que faltó el comando virt-what. Por lo demás, excelente

    1.    fico dijo

      Gracias por comentar, amigo Zodiac. Cierto que faltó el comando virt-what. Lo omití a conciencia porque la recomendación sobre su utilización acorde a su manual, me dejó un mal sabor. Al final lo que entendí es que No recomiendan su uso

  3.   Federico dijo

    Muy cierto amigo Zodiac. Como dice Diego en su comentario, es un gran esfuerzo el que hacemos en DesdeLinux para entregarle a Ustedes artículos de calidad y en español. Que no sean los clásicos posts cd copiar y pegar que abundan en la Aldea WWW. Que ayuden a la formación de Administradores de Sistemas. Los que hayan seguido esta serie, se habrán dado cuenta de que pensamos en abarcar de forma integral, y en un orden lógico, la solución para una red empresarial de pequeño o medio formato. Gracias nuevamente a todos por sus comentarios

  4.   crespo88 dijo

    He estado haciendo algo con los android smartphones, y no había tenido el chance de leer tan buen artículo, en esta ocasión solo quiero decir algo. “Dale suave”. A buen entendedor…

  5.   federico dijo

    Crespo88, puede que el artículo sea un poco extenso, pero no soy amigo de cortar un tema específico como éste en varios posts, si es que a eso te refieres. La relativa complejidad del contenido, no la pongo yo, la pone el propio tema de la virtualización. 😉

    1.    crespo88 dijo

      No me refería a ello, el artículo excelente como siempre. Me refiero a que estas tocando temas muy buenos, o sea, con una utilidad muy provechosa. El “Dale suave”, significa que estás escapaooooo. Jejejje, un abrazo hermano.

      1.    fico dijo

        Gracias hermano por comentar

  6.   petercheco dijo

    Muy buen post… Didáctico, completo y sencillamente perfecto.

    Ahora, para los que prefieran usar este tipo de virtualización, es mejor, usar oVirt (http://www.ovirt.org/), proyecto sobre el cual se costruye Red Hat Virtualization y además Open Source. De esta manera es posible acceder de una manera realmente fácil a opciones muy avanzadas, las cuales resultan bastante complejas en la consola :).

    http://www.ovirt.org/download/
    http://www.ovirt.org/documentation/introduction/about-ovirt/

    Saludos :).

  7.   Federico dijo

    Muchas gracias, Petercheco por tu comentario. En artículo anterior “Virtualización en Debian: Introducción”, en párrafo dedicado a la Open Virtualization Alliance, menciono al oVirt como uno de los softwares que promociona la OVA. Pienso que el oVirt es para grandes despliegues. Por otra parte, pide una workstation dedicada a él con 4 gigas de RAM como cantidad de memoria recomendada. Mi amigo y colega Eduardo Noel “enoel.corebsd@gmail.com” tiene instalado varios servidores de virtualización basados en CentOS 7, y los administra de maravillas con el oVirt.

  8.   Denis Cantillo dijo

    excelente articulo mi socio, otro ejemplo de la calidad que tienes

  9.   federico dijo

    Gracias amigo Denis por tu comentario e inmerecido elogio hacia mi persona. Hacemos lo que podemos.

  10.   Ismael Alvarez Wong dijo

    Si bien me queda pendiente el test de los virt-commands en mi lab-casero, no puedo dejar de reconocer que el articulo esta sencillamente genial, muy practico y sumamente útil ya que esta enfocado al terminal que es realmente mi favorito por mi perfil de sysadmin.
    Buenísimo todo lo relacionado con la administración local o remota de las MVs sin emplear interfaz gráfica del “Virt-Manager”.
    Una vez mas amigo Fico, te engrandeces compartiendo desinteresadamente tus conocimientos del mundo Linux.
    Slds efusivos de Wong y continuo con el estudio de la serie de Virt Qemu-KVM con mas ahinco.

    1.    federico dijo

      Amigo Wong: Comentarios como el tuyo son los que me obligan a continuar escribiendo sobre las Redes PYME. Muchos se podrán preguntar el porqué de mi hincapié en Qemu-KVM, y la respuesta está en mi artículo http://blog.desdelinux.net/virtualizacion-debian-introduccion-redes-computadoras-las-pymes/#Open_Virtualization_Alliance_OVA. Menos sobre el oVirt, al cual considero apropiado para escenarios mas grandes que una Red PYME, he tratado sobre los demás programas que promociona la OVA. Así de simple.

      ¿Para que buscar fuera de los repositorios de programas de cada distribución que abordo, si lo que necesito para virtualizar a nivel empresarial está ahí?.

      ¡Mis mas sinceras Gracias por tus comentarios, amigo Wong!.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*

*

  1. Responsable de los datos: Miguel Ángel Gatón
  2. Finalidad de los datos: Controlar el SPAM, gestión de comentarios.
  3. Legitimación: Tu consentimiento
  4. Comunicación de los datos: No se comunicarán los datos a terceros salvo por obligación legal.
  5. Almacenamiento de los datos: Base de datos alojada en Occentus Networks (UE)
  6. Derechos: En cualquier momento puedes limitar, recuperar y borrar tu información.