Product SiteDocumentation Site

Red Hat Enterprise Linux 5

Manual de virtualización

Virtualization Documentation

Edición 5.8

Red Hat Engineering Content Services

Aviso Legal

Copyright © 2008, 2009, 2010, 2011, 2012 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
All other trademarks are the property of their respective owners.


1801 Varsity Drive
 RaleighNC 27606-2072 USA
 Phone: +1 919 754 3700
 Phone: 888 733 4281
 Fax: +1 919 754 3701

Resumen
The Red Hat Enterprise Linux Virtualization Guide contains information on installation, configuring, administering, and troubleshooting virtualization technologies included with Red Hat Enterprise Linux.

Prefacio
1. Acerca de este libro
2. Convenciones del Documento
2.1. Convenciones Tipográficas
2.2. Convenciones del documento
2.3. Notas y Advertencias
3. We need your feedback
3.1. Technical review requests
4. What is Virtualization?
5. Types of Virtualization
5.1. Full Virtualization
5.2. Para-Virtualization
5.3. Para-virtualized drivers
6. How CIOs should think about virtualization
I. Requerimientos y limitaciones para virtualización con Red Hat Enterprise Linux
1. Requerimientos del sistema
2. Restricciones y soporte de Xen
3. Restricciones de KVM y soporte
4. Hyper-V restrictions and support
5. Limitaciones de virtualización
5.1. Limitaciones generales para virtualización
5.2. Limitaciones de KVM
5.3. Limitaciones de Xen
5.4. Limitaciones de aplicación
II. Instalación
6. Instalación de paquetes de virtualización
6.1. Instalación Xen con una instalación de Red Hat Enterprise Linux 5
6.2. Instalación de paquetes Xen en un sistema de Red Hat Linux existente
6.3. Instalación de KVM con una nueva instalación de Red Hat Enterprise Linux
6.4. Instalación de paquetes KVM en un sistema existente de Red Hat Enterprise Linux
7. Visión general de la tecnología de virtualización
7.1. Creación de huéspedes con virt-install
7.2. Creación de huéspedes con virt-manager
7.3. Instalación de huéspedes con PXE
8. Procedimiento de instalación de sistema operativo de huésped
8.1. Instalación de Red Hat Enterprise Linux 5 como huésped para-virtualizado
8.2. Instalación de Red Hat Enterprise Linux como un huésped completamente virtualizado
8.3. Instalación de Windows XP como huésped completamente virtualizado
8.4. Instalación de Windows Server 2003 como un huésped completamente virtualizado
8.5. Instalación de Windows Server 2008 como huésped totalmente virtualizado
III. Configuración
9. Virtualized storage devices
9.1. Cómo crear un controlador de disquete virtualizado
9.2. Cómo añadir dispositivos de almacenaje a huéspedes
9.3. Cómo configurar un almacenamiento persistente en Red Hat Enterprise Linux 5
9.4. Cómo añadir dispositivos CD-ROM o DVD a un huésped
10. Configuración de la red
10.1. Traducción de dirección de red (NAT) con libvirt
10.2. Creación de redes en puente con libvirt
11. Creación de redes Xen en Pre-Red Hat Enterprise Linux 5.4
11.1. Configuración de varios puentes de red huéspedes para usar varias tarjetas Ethernet
11.2. Configuración de redes de portátil de Red Hat Enterprise Linux 5.0
12. Controladores para-virtualizados Xen
12.1. Requerimientos del sistema
12.2. Restricciones y soporte de para-virtualización
12.3. Instalación de controladores para-virtualizados
12.3.1. Pasos comunes de instalación
12.3.2. Instalación y configuración de controladores para-virtualizados en Red Hat Enterprise Linux 3
12.3.3. Instalación y configuración de controladores para-virtualizados en Red Hat Enterprise Linux 4
12.3.4. Xen Para-virtualized Drivers on Red Hat Enterprise Linux 5
12.3.5. Xen Para-virtualized Drivers on Red Hat Enterprise Linux 6
12.4. Configuración de controlador para-virtualizado de redes
12.5. Configuración de hardware para-virtualizado adicional
12.5.1. Interfaces de red virtualizadas
12.5.2. Dispositivos de almacenamiento virtualizados
13. Controladores KVM para-virtualizados
13.1. Instalación de controladores KVM Windows para-virtualizados
13.2. Installing drivers with a virtualized floppy disk
13.3. Uso de controladores KVM para-virtualizados para dispositivos existentes
13.4. Uso de controladores KVM para-virtualizados para nuevos dispositivos
14. Paso de PCI
14.1. Adding a PCI device with virsh
14.2. Adding a PCI device with virt-manager
14.3. PCI passthrough with virt-install
14.4. PCI passthrough for para-virtualized Xen guests on Red Hat Enterprise Linux
15. SR-IOV
15.1. Introduction
15.2. Using SR-IOV
15.3. Troubleshooting SR-IOV
16. Administración del tiempo del huésped KVM
IV. Administración
17. Mejores prácticas de servidor
18. Seguridad para virtualización
18.1. Storage security issues
18.2. SELinux y virtualización completas
18.3. SELinux
18.4. Virtualization firewall information
19. Administración de huéspedes con xend
20. Migración Xen en vivo
20.1. Ejemplo de migración en vivo
20.2. Configurar la migración en vivo del huésped
21. Migración KVM en vivo
21.1. Requerimientos de migración en vivo
21.2. Ejemplo de almacenaje compartido: NFS para una migración sencilla
21.3. Migración KVM en vivo con virsh
21.4. Migración con virt-manager
22. Administración remota de huéspedes virtualizados
22.1. Administración remota con SSH
22.2. Administración remota en TLS y SSL
22.3. Modos de transporte
V. Virtualization Storage Topics
23. Using shared storage with virtual disk images
23.1. Using iSCSI for storing virtual disk images
23.1.1. How to set up an iSCSI target on Red Hat Enterprise Linux
23.1.2. How to configure iSCSI on a libvirt KVM host and provision a guest using virt-install
VI. Manual de referencia de virtualización
24. Herramientas de virtualización
25. Administración de huéspedes con virsh
26. Manejo de huéspedes con un Administrador de máquinas virtuales (virt-manager)
26.1. The Add Connection window
26.2. La ventana principal del Administrador de máquinas virtuales
26.3. The guest Overview tab
26.4. Consola gráfica de la Máquina virtual
26.5. Inicio de virt-manager
26.6. Restaurar una máquina guardada
26.7. Mostrar información de huéspedes
26.8. Estado de monitorización
26.9. Mostrar los identificadores de huésped
26.10. Displaying a guest's status
26.11. Mostrar las CPU virtuales
26.12. Mostrar uso de la CPU
26.13. Mostrar uso de memoria
26.14. Administración de una red virtual
26.15. Crear una nueva red virtual
27. El comando xm de referencia rápida
28. Configuración de parámetros de arranque de Xen
29. Configuración de ELILO
30. libvirt configuration reference
31. Archivos de configuración Xen
VII. Consejos y trucos
32. Consejos y trucos
32.1. Inicio automático de huéspedes
32.2. Cambio entre los hipervisores KVM y Xen
32.2.1. De Xen a KVM
32.2.2. De KVM a Xen
32.3. Uso de qemu-img
32.4. Overcommitting Resources
32.5. Modificar /etc/grub.conf
32.6. Verificar extensiones de virtualización
32.7. Accessing data from a guest disk image
32.8. Setting KVM processor affinities
32.9. Generar una nueva dirección MAC única
32.10. Limitar el ancho de banda de redes para un huésped de Xen
32.11. Configurar afinidades de procesador Xen
32.12. Modificar el hipervisor Xen
32.13. Very Secure ftpd
32.14. Configurar persistencia de LUN
32.15. Inhabilitar la monitorización de disco SMART para huéspedes
32.16. Limpiar archivos de configuración Xen anteriores
32.17. Configurar un servidor VNC
32.18. Clonar los archivos de configuración de huésped
32.19. Duplicar un huésped existente y su archivo de configuración
33. Creación de scripts libvirt personales
33.1. Uso de los archivos de configuración XML con virsh
VIII. Solución de problemas
34. Solución de problemas Xen
34.1. Depuración e identificación y resolución de problemas de Xen
34.2. Visión general de archivos de registro
34.3. Descripción del archivo de registro
34.4. Ubicación de directorios importantes
34.5. Detección y solución de problemas con registros
34.6. Detección y solución de problemas con la consola serial
34.7. Acceso de consola del huésped para-virtualizado
34.8. Acceso a la consola de huésped completamente virtualizado
34.9. Problemas comunes de Xen
34.10. Errores durante la creación de huéspedes
34.11. Detección y solución de problemas con consolas seriales
34.11.1. Salida de consola serial para Xen
34.11.2. Salida de consola serial de Xen de los huéspedes para-virtualizados
34.11.3. Salida de consola serial desde huéspedes completamente virtualizados
34.12. Archivos de configuración Xen
34.13. Interpretación de mensajes de error Xen
34.14. Presentación de los directorios de registro
35. Solución de problemas
35.1. Identificar almacenamiento disponible y particiones
35.2. Después de reiniciar los huéspedes basados en Xen la consola se congela
35.3. Los dispositivos Ethernet virtualizados no se encuentran mediante herramientas de red
35.4. Errores del dispositivo en bucle
35.5. Falló la creación de dominio por escasez de memoria
35.6. Wrong kernel image error
35.7. Wrong kernel image error - non-PAE kernel on a PAE platform
35.8. El huésped completamente virtualizado falla en el arranque
35.9. Una entrada de host local faltante hace que el virt-manager falle
35.10. Error de microcódigo durante el arranque de huésped.
35.11. Mensajes de advertencia de depreciación de Python al inicio de una máquina virtual
35.12. Habilitando las extensiones de virtualización de hardware Intel VT y AMD-V en BIOS
35.13. Rendimiento de redes KVM
36. Detección y solución de errores de los controladores de para-virtualización.
36.1. Directorios y archivo de registro de virtualización de Red Hat Enterprise Linux 5
36.2. Huésped para-virtualizado falla al cargar en un sistema operativo de huésped Red Hat Enterprise Linux 3
36.3. Se muestra un mensaje de advertencia durante la instalación de los controladores para-virtualizados en Red Hat Enterprise Linux 3
36.4. Cargar manualmente los controladores para- virtualizados
36.5. Verificación de los controladores para-virtualizados cargados correctamente
36.6. El sistema tiene rendimiento limitado con controladores para-virtualizados
Glossary
A. Recursos adicionales
A.1. Recursos en línea
A.2. Documentación instalada
B. Colofón

Prefacio

The Red Hat Enterprise Linux Virtualization Guide covers all aspects of using and managing virtualization products included with Red Hat Enterprise Linux.

1. Acerca de este libro

This book is divided into 8 parts:
  • Requerimientos del sistema
  • Instalación
  • Configuración
  • Administración
  • Storage
  • Referencia
  • Consejos y trucos
  • Solución de problemas
Key terms and concepts used throughout this book are covered in the Glossary.
This book covers virtualization topics for Red Hat Enterprise Linux 5. The KVM and Xen hypervisors are provided with Red Hat Enterprise Linux 5. Both the KVM and Xen hypervisors support Full virtualization. The Xen hypervisor also supports Para-virtualization. Refer to Sección 4, “What is Virtualization?” and the Glossary for more details on these terms.

2. Convenciones del Documento

Este manual utiliza varias convenciones para resaltar algunas palabras y frases y llamar la atención sobre ciertas partes específicas de información.
En ediciones PDF y de papel, este manual utiliza tipos de letra procedentes de Liberation Fonts. Liberation Fonts también se utilizan en ediciones de HTML si están instalados en su sistema. Si no, se muestran tipografías alternativas pero equivalentes. Nota: Red Hat Enterprise Linux 5 y siguientes incluyen Liberation Fonts predeterminadas.

2.1. Convenciones Tipográficas

Se utilizan cuatro convenciones tipográficas para llamar la atención sobre palabras o frases específicas. Dichas convenciones y las circunstancias en que se aplican son las siguientes:
Negrita monoespaciado
Utilizada para resaltar la entrada del sistema, incluyendo comandos de shell, nombres de archivo y rutas. También se utiliza para resaltar teclas claves y combinaciones de teclas. Por ejemplo:
Para ver el contenido del archivo my_next_bestselling_novel en su directorio actual de trabajo, escriba el comando cat my_next_bestselling_novel en el intérprete de comandos de shell y pulse Enter para ejecutar el comando.
El ejemplo anterior incluye un nombre de archivo, un comando de shell y una tecla clave. Todo se presenta en negrita-monoespaciado y distinguible gracias al contexto.
Las combinaciones de teclas se pueden distinguir de las teclas claves mediante el guión que conecta cada parte de una combinación de tecla. Por ejemplo:
Pulse Enter para ejecutar el comando.
Pulse Control+Alt+F2 para cambiar a la primera terminal virtual. Pulse Control+Alt+F1 para volver a su sesión de Ventanas-X.
La primera oración resalta la tecla clave determinada que se debe pulsar. La segunda resalta dos conjuntos de tres teclas claves que deben ser presionadas simultáneamente.
Si se discute el código fuente, los nombres de las clase, los métodos, las funciones, los nombres de variables y valores de retorno mencionados dentro de un párrafo serán presentados en Negrita-monoespaciado. Por ejemplo:
Las clases de archivo relacionadas incluyen filename para sistema de archivos, file para archivos y dir para directorios. Cada clase tiene su propio conjunto asociado de permisos.
Negrita proporcional
Esta denota palabras o frases encontradas en un sistema, incluyendo nombres de aplicación, texto de cuadro de diálogo, botones etiquetados, etiquetas de cajilla de verificación y botón de radio; títulos de menú y títulos del sub-menú. Por ejemplo:
Seleccionar SistemaPreferenciasRatón desde la barra del menú principal para lanzar Preferencias de Ratón. En la pestaña de Botones, haga clic en la cajilla ratón de mano izquierda y luego haga clic en Cerrar para cambiar el botón principal del ratón de la izquierda a la derecha (adecuando el ratón para la mano izquierda).
Para insertar un caracter especial en un archivo de gedit, seleccione desde la barra del menú principal AplicacionesAccessoriesMapa de caracteres. Luego, desde la barra de menúes de mapa de caracteres elija BúsquedaHallar…, teclee el nombre del caracter en el campo Búsqueda y haga clic en Siguiente. El caracter buscado se resaltará en la Tabla de caracteres. Haga doble clic en este caracter resaltado para colocarlo en el campo de Texto para copiar y luego haga clic en el botón de Copiar. Ahora regrese a su documento y elija EditarPegar desde la barra de menú de gedit.
El texto anterior incluye nombres de aplicación; nombres y elementos del menú de todo el sistema; nombres de menú de aplicaciones específicas y botones y texto hallados dentro de una interfaz gráfica de usuario, todos presentados en negrita proporcional y distinguibles por contexto.
Itálicas-negrita monoespaciado o Itálicas-negrita proporcional
Ya sea negrita monoespaciado o negrita proporcional, la adición de itálicas indica texto reemplazable o variable. Las itálicas denotan texto que usted no escribe literalmente o texto mostrado que cambia dependiendo de la circunstancia. Por ejemplo:
Para conectar a una máquina remota utilizando ssh, teclee ssh nombredeusuario@dominio.nombre en un intérprete de comandos de shell. Si la máquina remota es example.com y su nombre de usuario en esa máquina es john, teclee ssh john@example.com.
El comando mount -o remount file-system remonta el sistema de archivo llamado. Por ejemplo, para volver a montar el sistema de archivo /home, el comando es mount -o remount /home.
Para ver la versión de un paquete actualmente instalado, utilice el comando rpm -q paquete. Éste entregará el resultado siguiente: paquete-versión-lanzamiento.
Observe las palabras en itálicas y negrita sobre — nombre de usuario, domain.name, sistema de archivo, paquete, versión y lanzamiento. Cada palabra es un marcador de posición, tanto para el texto que usted escriba al ejecutar un comando como para el texto mostrado por el sistema.
Aparte del uso estándar para presentar el título de un trabajo, las itálicas denotan el primer uso de un término nuevo e importante. Por ejemplo:
Publican es un sistema de publicación de DocBook.

2.2. Convenciones del documento

Los mensajes de salida de la terminal o fragmentos de código fuente se distinguen visualmente del texto circundante.
Los mensajes de salida enviados a una terminal se muestran en romano monoespaciado y se presentan así:
books        Desktop   documentation  drafts  mss    photos   stuff  svn
books_tests  Desktop1  downloads      images  notes  scripts  svgs
Los listados de código fuente también se muestran en romano monoespaciado, pero se presentan y resaltan de la siguiente manera:
package org.jboss.book.jca.ex1;

import javax.naming.InitialContext;

public class ExClient
{
   public static void main(String args[]) 
       throws Exception
   {
      InitialContext iniCtx = new InitialContext();
      Object         ref    = iniCtx.lookup("EchoBean");
      EchoHome       home   = (EchoHome) ref;
      Echo           echo   = home.create();

      System.out.println("Created Echo");

      System.out.println("Echo.echo('Hello') = " + echo.echo("Hello"));
   }
}

2.3. Notas y Advertencias

Finalmente, utilizamos tres estilos visuales para llamar la atención sobre la información que de otro modo se podría pasar por alto.

Nota

Una nota es una sugerencia, atajo o enfoque alternativo para una tarea determinada. Ignorar una nota no debería tener consecuencias negativas, pero podría perderse de algunos trucos que pueden facilitarle las cosas.

Importante

Los cuadros con el título de importante dan detalles de cosas que se pueden pasar por alto fácilmente: cambios de configuración únicamente aplicables a la sesión actual, o servicios que necesitan reiniciarse antes de que se aplique una actualización. Ignorar estos cuadros no ocasionará pérdida de datos, pero puede causar enfado y frustración.

Advertencia

Las advertencias no deben ignorarse. Ignorarlas muy probablemente ocasionará pérdida de datos.

3. We need your feedback

If you find a typographical error in this manual, or if you have thought of a way to make this manual better, we would love to hear from you. Submit a report in Bugzilla: http://bugzilla.redhat.com/ against Red Hat Enterprise Linux with the Virtualization_Guide component.
When submitting a bug report, be sure to mention the manual's identifier: Virtualization_Guide and version number: 5.
If you have a suggestion for improving the documentation, try to be as specific as possible when describing it. If you have found an error, include the section number and some of the surrounding text so we can find it easily.

3.1. Technical review requests

All review requests are classified into one of the following five categories:
New content
content documented for the first time — an entirely new feature, procedure, or concept. For example: "Section now describes the new procedure for creating bootable USB devices."
Correction
a factual error previously present in the text has been corrected. For example: "Section previously stated (incorrectly) that IPv4 and IPv6 were both supported; section now states that IPv6 has never been supported."
Clarification
material that was already factually correct but is now better explained. Clarifications are usually in response to reader feedback that the previous content was confusing or misleading in some way. For example: "Paths described in Example 1.2.3 now better reflect the directory structure of an actual installed system."
Obsoletion
a description of a feature or a procedure has been dropped. Material might be obsolete because of a feature that is no longer supported, a known issue that has been corrected, or hardware that is now obsolete. For example, "Section no longer describes how to update kernel modules using a floppy disk."
Verification
a request to check a fact, procedure, or whether material should be obsoleted. For example, "Section describes how to connect to a generic iSCSI storage device. Please verify this on your hardware" or "Section still describes how to update kernel modules using a LS-120 SuperDisk; please verify that we still need to tell readers about this obsolete hardware."

4. What is Virtualization?

Virtualization is a broad computing term for running software, usually operating systems, concurrently and isolated from other programs on one system. Most existing implementations of virtualization use a hypervisor, a software layer that controls hardware and provides guest operating systems with access to underlying hardware devices. The hypervisor allows multiple operating systems to run on the same physical system by offering virtualized hardware to the guest operating system.

5. Types of Virtualization

5.1. Full Virtualization

Red Hat Enterprise Linux contains virtualization packages and tools which provide system administrators with the means to run fully virtualized, unmodified, operating system guests on Red Hat Enterprise Linux. This provides companies with the ability to consolidate older systems onto newer, more efficient hardware. This reduces physical space and operating costs involved with powering and cooling older, less efficient systems. Full virtualization incurs worse I/O performance than native, also known as bare-metal, installations of operating systems.

5.2. Para-Virtualization

Para-virtualization is a virtualization technique which involves running modified versions of operating systems. The para-virtualized operating system is modified to be aware that it is being virtualized, offering an increased ability for optimization as the guest is more aware of its environment. Performance is generally very close to running bare-metal, non-virtualized operating systems.

5.3. Para-virtualized drivers

These two techniques, para-virtualization and full virtualization, can be combined to allow unmodified operating systems to receive near native I/O performance by using para-virtualized drivers on fully virtualized operating systems. This guide covers installation and configuration of the Red Hat Enterprise Linux para-virtualized drivers package for fully virtualized Microsoft Windows® guests.
The para-virtualized drivers package contains storage and network device drivers for fully virtualized Microsoft Windows® guests. The drivers provide Microsoft Windows® guests running on Red Hat Enterprise Linux with enhanced disk and network I/O performance.

6. How CIOs should think about virtualization

by Lee Congdon, Chief Information Officer, Red Hat, Inc.
Puede haber invertido ya en una tecnología de virtualización que está emergiendo rápidamente. Si es así, considere algunas de las ideas a continuación para explotar mucho más esta tecnología.De lo contrario, es el momento preciso para comenzar.
La virtualización proporciona una serie de herramientas para aumentar la flexibilidad y disminuir costos, aspectos importantes en toda empresa y organización de tecnología informática. Las soluciones de virtualización están aumentando en disponibilidad y en funciones más productivas.
Puesto que la virtualización puede ofrecer beneficios significativos para su organización en muchas áreas, debería establecer pruebas, desarrollar conocimientos y poner a funcionar la tecnología de virtualización ahora.
Virtualización para innovar
En esencia, la virtualización aumenta la flexibilidad al disociar el sistema operativo y los servicios y aplicaciones soportados por ese sistema de la plataforma física de hardware. Permite establecer los entornos virtuales en una plataforma de hardware compartida.
Las organizaciones que buscan innovar consideran que esa habilidad para crear nuevos sistemas y servicios sin necesidad de instalar hardware adicional, (y rápidamente deshacerse de aquellos sistemas y servicios que ya no se necesiten) puede ser un gran impulso para la innovación.
Entre los posibles enfoques están el rápido establecimiento de sistemas para la creación de software personal, la habilidad de establecer rápidamente entornos de pruebas, la capacidad de ofrecer soluciones alternas y compararlas sin hacer grandes inversiones en hardware, el soporte para rápida creación de prototipos y entornos ágiles de desarrollo y la habilidad de establecer rápidamente nuevos servicios de producción a solicitud.
Estos entornos se pueden crear de modo interno o externo, como con el ofrecimiento EC2 de Amazon. Debido a que el costo para crear un nuevo entorno virtual puede ser muy bajo y se puede hacer uso del hardware existente, la creación puede facilitarse y acelerarse con una inversión mínima.
La virtualization también puede destacarse en la creación de soporte mediante el uso de entornos virtuales para entrenamiento y aprendizaje. Estos servicios son aplicaciones ideales para la tecnología de virtualización. Un estudiante puede comenzar el curso con un entorno de sistema estándar. El trabajo en clase puede estar aislado de la red de producción. Los estudiantes pueden establecer sus propios entornos de software sin exigir el uso exclusivo de recursos de hardware
Como las capacidades de los entornos virtuales continúan aumentando, es muy probable ver en aumento el uso de la virtualización para habilitar entornos portátiles adaptados a las necesidades específicas del usuario. Estos entornos pueden ser desplazados dinámicamente a un entorno local o accesible, sin importar dónde esté localizado el usuario. Los entornos virtuales de usuario pueden ser almacenados en la red o llevados en un dispositivo de memoria portátil.
Un concepto relacionado es el Sistema operativo Appliance, un paquete de aplicaciones orientadas al sistema operativo diseñadas para ser ejecutadas en un entorno virtual. El enfoque del paquete puede generar costos de desarrollo y soporte más bajos, como también garantizar que la aplicación se ejecute en un entorno conocido y seguro. Una solución de Sistema operativo de aplicación brinda beneficios tanto para los desarrolladores de la aplicación como para sus consumidores.
La forma como estas aplicaciones de tecnología de virtualización se aplican en la empresa varía. Si ya está utilizando tecnología en más de una de las áreas anotadas anteriormente, considere una inversión adicional en una solución que requiera un desarrollo rápido. Si no ha comenzado con virtualización, inicie con una implementación de entrenamiento y aprendizaje para desarrollar destrezas, luego prosiga al desarrollo de aplicaciones y prueba. Las empresas con una experiencia más amplia en virtualización deberían considerar implementar entornos virtuales portátiles o dispositivos de aplicaciones
Virtualización para ahorrar costos
La virtualización también se puede utilizar para disminuir costos. Un beneficio obvio surge de la consolidación de servidores en una serie más pequeña de plataformas de hardware más potentes ejecutando una serie de entornos virtuales. No solamente se pueden reducir costos al reducir la cantidad de hardware y de opciones no utilizadas, sino el rendimiento de la aplicación puede mejorar, puesto que los huéspedes virtuales se ejecutan en más de un hardware potente.
Otros beneficios incluyen la habilidad de añadir hardware sin interrupciones y migrar de forma dinámica las cargas de trabajos a recursos disponibles.
Dependiendo de las necesidades de su organización, puede ser posible crear un entorno virtual para recuperación ante desastres. La introducción de virtualización puede reducir significativamente la necesidad de replicar entornos de hardware y permitir pruebas de escenarios de desastres, a bajo costo.
La virtualización ofrece una excelente solución para enfrentar las temporadas pico o altas de cargas de trabajo. Si tiene cargas de trabajo complementarias en su organización, puede asignar dinámicamente recursos a las aplicaciones que están experimentando mayor demanda. Si usted tiene temporadas de trabajo altas que actualmente está supliendo dentro de su organización, puede comprar una capacidad externa e implementarla eficientemente mediante la tecnología virtual.
El ahorro en costos de la consolidación del servidor puede ser atractivo. Si no está explotando la virtualización para ello, debería iniciar un programa ahora. Mientras gana experiencia con la virtualización, explore los beneficios de equilibrar la carga de trabajo y los entornos virtualizados de recuperación ante desastres.
La virtualization como una solución estándar
A pesar de las necesidades específicas de su empresa, usted debería estar investigando la virtualización como parte de su sistema y portafolio de aplicación ya que la tecnología es muy probable que se convierta en permeable. Esperamos que los proveedores de sistemas operativos incluyan virtualización como un componente estándar, los proveedores de hardware creen capacidades virtuales en sus plataformas y los proveedores de virtualización amplíen el alcance de sus ofertas.
Si usted no tiene planes para incorporar la virtualización en su arquitectura de solución, ahora es el momento de identificar un proyecto piloto, asignar algunas plataformas de hardware sub-utilizadas y desarrollar una tecnología eficiente en costos y flexible. Luego, extienda sus arquitecturas objetivo para incorporar soluciones virtuales. Aunque hay beneficios substanciales disponibles desde los servicios existentes virtuales, crear nuevas aplicaciones con una estrategia de virtualización integrada puede generar otros beneficios administrativos y de disponibilidad.
Puede aprender más acerca de soluciones de virtualización de Red Hat en http://www.redhat.com/products/

Parte I. Requerimientos y limitaciones para virtualización con Red Hat Enterprise Linux

Requerimientos del sistema, restricciones de soporte y limitaciones

Estos capítulos presentan los requerimientos del sistema, las restricciones de soporte y limitaciones de virtualización en Red Hat Enterprise Linux.

Capítulo 1. Requerimientos del sistema

This chapter lists system requirements for successfully running virtualization with Red Hat Enterprise Linux. Virtualization is available for Red Hat Enterprise Linux 5 Server.
The requirements for virtualization vary depending on the type of hypervisor. The Kernel-based Virtual Machine (KVM) and Xen hypervisors are provided with Red Hat Enterprise Linux 5. Both the KVM and Xen hypervisors support Full virtualization. The Xen hypervisor also supports Para-virtualization.
For information on installing the virtualization packages, read Capítulo 6, Instalación de paquetes de virtualización.
Requerimientos mínimos del sistema
  • 6GB de espacio de disco libre
  • 2GB de RAM

Sobre envío de KVM

KVM can overcommit physical resources for virtualized guests. Overcommiting resources means the total virtualized RAM and processor cores used by the guests can exceed the physical RAM and processor cores on the host. For information on safely overcommitting resources with KVM refer to Sección 32.4, “Overcommitting Resources”.
Requerimientos de para-virtualización de Xen
Los huéspedes para-virtualizados requieren un árbol de instalación de Red Hat Enterprise Linux 5 disponible en la red mediante los protocolos NFS, FTP o HTTP.
Requerimientos de virtualización completa de Xen
La virtualización completa con el hipervisor Xen requiere:
  • an Intel processor with the Intel VT extensions, or
  • Un procesador AMD con las extensiones AMD-V o
  • Un procesador Intel Itanium.
Refer to Sección 32.6, “Verificar extensiones de virtualización” to determine if your processor has the virtualization extensions.
Requerimientos de KVM
El hipervisor KVM requiere:
  • Un procesador Intel con las extensiones Intel VT e Intel 64 o
  • Un procesador de AMD con extensiones AMD-V y AMD64.
Refer to Sección 32.6, “Verificar extensiones de virtualización” to determine if your processor has the virtualization extensions.
Soporte de almacenaje
Los métodos de almacenaje de huéspedes compatibles son:
  • Files on local storage
  • Physical disk partitions
  • Locally connected physical LUNs
  • LVM partitions
  • iSCSI and Fibre Channel based LUNs

Almacenaje de huésped basado en archivo

File-based guest images are stored in the /var/lib/libvirt/images/ directory by default. If you use a different directory you must label the new directory according to SELinux policy. Refer to Sección 18.2, “SELinux y virtualización completas” for details.

Capítulo 2. Restricciones y soporte de Xen

Red Hat Enterprise Linux 5 supports various architecture combinations for hosts and virtualized guests. All architectures have processor and memory limitations. Refer to the following URLs for the processor and memory amount limitations for Red Hat Enterprise Linux:
The following URL shows a complete chart of supported operating systems and host and guest combinations:

Nota

To utilize para-virtualization on Red Hat Enterprise Linux 5, your processor must have the Physical Address Extension (PAE) instruction set.

Soporte Itanium®

Virtualization with the Xen hypervisor on the Intel Itanium architecture requires the guest firmware image package, refer to Instalación del hipervisor de Xen con yum for more information.

Capítulo 3. Restricciones de KVM y soporte

The KVM hypervisor requires a processor with the Intel-VT or AMD-V virtualization extensions.
To verify whether your processor supports the virtualization extensions and for information on enabling the virtualization extensions if they are disabled, refer to Sección 32.6, “Verificar extensiones de virtualización”.
The following URLs explain the processor and memory amount limitations for Red Hat Enterprise Linux:
The following URL shows a complete chart of supported operating systems and host and guest combinations:

Capítulo 4. Hyper-V restrictions and support

Certification of guests running under the Microsoft Hyper-V server is conducted by Microsoft. Red Hat Enterprise Linux 5 is fully certified to run under the Microsoft Hyper-V server.

Nota

To avoid timing errors when running Red Hat Enterprise Linux 5 under the Microsoft Hyper-V server, use the divider=10 option in the grub.conf file.

Capítulo 5. Limitaciones de virtualización

Este capítulo cubre las limitaciones adicionales de los paquetes de virtualización en Red Hat Enterprise Linux.

5.1. Limitaciones generales para virtualización

Converting between hypervisors
Presently, there is no support for converting Xen-based guests to KVM or KVM-based guests to Xen. Guests can only be supported on the hypervisor type on which they were created. However, at the time of writing, a tool is in development which may be released with future versions of Red Hat Enterprise Linux.
Otras limitaciones
For other details affecting virtualization, refer to the Red Hat Enterprise Linux Release Notes at http://docs.redhat.com for your version. The Release Notes cover the present new features, known issues and limitations as they are updated or discovered.
Lanzamiento antes de prueba
You should test for the maximum anticipated system and virtualized network load before deploying heavy I/O applications. Load testing and planning are important as virtualization performance can suffer due to high I/O usage.

5.2. Limitaciones de KVM

Las siguientes limitaciones se aplican al hipervisor de KVM:
Bit TSC constante
Systems without a Constant Time Stamp Counter require additional configuration. Refer to Capítulo 16, Administración del tiempo del huésped KVM for details on determining whether you have a Constant Time Stamp Counter and configuration steps for fixing any related issues.
Sobrecompromiso de memoria
KVM supports memory overcommit and can store the memory of guests in swap. A guest will run slower if it is swapped frequently. When Kernel SamePage Merging (KSM) is used, make sure that the swap size is equivalent to the size of the overcommit ratio.
Sobrecompromiso de CPU
No se soportan más de 10 CPU virtuales por núcleo de procesador físico. Cualquier cantidad de CPU virtuales sobrecomprometidas, superior al número de núcleos de procesador físicos, puede ocasionar problemas con algunos huéspedes virtualizados.
Overcommitting CPUs has some risk and can lead to instability. Refer to Sección 32.4, “Overcommitting Resources” for tips and recommendations on overcommitting CPUs.
Dispositivos virtualizados SCSI
SCSI emulation is presently not supported. Virtualized SCSI devices are disabled in KVM.
Dispositivos IDE virtualizados
KVM está limitado a un máximo de cuatro dispositivos IDE (emulados) por huésped.
Controladores para-virtualizados
Los dispositivos para-virtualizados, los cuales usan los controladores virtio, son dispositivos de PCI. Actualmente, los huéspedes están limitados a un máximo de 32 dispositivos de PCI. Algunos dispositivos de PCI son importantes para que el huésped se ejecute y estos dispositivos no pueden removerse. Los dispositivos predeterminados requeridos son:
  • el puente de host,
  • el puente de ISA y el puente de USB (Los puentes de USB e ISA son el mismo dispositivo),
  • la tarjeta gráfica (usando el controlador Cirrus o qxl) y
  • el dispositivo de memoria de globo
Cuatro de los 32 dispositivos de PCI disponibles, no se pueden quitar. Esto significa que hay sólo 28 ranuras de PCI disponibles para dispositivos adicionales por huésped. Cada red para-virtualizada o dispositivo de bloque utiliza una ranura. Cada huésped puede usar hasta 28 dispositivos adicionales compuestos por una combinación de redes para-virtualizadas, dispositivos de disco para-virtualizados u otros dispositivos de PCI que utilicen VTd.
Limitaciones de migración
La migración en vivo sólo es posible con las CPU del mismo proveedor (es decir, de Intel a Intel o de AMD a AMD únicamente).
Para una migración en vivo, el bit de No eXecution (NX) debe estar encendido (on) o apagado (off) para ambas CPU.
Storage limitations
The host should not use disk labels to identify file systems in the fstab file, the initrd file or used by the kernel command line. If less privileged users, especially virtualized guests, have write access to whole partitions or LVM volumes the host system could be compromised.
Guests should not be given write access to whole disks or block devices (for example, /dev/sdb). Virtualized guests with access to block devices may be able to access other block devices on the system or modify volume labels which can be used to compromise the host system. Use partitions (for example, /dev/sdb1) or LVM volumes to prevent this issue.

5.3. Limitaciones de Xen

Nota

All limitations in this chapter are limitations for Red Hat Enterprise Linux 5.8 except where noted. Older versions may have fewer limitations.
Limitaciones de host de Xen (dom0)
  • A limit of 254 para-virtualized block devices per host. The total number of block devices (using the tap:aio driver) attached to virtualized guests cannot exceed 254 devices.

Operando cerca del límite de dispositivo para-virtualizado

There are two methods for working around the para-virtualized device limit: using phy devices (devices using the physical access mode) or using LVM on the guest.
El host no tiene límites de número de dispositivos phy, si tiene recursos suficientes.
LVM o una herramienta de particionamiento similar, puede utilizarse en un dispositivo de bloque para crear particiones lógicas adicionales en un dispositivo de bloque para-virtualizado único.
Limitaciones de para-virtualización Xen
  • For x86 guests, a maximum of 16GB memory per guest.
  • For x86_64 guests, a maximum of 168GB memory per guest.
  • A maximum of 254 devices per virtualized guest.
  • Un máximo de 15 dispositivos de red por huésped virtualizado.
Limitaciones de virtualización Xen completa
  • For x86 guests, a maximum of 16GB memory per guest.
  • Un máximo de cuatro dispositivos IDE (emulados ) por huésped.
    Los dispositivos que utilizan controladores para-virtualizados para huéspedes complemente virtualizados no tienen esta limitación.
  • Virtualized (emulated) IDE devices are limited by the total number of loopback devices supported by the system. The default number of available loopback devices on Red Hat Enterprise Linux 5.8 is 8. That is, by default, all virtualized guests on the system can each have no more than 8 virtualized (emulated) IDE devices.
    For more information on loopback devices, refer to the Red Hat KnowledgeBase, article DOC-1722.

    Usando más de 8 dispositivos de loopback

    Por defecto, Red Hat Enterprise Linux limita el número de dispositivos de loopback disponibles. Puede aumentar este número modificando el límite de kernel.
    En /etc/modprobe.conf añada la siguiente línea:
    options loop max_loop=64
    
    Reboot the machine or run the following commands to update the kernel with this new limit:
    # rmmod loop
    # modprobe loop
    
  • A limit of 254 para-virtualized block devices per host. The total number of block devices (using the tap:aio driver) attached to virtualized guests cannot exceed 254 devices.
  • A maximum of 254 block devices using the para-virtualized drivers per virtualized guest.
  • Un máximo de 15 dispositivos de red por huésped virtualizado.
  • Un máximo de 15 dispositivos virtualizados SCSI por huésped virtualizado.
PCI passthrough limitations
  • PCI passthrough (attaching PCI devices to guests) is presently only supported on the following architectures:
    • 32 bit (x86) systems.
    • Intel 64 systems.
    • Intel Itanium 2 systems.

5.4. Limitaciones de aplicación

Hay aspectos de virtualización que pueden hacer la virtualización no apta para algunos tipos de aplicaciones.
La aplicaciones con requerimientos de rendimiento de E/S, deben utilizar los controladores para-virtualizados para huéspedes completamente virtualizados. Sin los controladores para-virtualizados algunas aplicaciones pueden ser inestables bajo cargas pesadas de E/S.
Las aplicaciones siguientes deben evitarse por sus amplias razones de requerimientos de E/S:
  • servidor kdump
  • servidor netdump
You should carefully evaluate database applications before running them on a virtualized guest. Databases generally use network and storage I/O devices intensively. These applications may not be suitable for a fully virtualized environment. Consider para-virtualization or para-virtualized drivers in these cases for increased I/O performance.
Other applications and tools which heavily utilize I/O or require real-time performance should be evaluated carefully. Using full virtualization with the para-virtualized drivers or para-virtualization results in better performance with I/O intensive applications. Applications still suffer a small performance loss from running in virtualized environments. The performance benefits of virtualization through consolidating to newer and faster hardware should be evaluated against the potential application performance issues associated with using fully virtualized hardware.

Parte II. Instalación

Capítulo 6. Instalación de paquetes de virtualización

Antes de poder utilizar virtualización, los paquetes de virtualización deben estar instalados en Red Hat Enterprise Linux. Los paquetes de virtualización pueden ser instalados ya sea durante la secuencia de instalación o después de la instalación mediante el comando yum y Red Hat Network (RHN).
Puede instalar los hipervisores KVM y Xen en un solo sistema. El hipervisor Xen utiliza el paquete kernel-xen y el hipervisor KVM, utiliza el kernel predeterminado de Red Hat Enterprise Linux con el módulo de kernel kvm. Xen y KVM utilizan cada uno un hipervisor diferente y sólo un hipervisor puede estar activo en un momento determinado. Red Hat recomienda utilizar únicamente un hipervisor, el hipervisor que se desea para virtualización.
To change hypervisor from Xen to KVM or KVM to Xen refer to Sección 32.2, “Cambio entre los hipervisores KVM y Xen”.

6.1. Instalación Xen con una instalación de Red Hat Enterprise Linux 5

Esta sección presenta las herramientas de instalación de virtualización y los paquetes Xen como parte de una nueva instalación de Red Hat Enterprise Linux.

¿Necesita ayuda en la instalación?

The Installation Guide (available from redhat.com) covers installing Red Hat Enterprise Linux in detail.
  1. Inicie una instalación interactiva de Red Hat Enterprise Linux desde el CD-ROM, DVD o PXE de instalación de Red Hat Enterprise Linux Installation.
  2. You must enter a valid installation number when prompted to receive access to the virtualization and other Advanced Platform packages. Installation numbers can be obtained from Red Hat Customer Service.
  3. Complete all steps until you see the package selection step.
    Seleccione el grupo del paquete Virtualización y el botón Personalizar ahora.
  4. Seleccione el grupo del paquete KVM. Desactive el grupo del paquete Virtualización. Éste selecciona el hipervisor KVM, virt-manager, libvirt y virt-viewer para instalación.
  5. Personalizar los paquetes (si se requiere)

    Personalizar el grupo de Virtualización si requiere otros paquetes de virtualización.
    Press the Close button then the Forward button to continue the installation.

Nota

Se requiere un derecho válido de virtualización de RHN para poder recibir actualizaciones de los paquetes de virtualización.
Instalación de paquetes Xen con archivos Kickstart
Esta sección describe cómo utilizar un archivo Kickstart para instalar Red Hat Enterprise sin los paquetes de hipervisor. Los archivos de Kickstart permiten grandes instalaciones automatizados sin necesidad de instalar manualmente a un usuario en cada sistema. Los pasos en esta sección le ayudarán a crear y utilizar un archivo Kickstart para instalar Red Hat Enterprise Linux con los paquetes de virtualización.
En la sección %packages de su archivo Kickstart, añada el siguiente grupo de paquetes:
%packages
@xen

Para sistemas Intel Itanium

Fully virtualized guests on the Itanium® architecture require the guest firmware image package (xen-ia64-guest-firmware). Append the following package to your kickstart file:
xen-ia64-guest-firmware
More information on Kickstart files can be found on Red Hat's website, redhat.com, in the Installation Guide.

6.2. Instalación de paquetes Xen en un sistema de Red Hat Linux existente

La sección describe los pasos necesarios para instalar los paquetes de virtualización en un sistema en ejecución de Red Hat Enterprise Linux.
Adición de paquetes a su lista de derechos de red Hat Network.
Esta sección describe cómo habilitar los derechos de Red Hat Network (RHN) para los paquetes de virtualización. Es necesario tener estos derechos habilitados para poder instalar o actualizar los paquetes de virtualización en Red Hat Enterprise Linux. Se requiere una cuenta válida de Red Hat Network para instalar paquetes de virtualización en Red Hat Enterprise Linux.
Además, sus máquinas deben estar registradas con RHN. Para registrar una instalación de Red Hat Enterprise Linux, ejecute el comando rhn_register command y siga las siguientes indicaciones.
Si no tiene una suscripción válida de Red Hat, visite Red Hat online store.
Procedimiento 6.1. Adición de derechos de virtualización con RHN
  1. Ingrese a RHN mediante su nombre de usuario y contraseña de RHN.
  2. Seleccione los sistemas en los que desea instalar virtualización.
  3. En la sección Propiedades de sistema los derechos de sistemas están listados cerca del encabezamiento Derechos. Utilice el enlace (Editar estas propiedades) para cambiar sus derechos.
  4. Seleccione la cajilla de verificación de Virtualización.
Su sistema ahora puede recibir los paquetes de virtualización. La próxima sección cubre la instalación de estos paquetes.
Instalación del hipervisor de Xen con yum
Para usar virtualización en Red Hat Enterprise Linux se necesitan los paquetes xen y kernel-xen. El paquete xen contiene el hipervisor y las herramientas básicas de virtualización. El paquete kernel-xen contiene un kernel de Linux modificado que se ejecuta como un huésped de máquina virtual en el hipervisor.
Para instalar los paquetes xen y kernel-xen, ejecute:
# yum install xen kernel-xen
Los huéspedes virtualizados en la arquitectura Itanium® requieren el paquete de imagen de huésped (xen-ia64-guest-firmware) desde la instalación de DVD complementaria. Este paquete también se puede instalar desde RHN con el comando yum:
# yum install xen-ia64-guest-firmware
It is advised to install additional virtualization packages for management and configuration. Paquetes de virtualización recomendados: lists the recommended packages.
Instale los otros paquetes de virtualización recomendados:
# yum install virt-manager libvirt libvirt-python python-virtinst

6.3. Instalación de KVM con una nueva instalación de Red Hat Enterprise Linux

Esta sección cubre las herramientas de instalación y el paquete KVM como parte de una nueva instalación de Red Hat Enterprise Linux.

¿Necesita ayuda en la instalación?

The Installation Guide (available from redhat.com) covers installing Red Hat Enterprise Linux in detail.

Necesita un número de instalación válido

No puede seleccionar los paquetes de virtualización durante la instalación sin un número válido de instalación.
  1. Inicie una instalación interactiva de Red Hat Enterprise Linux desde el CD-ROM, DVD o PXE de instalación de Red Hat Enterprise Linux Installation.
  2. Debe entrar un número de instalación válido cuando se le indique para tener acceso a los paquetes de virtualización y a otros paquetes de plataforma avanzada.
  3. Complete all steps up to the package selection step.
    Seleccione el grupo del paquete Virtualización y el botón Personalizar ahora.
  4. Seleccione el grupo de paquete KVM. Desactive el grupo de paquete Virtualización. Éste selecciona el hipervisor KVM, virt-manager, libvirt y virt-viewer para instalación.
  5. Personalizar los paquetes (si se requiere)

    Personalizar el grupo de Virtualización si requiere otros paquetes de virtualización.
    Press the Close button then the Forward button to continue the installation.

Nota

Se requiere un derecho válido de virtualización de RHN para poder recibir actualizaciones de los paquetes de virtualización.
Instalación de paquetes KVM con archivos Kickstart
Esta sección describe cómo utilizar un archivo Kickstart para instalar Red Hat Enterprise Linux con los paquetes de hipervisor KVM. Los archivos Kickstart permiten grandes instalaciones automatizadas sin instalación manual de parte del usuario de cada sistema. Los pasos en esta sección le ayudarán en la creación y uso de un archivo Kickstart para instalar Red Hat Enterprise Linux con los paquetes de virtualización.
En la sección %packages de su archivo Kickstart, añada el siguiente grupo de paquetes:
%packages
@kvm
More information on Kickstart files can be found on Red Hat's website, redhat.com, in the Installation Guide.

6.4. Instalación de paquetes KVM en un sistema existente de Red Hat Enterprise Linux

Esta sección describe los pasos para instalar el hipervisor KVM en un sistema funcionando en Red Hat Enterprise Linux 5.4 o más reciente.
Adición de paquetes a su lista de derechos de red Hat Network.
Esta sección describe cómo habilitar los derechos de Red Hat Network (RHN) para los paquetes de virtualización. Es necesario tener estos derechos habilitados para poder instalar o actualizar los paquetes de virtualización en Red Hat Enterprise Linux. Se requiere una cuenta válida de Red Hat Network para instalar paquetes de virtualización en Red Hat Enterprise Linux.
Además, sus máquinas deben estar registradas con RHN. Para registrar una instalación de Red Hat Enterprise Linux, ejecute el comando rhn_register command y siga las siguientes indicaciones.
Si no tiene una suscripción válida de Red Hat, visite Red Hat online store.
Procedimiento 6.2. Adición de derechos de virtualización con RHN
  1. Ingrese a RHN mediante su nombre de usuario y contraseña de RHN.
  2. Seleccione los sistemas en los que desea instalar virtualización.
  3. En la sección Propiedades de sistema los derechos de sistemas están listados cerca del encabezamiento Derechos. Utilice el enlace (Editar estas propiedades) para cambiar sus derechos.
  4. Seleccione la cajilla de verificación de Virtualización.
Su sistema ahora puede recibir los paquetes de virtualización. La próxima sección cubre la instalación de estos paquetes.
Instalación del hipervisor KVM con yum
Para utilizar virtualización en Red Hat Enterprise Linux se requiere el paquete kvm. El paquete kvm contiene el módulo de kernel de KVM que proporciona el hipervisor KVM en el kernel predeterminado de Red Hat Enterprise Linux .
Para instalar el paquete kvm, ejecute:
# yum install kvm
Ahora, instale los paquetes adicionales de administración de virtualización.
Instale los otros paquetes de virtualización recomendados:
# yum install virt-manager libvirt libvirt-python python-virtinst

Capítulo 7. Visión general de la tecnología de virtualización

Después de haber instalado los paquetes de virtualización en el sistema de host, puede crear sistemas operativos de huésped. Este capítulo describe los procesos generales para la instalación de sistemas operativos de huésped en máquinas virtuales. Puede crear huéspedes con el botón Nuevo en virt-manager o utilizar la interfaz de línea de virt-install. Ambos métodos están descritos en este capítulo.
Detailed installation instructions are available for specific versions of Red Hat Enterprise Linux, other Linux distributions and Windows. Refer to Capítulo 8, Procedimiento de instalación de sistema operativo de huésped for those procedures.

7.1. Creación de huéspedes con virt-install

Puede utilizar virt-install para crear huéspedes virtualizados desde la línea de comando. virt-install, ya sea de forma interactiva o como parte de un script para automatizar la creación de las máquinas virtuales. El uso de virt-install con archivos Kickstart files permite una instalación de máquinas virtuales sin supervisión.
La herramienta virt-install proporciona un número de opciones que se pueden pasar a la línea de comandos. Para ver una lista completa de opciones ejecute:
$ virt-install --help
La página man virt-install también documenta cada opción de comando y variables importantes.
El comando qemu-img es un comando que puede utilizarse antes de virt-install para configurar opciones de almacenaje.
An important option is the --vnc option which opens a graphical window for the guest's installation.
Ejemplo 7.1. Uso de virt-install con KVM para crear un huésped de Red Hat Enterprise Linux 3
Este ejemplo crea un huésped de Red Hat Enterprise Linux 3, llamado rhel3support, desde un CD-ROM, con redes virtuales y con un archivo de 5GB basado en imagen de dispositivo de bloque. Este ejemplo utiliza el hipervisor de KVM.
# virt-install --accelerate --hvm --connect qemu:///system \
   --network network:default \
   --name rhel3support --ram=756\
   --file=/var/lib/libvirt/images/rhel3support.img \
   --file-size=6 --vnc --cdrom=/dev/sr0

Ejemplo 7.2. Uso de virt-install para crear un huésped de Fedora 11
# virt-install --name fedora11 --ram 512 --file=/var/lib/libvirt/images/fedora11.img \
	--file-size=3 --vnc --cdrom=/var/lib/libvirt/images/fedora11.iso

7.2. Creación de huéspedes con virt-manager

virt-manager, también conocido como un Administrador de máquina virtual es una herramienta gráfica para crear y administrar los huéspedes virtualizados.
Procedimiento 7.1. Creación de un huésped virtualizado con virt-manager
  1. Open virt-manager

    Start virt-manager. Launch the Virtual Machine Manager application from the Applications menu and System Tools submenu. Alternatively, run the virt-manager command as root.
  2. Optional: Open a remote hypervisor

    Open the File -> Add Connection. The dialog box below appears. Select a hypervisor and click the Connect button:
  3. Create a new guest

    La ventana virt-manager le permite crear una nueva máquina virtual. Haga clic en el botón Nuevo para crear un nuevo huésped. De esta manera se abre el asistente como se muestra en la instantánea.
  4. New guest wizard

    The Create a new virtual machine window provides a summary of the information you must provide in order to create a virtual machine:
    Revise la información para su instalación y haga clic en el botón Adelante.
  5. Name the virtual machine

    Provide a name for your virtualized guest. Punctuation and whitespace characters are not permitted in versions before Red Hat Enterprise Linux 5.5. Red Hat Enterprise Linux 5.5 adds support for '_', '.' and '-' characters.
    Press Forward to continue.
  6. Choose virtualization method

    La ventana Seleccionar un método de virtualización aparece. Elija entre para-virtualizado o Completamente virtualizado.
    La virtualización completa requiere un sistema con procesador Intel® VT or AMD-V. Si las extensiones de virtualización no están presentes el botón de opción Completamente virtualizado o Habilitar aceleración de kernel/hardware no podrá ser seleccionado. La opción para-virtualizado estará inhabilitada si kernel-xen no es el kernel que se está ejecutando en este momento.
    Si está conectado al hipervisor de KVM sólo la virtualización completa está disponible.
    Choose the virtualization type and click the Forward button.
  7. Select the installation method

    The Installation Method window asks for the type of installation you selected.
    Guests can be installed using one of the following methods:
    Local media installation
    This method uses a CD-ROM or DVD or an image of an installation CD-ROM or DVD (an .iso file).
    Network installation tree
    This method uses a mirrored Red Hat Enterprise Linux installation tree to install guests. The installation tree must be accessible using one of the following network protocols: HTTP, FTP or NFS.
    The network services and files can be hosted using network services on the host or another mirror.
    Network boot
    This method uses a Preboot eXecution Environment (PXE) server to install the guest. Setting up a PXE server is covered in the Red Hat Enterprise Linux Deployment Guide. Using this method requires a guest with a routable IP address or shared network device. Refer to Capítulo 10, Configuración de la red for information on the required networking configuration for PXE installation.
    Set the OS type and OS variant.
    Choose the installation method and click Forward to proceed.

    Para-virtualized guest installation

    Para-virtualized installation must be installed with a network installation tree. The installation tree must be accessible using one of the following network protocols: HTTP, FTP or NFS. The installation media URL must contain a Red Hat Enterprise Linux installation tree. This tree is hosted using NFS, FTP or HTTP.
  8. Installation media selection

    This window is dependent on what was selected in the previous step.
    1. ISO image or physical media installation

      If Local install media was selected in the previous step this screen is called Install Media.
      Select the location of an ISO image or select a DVD or CD-ROM from the dropdown list.
      Click the Forward button to proceed.
    2. Network install tree installation

      If Network install tree was selected in the previous step this screen is called Installation Source.
      Network installation requires the address of a mirror of a Linux installation tree using NFS, FTP or HTTP. Optionally, a kickstart file can be specified to automated the installation. Kernel parameters can also be specified if required.
      Click the Forward button to proceed.
    3. Network boot (PXE)

      PXE installation does not have an additional step.
  9. Storage setup

    The Storage window displays. Choose a disk partition, LUN or create a file-based image for the guest storage.
    All image files are stored in the /var/lib/libvirt/images/ directory by default. In the default configuration, other directory locations for file-based images are prohibited by SELinux. If you use a different directory you must label the new directory according to SELinux policy. Refer to Sección 18.2, “SELinux y virtualización completas” for details.
    Your guest storage image should be larger than the size of the installation, any additional packages and applications, and the size of the guests swap file. The installation process will choose the size of the guest's swap based on size of the RAM allocated to the guest.
    Asigne espacio adicional si el huésped necesita más espacio para aplicaciones o datos. Por ejemplo, los servidores de Web requieren espacio adicional para archivos de registro.
    Introduzca un tamaño apropiado para el huésped en su tipo de almacenaje y haga clic en el botón Adelante.

    Nota

    It is recommend that you use the default directory for virtual machine images, /var/lib/libvirt/images/. If you are using a different location (such as /images/ in this example) make sure it is added to your SELinux policy and relabeled before you continue with the installation (later in the document you will find information on how to modify your SELinux policy).
  10. Network setup

    Select either Virtual network or Shared physical device.
    The virtual network option uses Network Address Translation (NAT) to share the default network device with the virtualized guest. Use the virtual network option for wireless networks.
    The shared physical device option uses a network bond to give the virtualized guest full access to a network device.
    Press Forward to continue.
  11. Memory and CPU allocation

    The Memory and CPU Allocation window displays. Choose appropriate values for the virtualized CPUs and RAM allocation. These values affect the host's and guest's performance.
    Los huéspedes requieren suficiente memoria física (RAM) para ejecutarse de modo eficiente y efectivo. Elija el valor de memoria que se ajuste a su sistema operativo de huésped y a los requerimientos de aplicación. La mayoría de los sistemas operativos requieren al menos 512MB de RAM para funcionar con receptividad. Recuerde que los huéspedes utilizan RAM física. La ejecución de muchos huéspedes o dejar memoria insuficiente para el sistema de host, resulta en un uso importante de memoria virtual. La memoria virtual es bastante lenta lo que produce un rendimiento de sistema y receptividad degradados. Asegúrese de asignar memoria suficiente a todos los huéspedes y al host para que funcionen de modo efectivo.
    Asigne suficientes CPU virtuales para huésped virtualizado. Si el huésped ejecuta una aplicación multi-hilos, asigne el número de CPU virtualizadas que éste requiera para ejecutar de un modo eficiente. No asigne más CPU virtuales que las de los procesadores físicos (o hiper-hilos) disponibles en el sistema de host. Es posible sobre asignar procesadores virtuales, no obstante, la sobre asignación tiene un efecto negativo en el rendimiento del huésped y host debido a las sobrecargas de conmutación de contexto del procesador.
    Press Forward to continue.
  12. Verify and start guest installation

    The Finish Virtual Machine Creation window presents a summary of all configuration information you entered. Review the information presented and use the Back button to make changes, if necessary. Once you are satisfied click the Finish button and to start the installation process.
    Una ventana VNC se abre para mostrar el inicio del proceso de instalación del sistema operativo de huésped.
This concludes the general process for creating guests with virt-manager. Capítulo 8, Procedimiento de instalación de sistema operativo de huésped contains step-by-step instructions to installing a variety of common operating systems.

7.3. Instalación de huéspedes con PXE

Esta sección cubre los pasos requeridos para instalar huéspedes con PXE. La instalación de huésped PXE requiere un dispositivo de red compartido, también conocido como un puente de red. El procedimiento a continuación cubre la creación de un puente y los pasos requeridos para utilizar el puente para un instalación PXE.
  1. Crear un nuevo puente

    1. Cree un nuevo archivo de script de red en el directorio /etc/sysconfig/network-scripts/. Este ejemplo crea un archivo llamado ifcfg-installation, el cual crea un puente llamado installation.
      # cd /etc/sysconfig/network-scripts/
      # vim ifcfg-installation
      DEVICE=installation
      TYPE=Bridge
      BOOTPROTO=dhcp
      ONBOOT=yes
      

      Advertencia

      The line, TYPE=Bridge, is case-sensitive. It must have uppercase 'B' and lower case 'ridge'.
    2. Start the new bridge by restarting the network service. The ifup installation command can start the individual bridge but it is safer to test the entire network restarts properly.
      # service network restart
      
    3. No hay interfaces añadidas al nuevo puente aún. Utilice el comando brctl show para ver información sobre puentes de red en el sistema.
      # brctl show
      bridge name     bridge id               STP enabled     interfaces
      installation    8000.000000000000       no
      virbr0          8000.000000000000       yes
      
      El puente virbr0 es un puente por defecto utilizado por libvirt para Traducción de dirección de red (NAT) en el dispositivo Ethernet predeterminado.
  2. Añada una interfaz al nuevo puente

    Edite el archivo de configuración para la interfaz. Añada el parámetro BRIDGE al archivo de configuración con el nombre del puente creado en los pasos anteriores.
    # Intel Corporation Gigabit Network Connection
    DEVICE=eth1
    BRIDGE=installation
    BOOTPROTO=dhcp
    HWADDR=00:13:20:F7:6E:8E
    ONBOOT=yes
    
    Después de editar el archivo de configuración, reinicie la red o vuelva a arrancar.
    # service network restart
    
    Verifique que la interfaz esté conectada al comando brctl show:
    # brctl show
    bridge name     bridge id               STP enabled     interfaces
    installation    8000.001320f76e8e       no              eth1
    virbr0          8000.000000000000       yes
    
  3. Configuración de seguridad

    Configure iptables para permitir que todo el tráfico sea reenviado a través del puente.
    # iptables -I FORWARD -m physdev --physdev-is-bridged -j ACCEPT
    # service iptables save
    # service iptables restart
    

    Desactivar iptables en puentes

    Otra posibilidad es evitar que el tráfico en puente sea procesado por reglas iptables. En /etc/sysctl.conf añada las siguientes líneas:
    net.bridge.bridge-nf-call-ip6tables = 0
    net.bridge.bridge-nf-call-iptables = 0
    net.bridge.bridge-nf-call-arptables = 0
    
    Vuelva a cargar los parámetros de kernel configurados con sysctl
    # sysctl -p /etc/sysctl.conf
    
  4. Reiniciar libvirt antes de la instalación

    Reinicie el demonio libvirt.
    # service libvirtd reload
    
El puente está configurado, ahora puede comenzar la instalación.
Instalación PXE con virt-install
Para virt-install añada el parámetro de instalación --network=bridge:installation donde installation es el nombre de su puente. Para instalaciones de PXE utilice el parámetro --pxe.
Ejemplo 7.3. Instalación PXE con virt-install
# virt-install --accelerate --hvm --connect qemu:///system \
    --network=bridge:installation --pxe\
    --name EL10 --ram=756 \
    --vcpus=4
    --os-type=linux --os-variant=rhel5
    --file=/var/lib/libvirt/images/EL10.img \

Instalación PXE con virt-manager
The steps below are the steps that vary from the standard virt-manager installation procedures. For the standard installations refer to Capítulo 8, Procedimiento de instalación de sistema operativo de huésped.
  1. Seleccionar PXE

    Seleccionar PXE como el medio de instalación
  2. Seleccionar el puente

    Seleccione Dispositivo físico compartido y elija el puente creado en el procedimiento anterior.
  3. Iniciar la instalación

    La instalación está lista para empezar.
Una solicitud de DHCP es enviada y si se encuentra un servidor válido PXE, los procesos de instalación de huésped iniciarán.

Capítulo 8. Procedimiento de instalación de sistema operativo de huésped

This chapter covers how to install various guest operating systems in a virtualized environment on Red Hat Enterprise Linux. To understand the basic processes, refer to Capítulo 7, Visión general de la tecnología de virtualización.

Importante

When installing a Red Hat Enterprise Linux guest, the installer will ask to perform an integrity check on your installation source (CD/DVD media, or ISO file). If you select to perform the check, once the media is tested and the installation continues, you may encounter a message that states: The Red Hat Enterprise Linux Server CD was not found in any of your CDROM drives. Please insert the Red Hat Enterprise Linux Server CD and press OK to retry.
This behavior is intentional, provided as a convenience to make sure media is ejected in case a CD install (requiring multiple discs/images) is being performed as opposed to a DVD install.
To proceed past this message, make sure you either insert the next CD, or edit the guest's XML file specifying the next ISO file (or re-insert the DVD media). Next, run virsh update-device Guest1 ~/Guest1.xml (substituting your guest's name and XML file), and select OK to continue past this step.

8.1. Instalación de Red Hat Enterprise Linux 5 como huésped para-virtualizado

Esta sección describe cómo instalar Red Hat Enterprise Linux 5 como un huésped para-virtualizado. La para-virtualización es más rápida que la virtualización completa y soporta todas las ventajas de la virtualización completa. La para-virtualización requiere un kernel soportado especial, el kernel de kernel-xen.

Nota importante sobre para-virtualización

La para-virtualización sólo funciona con el hipervisor Xen. La para-virtualización no funciona con el hipervisor KVM.
Asegúrese de tener acceso de root antes de iniciar la instalación.
Este método instala Red Hat Enterprise Linux desde un servidor remoto. Las instrucciones de instalación presentadas en esta sección son similares a la instalación mínima en vivo de CD-ROM.
Create para-virtualized Red Hat Enterprise Linux 5 guests using virt-manager or virt-install. For instructions on virt-manager, refer to the procedure in Sección 7.2, “Creación de huéspedes con virt-manager”.
Cree un huésped para-virtualizado con la herramienta de la línea de comandos virt-install. La opción --vnc muestra la instalación gráfica. El nombre de huésped en el ejemplo es rhel5PV, el archivo de imagen de disco es rhel5PV.dsk y el espejo local de un árbol de instalación de Red Hat Enterprise Linux 5 es ftp://10.1.1.1/trees/RHEL5-B2-Server-i386/. Remplace estos valores por valores exactos para su sistema y red.
# virt-install -n rhel5PV -r 500 \
-f /var/lib/libvirt/images/rhel5PV.dsk -s 3 --vnc -p \
-l ftp://10.1.1.1/trees/RHEL5-B2-Server-i386/

Automatizar la instalación

Red Hat Enterprise Linux puede ser instalado sin interfaz gráfica o entrada manual. Use los archivos Kickstart para automatizar el proceso de instalación.
El uso de cualquiera de los métodos abre esta ventana, la cual muestra las fases de arranque de su huésped:
Después de que su huésped haya completado el arranque inicial, se inicia el proceso de instalación estándar para Red Hat Enterprise Linux. Para la mayoría de los sistemas las respuestas predeterminadas son aceptables.
Procedimiento 8.1. Procedimiento de instalación de huésped para-virtualizado de Red Hat Enterprise Linux
  1. Seleccione el idioma y haga clic en OK.
  2. Seleccione el diseño del teclado y haga clic en OK.
  3. Assign the guest's network address. Choose to use DHCP (as shown below) or a static IP address:
  4. Si selecciona DHCP el proceso de instalación intentará obtener una dirección IP:
  5. If you chose a static IP address for your guest this prompt appears. Enter the details on the guest's networking configuration:
    1. Ingrese una dirección IP válida. Asegúrese de que esa dirección IP pueda llegar al servidor con el árbol de instalación.
    2. Ingrese un máscara de subred válida, el puerto de enlace por defecto y la dirección de nombre de servidor.
    Seleccione el idioma y haga clic en OK.
  6. Este es un ejemplo de configuración de dirección IP estática:
  7. El proceso de instalación ahora recupera los archivos necesarios desde el servidor:
Una vez los pasos iniciales estén completos, comienza el proceso de instalación gráfica.
Si está instalando una distribución de lanzamiento Beta o temprana, confirme que desea instalar el sistema operativo. Haga clic en Instale de todos modos, y luego en OK:
Procedimiento 8.2. Proceso de instalación gráfica
  1. Ingrese un código de registro válido. Si tiene una llave de suscripción válida de RHN, por favor ingrésela en el campo Installation Number:

    Nota

    Si ignora el paso de registro, confirme su información de cuenta de Red Hat Network después de la instalación con el comando rhn_register. El comando rhn_register requiere acceso de root.
  2. La instalación le solicita confirmar el borrado de todos los datos en el almacenaje que usted seleccionó para la instalación:
    Haga clic en Yes para continuar.
  3. Review the storage configuration and partition layout. You can chose to select the advanced storage configuration if you want to use iSCSI for the guest's storage.
    Make your selections then click Forward.
  4. Confirme el almacenaje seleccionado para la instalación.
    Haga clic en Yes para continuar.
  5. Establezca la configuración de red y de nombre de host. Esta configuración se genera con los datos ingresados anteriormente en el proceso de instalación. Cambie esta configuración si es necesario.
    Haga clic en OK para continuar.
  6. Seleccione la zona horaria apropiada para su entorno.
  7. Ingrese la contraseña de root para el huésped.
    Haga clic en Adelante para continuar.
  8. Seleccione los paquetes de software a instalar. Seleccione el botón Personalizar ahora. Debe instalar el paquete de kernel-xen en el directorio System. El paquete de kernel-xen es requerido para la para-virtualización.
    Click Forward.
  9. Los requerimientos de dependencias y espacio son calculados.
  10. After the installation dependencies and space requirements have been verified click Forward to start the actual installation.
  11. Todos los paquetes de software seleccionados se instalan automáticamente.
  12. Cuando la instalación haya finalizado reinicie el huésped:
  13. El huésped en lugar de reiniciar, se apagará...
  14. Boot the guest. The guest's name was chosen when you used the virt-install in Sección 8.1, “Instalación de Red Hat Enterprise Linux 5 como huésped para-virtualizado”. If you used the default example the name is rhel5PV.
    Utilice virsh para volver a arrancar el huésped:
    # virsh reboot rhel5PV
    Otra posibilidad es abrir virt-manager, seleccionar el nombre de su huésped, y hacer clic en Abrir, luego haga clic en ejecutar.
    A VNC window displaying the guest's boot processes now opens.
  15. Al arrancar el huésped se inicia la pantalla de configuración del Primer arranque. Este asistente le solicita algunas opciones de configuración básicas para su huésped.
  16. Lea y acepte el acuerdo de licencia.
    Haga clic en Adelante en el acuerdo de licencia de Windows.
  17. Configuración de Firewall.
    Haga clic en Adelante para continuar.
    1. Si desactiva el Firewall se le solicitará confirmar su elección. Haga clic en para confirmar y continuar. No se recomienda desactivar el Firewall.
  18. Configure SELinux. Se recomienda encarecidamente ejecutar SELinux en modo impositivo. Tiene la opción de ejecutar SELinux en modo permisivo o desactivarlo completamente.
    Haga clic en Adelante para continuar.
    1. Si elige desactivar SELinux aparece esta advertencia. Haga clic en para desactivar SELinux.
  19. Disable kdump. The use of kdump is unsupported on para-virtualized guests.
    Haga clic en Adelante para continuar.
  20. Confirm time and date are set correctly for your guest. If you install a para-virtualized guest time and date should synchronize with the hypervisor.
    If the users sets the time or date during the installation it is ignored and the hypervisor's time is used.
    Haga clic en Adelante para continuar.
  21. Configure actualizaciones de software. Si no tiene una suscripción de Red Hat Network o si desea ensayar una, utilice la pantalla de abajo para registrar su huésped recién instalado en RHN.
    Haga clic en Adelante para continuar.
    1. Confirme su escogencia para RHN.
    2. Verá una pantalla adicional si no configuró el acceso a RHN. Si el acceso a RHN no está habilitado, no recibirá actualizaciones de software.
      Haga clic en el botón Adelante.
  22. Cree una cuenta de usuario no-root. Se recomienda crear un usuario no-root para uso normal y seguridad mejorada. Ingrese el nombre de usuario, Nombre y contraseña.
    Haga clic en el botón Adelante.
  23. Si detecta un dispositivo de sonido y requiere sonido, puede calibrarlo. Complete el proceso y haga clic en Adelante.
  24. You can install additional packages from a CD or another repository using this screen. It is often more efficient to not install any additional software at this point but add packages later using the yum command or RHN. Click Finish.
  25. El huésped ahora establece la configuración que usted cambió y continúa el proceso de arranque.
  26. Muestra la pantalla de ingreso de Red Hat Enterprise Linux 5. Ingrese con el nombre de usuario creado en los pasos anteriores.
  27. Ahora ha instalado con éxito un huésped para-virtualizado de Red Hat Enterprise Linux.

8.2. Instalación de Red Hat Enterprise Linux como un huésped completamente virtualizado

This section covers installing a fully virtualized Red Hat Enterprise Linux 5 guest. This procedure covers both the KVM and the Xen hypervisors; the steps are interchangeable and different steps are noted.
The KVM hypervisor requires Red Hat Enterprise Linux 5.4 or newer.
Procedimiento 8.3. Creación de un huésped completamente virtualizado de Red Hat Enterprise Linux 5 con virt-manager
  1. Open virt-manager

    Inicie virt-manager. Lance la aplicación del Administrador de máquina virtual desde el menú Aplicaciones y el submenú Herramientas del sistema. También, puede ejecutar el comando virt-manager como root.
  2. Seleccione el hipervisor

    Seleccione el hipervisor. Si está instalado, seleccione Xen o KVM. Para este ejemplo, seleccione KVM. Observe que actualmente el KVM se denomina qemu.
    Connect to a hypervisor if you have not already done so. Open the File menu and select the Add Connection... option. Refer to Sección 26.1, “The Add Connection window”.
    Una vez haya seleccionado la conexión del hipervisor el botón Nueva aparece. Presione el botón Nueva.
  3. Inicie el asistente de la nueva máquina virtual

    Pressing the New button starts the virtual machine creation wizard.
    Press Forward to continue.
  4. Nombre de la máquina virtual

    Provide a name for your virtualized guest. Punctuation and whitespace characters are not permitted in versions before Red Hat Enterprise Linux 5.5. Red Hat Enterprise Linux 5.5 adds support for '_', '.' and '-' characters.
    Press Forward to continue.
  5. Elija un método de virtualización

    Choose the virtualization method for the virtualized guest. Note you can only select an installed virtualization method. If you selected KVM or Xen earlier (Paso 4) you must use the hypervisor you selected. This example uses the KVM hypervisor.
    Press Forward to continue.
  6. Seleccione el método de instalación

    Red Hat Enterprise Linux puede ser instalado mediante los siguientes métodos:
    • Medios de instalación local, ya sea una imagen ISO o un medio óptico físico.
    • Seleccione Árbol de instalación de red si tiene el árbol de instalación para Red Hat Enterprise Linux alojado en alguna parte en su red a través de HTTP, FTP o NFS.
    • PXE puede ser instalado si tiene un servidor PXE configurado para iniciar medios de instalación de Red Hat Enterprise Linux. La configuración de un servidor a PXE para arrancar una instalación de Red Hat Enterprise Linux no se cubre en este manual. No obstante, la mayoría de los pasos de instalación son los mismos después del arranque de medios.
    Set OS Type to Linux and OS Variant to Red Hat Enterprise Linux 5 as shown in the screenshot.
    Press Forward to continue.
  7. Ubicar el medio de instalación

    Seleccione la ubicación de la imagen ISO o dispositivo CD-ROM o DVD. Este ejemplo utiliza un archivo de imagen ISO de la instalación de DVD de Red Hat Enterprise Linux.
    1. Presione el botón Navegar.
    2. Busque la ubicación del archivo ISO y selecciones la imagen ISO. Presione Abrir para confirmar su elección.
    3. The file is selected and ready to install.
      Press Forward to continue.

    Archivos de imagen y SELinux

    For ISO image files and guest storage images the recommended to use the /var/lib/libvirt/images/ directory. Any other location may require additional configuration for SELinux, refer to Sección 18.2, “SELinux y virtualización completas” for details.
  8. Configuración de almacenaje

    Assign a physical storage device (Block device) or a file-based image (File). File-based images must be stored in the /var/lib/libvirt/images/ directory. Assign sufficient space for your virtualized guest and any applications the guest requires.
    Press Forward to continue.

    Migración

    Live and offline migrations require guests to be installed on shared network storage. For information on setting up shared storage for guests refer to Parte V, “Virtualization Storage Topics”.
  9. Configuración de redes

    Seleccione Red virtual o Dispositivo físico compartido.
    La opción de red virtual utiliza Traducción de dirección de redes (NAT) para compartir el dispositivo de red predeterminado con un huésped virtualizado. Utilice la opción de red virtual para redes inalámbricas.
    The shared physical device option uses a network bond to give the virtualized guest full access to a network device.
    Press Forward to continue.
  10. Asignación de memoria y CPU

    The Memory and CPU Allocation window displays. Choose appropriate values for the virtualized CPUs and RAM allocation. These values affect the host's and guest's performance.
    Los huéspedes virtualizados requieren suficiente memoria física (RAM) para ejecutar de una manera efectiva y eficaz. Elija la memoria que se ajuste a su sistema operativo de huésped y a los requerimientos de aplicación. Recuerde que los huéspedes usan RAM física. Si ejecuta muchos huéspedes o deja memoria insuficiente para el sistema de huésped, generará un uso significativo de memoria virtual y de intercambio. La memoria virtual es mucho más lenta, lo que produce un rendimiento y receptividad del sistema degradados. Asegúrese de asignar suficiente memoria a todos los huéspedes y al host para que operen con eficacia.
    Asigne suficientes CPU virtuales para el huésped virtualizado. Si el huésped ejecuta una aplicación multi-hilos, asigne el número de CPU virtualizadas que el huésped requiera para ejecutarse con eficacia. No asigne un número mayor de CPU virtuales que el de los procesadores físicos (o hiper-hilos) disponibles en el sistema de host. Es posible sobre asignar procesadores virtuales, sin embargo, la sobre asignación tiene un efecto negativo importante en el huésped y el rendimiento del host debido a la sobrecarga de conmutación de contexto de procesador.
    Press Forward to continue.
  11. Verificar e iniciar una instalación de un huésped

    Verify the configuration.
    Press Finish to start the guest installation procedure.
  12. Instalación de Red Hat Enterprise Linux

    Complete la secuencia de instalación de Red Hat Enterprise Linux 5. La secuencia de instalación se describe en el Manual de instalación, consulte Documentación de Red Hat para El Manual de Instalación de Red Hat Enterprise Linux.
Un huésped completamente virtualizado de Red Hat Enterprise Linux 5 está ahora instalado.

8.3. Instalación de Windows XP como huésped completamente virtualizado

Windows XP puede ser instalado como un huésped completamente virtualizado. Esta sección describe cómo instalar Windows XP como un huésped completamente virtualizado en Red Hat Enterprise Linux.
This procedure covers both the KVM and the Xen hypervisors; the steps are interchangeable and different steps are noted.
The KVM hypervisor requires Red Hat Enterprise Linux 5.4 or newer.
Antes de comenzar este procedimiento asegúrese de tener acceso de root.

Soporte de Itanium®

Actualmente, los hosts de Red Hat Enterprise Linux en la arquitectura Itanium® no soportan huéspedes de Windows XP completamente virtualizados. Sólo Windows Server 2003 para sistemas basados en Itanium está soportado para sistemas de Itanium.
  1. Iniciar virt-manager

    Open Applications > System Tools > Virtual Machine Manager. Open a connection to a host (click File > Add Connection). Click the New button to create a new virtual machine.
  2. Dar un nombre al sistema virtual

    Ingrese el Nombre de sistema y haga clic en el botón Adelante.
  3. Elegir el método de virtualización

    If you selected KVM or Xen earlier (step Paso 1 ) you must use the hypervisor you selected. This example uses the KVM hypervisor.
    Windows sólo puede ser instalado mediante virtualización completa.
  4. Elegir el método de instalación

    Esta pantalla le permite especificar el método de instalación y el tipo de sistema operativo.
    Seleccione Windows desde la lista de Tipo de sistema operativo y Microsoft Windows XP desde la lista de Variante de sistema operativo.
    La instalación de huéspedes con PXE es soportada desde Red Hat Enterprise Linux 5.2. La instalación PXE no se cubre en este capítulo.

    Archivos de imagen y SELinux

    For ISO image files and guest storage images the recommended to use the /var/lib/libvirt/images/ directory. Any other location may require additional configuration for SELinux, refer to Sección 18.2, “SELinux y virtualización completas” for details.
    Presione Adelante para continuar.
  5. Choose installation image

    Choose the installation image or CD-ROM. For CD-ROM or DVD installation select the device with the Windows installation disc in it. If you chose ISO Image Location enter the path to a Windows installation .iso image.
    Presione Adelante para continuar.
  6. The Storage window displays. Choose a disk partition, LUN or create a file-based image for the guest's storage.
    All image files are stored in the /var/lib/libvirt/images/ directory by default. In the default configuration, other directory locations for file-based images are prohibited by SELinux. If you use a different directory you must label the new directory according to SELinux policy. Refer to Sección 18.2, “SELinux y virtualización completas” for details.
    Asigne un espacio adicional si el huésped necesita más espacio para aplicaciones u otros datos. Por ejemplo, los servidores de red requieren espacio adicional para archivos de registro.
    Elija el tamaño apropiado para el huésped en su tipo de almacenaje seleccionado y haga clic en el botón Adelante.

    Nota

    Se recomienda utilizar el directorio predeterminado para imágenes de máquina virtual, /var/lib/libvirt/images/. Si está utilizando una ubicación diferente (tal como /images/ en este ejemplo), añada la política de SELinux y vuélvala a etiquetar antes de continuar con la instalación (más adelante en el documento encontrará información sobre cómo modificar su política de SELinux).
  7. Configurar la red

    Elija entre Red virtual o Dispositivo físico compartido.
    La opción de red virtual utiliza Traducción de dirección de red (NAT) para compartir el dispositivo de red predeterminado con el huésped virtualizado. Use la opción de red virtual para redes inalámbricas.
    The shared physical device option uses a network bond to give the virtualized guest full access to a network device.
    Press Forward to continue.
  8. The Memory and CPU Allocation window displays. Choose appropriate values for the virtualized CPUs and RAM allocation. These values affect the host's and guest's performance.
    Los huéspedes virtualizados requieren suficiente memoria física (RAM) para operar en forma eficiente y eficaz. Elija un valor de memoria apto para los requerimientos de su sistema operativo de huésped y aplicaciones. La mayoría de los sistemas operativos requieren al menos 512MB de RAM para funcionar con alternación. Recuerde que los huéspedes usan RAM física. Si se ejecutan demasiados huéspedes o si se deja memoria insuficiente para el sistema de host, resulta en un uso significativo de memoria virtual y de intercambio. La memoria virtual es bastante lenta lo que hace que el rendimiento y receptividad del sistema se degraden. Asigne suficiente memoria para que todos los huéspedes y el host operen de modo eficaz.
    Asigne las CPU virtuales suficientes para el huésped virtualizado. Si el huésped ejecuta una aplicación multihilos, asigne el número de CPU virtualizadas que éste requiera para operar eficientemente. No asigne más CPU virtuales que las de los procesadores físicos (o hiper-hilos) disponibles en el sistema de host. Es posible asignar más procesadores virtuales, no obstante, esto puede tener efectos negativos en el rendimiento del huésped y host debido a la sobrecarga de cambio de contexto.
  9. Antes de que la instalación continúe, aparecerá la pantalla de resumen. Presione Terminar para proseguir con la instalación de huésped:
  10. You must make a hardware selection so open a console window quickly after the installation starts. Click Finish then switch to the virt-manager summary window and select your newly started Windows guest. Double click on the system name and the console window opens. Quickly and repeatedly press F5 to select a new HAL, once you get the dialog box in the Windows install select the 'Generic i486 Platform' tab. Scroll through selections with the Up and Down arrows.
  11. La instalación continúa con la instalación estándar de Windows.
  12. Dividir el disco duro cuando se le solicite.
  13. Después de dar formato al controlador, Windows comienza a copiar los archivos al disco duro.
  14. Los archivos son copiados al dispositivo de almacenamiento y ahora Windows reinicia.
  15. Reiniciar el huésped de Windows:
    # virsh start WindowsGuest
    WindowsGuest es el nombre de su máquina virtual.
  16. Cuando la ventana de consola se abra, verá la fase de configuración de la instalación de Windows.
  17. Si su instalación parece estar bloqueada durante la fase de configuración, reinicie el huésped con virsh reboot Nombre de_huésped_Windows. Al reiniciar la máquina virtual, el mensaje Setup is being restarted muestra:
  18. Cuando la configuración termine, verá la pantalla de arranque de Windows:
  19. Ahora, puede continuar con la configuración estándar de su instalación de Windows:
  20. El proceso de configuración está completo.

8.4. Instalación de Windows Server 2003 como un huésped completamente virtualizado

This chapter describes installing a fully virtualized Windows Server 2003 guest with the virt-install command. virt-install can be used instead of virt-manager This process is similar to the Windows XP installation covered in Sección 8.3, “Instalación de Windows XP como huésped completamente virtualizado”.

Soporte Itanium®

Actualmente, los hosts de Red Hat Enterprise Linux en la arquitectura Itanium® no soportan huéspedes de Windows totalmente virtualizados. Esta sección se aplica únicamente a hosts x86 y x86-64.
  1. Using virt-install for installing Windows Server 2003 as the console for the Windows guest opens the virt-viewer window promptly. The examples below installs a Windows Server 2003 guest with the virt-install command.
    1. Xen virt-install

      # virt-install --virt-type=xen -hvm  \
         --name windows2003sp1 
         --file=/var/lib/libvirt/images/windows2003sp2.img \
         --file-size=6 \
         --cdrom=/var/lib/libvirt/images/ISOs/WIN/en_windows_server_2003_sp1.iso \
         --vnc --ram=1024
      
    2. KVM virt-install

      # virt-install --accelerate --hvm --connect qemu:///system \
         --name rhel3support  \
         --network network:default \
         --file=/var/lib/libvirt/images/windows2003sp2.img \
         --file-size=6 \
         --cdrom=/var/lib/libvirt/images/ISOs/WIN/en_windows_server_2003_sp1.iso \
         --vnc --ram=1024
      
  2. Una vez que el huésped arranca dentro de la instalación, se debe presionar rápidamente la tecla F5. Si no presiona F5 en el momento preciso, necesitará reiniciar la instalación. Al presionar la tecla F5 puede seleccionar diferentes HAL o Tipo de computador. Elija Standard PC como el Tipo de computador. El cambio de Tipo de computador es requerido por los huéspedes virtualizados de Windows Server 2003.
  3. Complete el resto de la instalación.
  4. Ahora, Windows Server 2003 está instalado como huésped completamente virtualizado.

8.5. Instalación de Windows Server 2008 como huésped totalmente virtualizado

This section covers installing a fully virtualized Windows Server 2008 guest. This procedure covers both the KVM and the Xen hypervisors; the steps are interchangeable and different steps are noted.
The KVM hypervisor requires Red Hat Enterprise Linux 5.4 or newer.
Procedimiento 8.4. Instalación de Windows Server 2008 con virt-manager
  1. Abrir virt-manager

    Inicie virt-manager. Lance la aplicación Administrador de máquina virtual desde el menú de Aplicaciones y el submenú Herramientas del sistemas. De modo alterno, puede ejecutar el comando virt-manager como root.
  2. Seleccionar el hipervisor

    Seleccione el hipervisor. Si está instalado, seleccione Xen o KVM. Para este ejemplo seleccione KVM. Observe que KVM actualmente se denomina qemu.
    Una vez seleccionada esta opción el botón Nueva aparece. Presione el botón Nueva.
  3. Iniciar el asistente de la nueva máquina virtual

    Pressing the New button starts the virtual machine creation wizard.
    Press Forward to continue.
  4. Dar nombre a la máquina virtual

    Provide a name for your virtualized guest. Punctuation and whitespace characters are not permitted in versions before Red Hat Enterprise Linux 5.5. Red Hat Enterprise Linux 5.5 adds support for '_', '.' and '-' characters.
    Press Forward to continue.
  5. Elegir el método de virtualización

    Choose the virtualization method for the virtualized guest. Note you can only select an installed virtualization method. If you selected KVM or Xen earlier (step 2) you must use the hypervisor you selected. This example uses the KVM hypervisor.
    Press Forward to continue.
  6. Seleccionar el medio de instalación

    Para todas las versiones de Windows, debe usar local install media, ya sea una imagen ISO o un medio óptico físico.
    PXE puede usarse si ya se tiene un servidor PXE para instalación de red de Windows. La instalación PXE Windows no se cubre en este manual.
    Set OS Type to Windows and OS Variant to Microsoft Windows 2008 as shown in the screenshot.
    Press Forward to continue.
  7. Ubicar el medio de instalación

    Seleccione la ubicación de la imagen ISO o CD-ROM o el dispositivo DVD. Este ejemplo utiliza una imagen de archivo ISO del CD de instalación de Windows Server 2008.
    1. Presione el botón Navegar.
    2. Search to the location of the ISO file and select it.
      Press Open to confirm your selection.
    3. The file is selected and ready to install.
      Press Forward to continue.

    Archivos de imagen y SELinux

    For ISO image files and guest storage images, the recommended directory to use is the /var/lib/libvirt/images/ directory. Any other location may require additional configuration for SELinux, refer to Sección 18.2, “SELinux y virtualización completas” for details.
  8. Establecer almacenamiento

    Assign a physical storage device (Block device) or a file-based image (File). File-based images must be stored in the /var/lib/libvirt/images/ directory. Assign sufficient space for your virtualized guest and any applications the guest requires.
    Press Forward to continue.
  9. Configurar red

    Seleccione Red virtual network o Dispositivo físico compartido.
    La opción de red virtual usa Traducción de dirección de red (NAT) para compartir el dispositivo de red predeterminado con el huésped virtualizado. Use la opción de red para redes inalámbricas.
    The shared physical device option uses a network bond to give the virtualized guest full access to a network device.
    Press Forward to continue.
  10. Asignar memoria y CPU

    The Memory and CPU Allocation window displays. Choose appropriate values for the virtualized CPUs and RAM allocation. These values affect the host's and guest's performance.
    Los huéspedes virtualizados requieren suficiente memoria física (RAM) para ejecutar de modo eficiente y eficaz. Elija un valor de memoria que se ajuste a los requerimientos de su sistema operativo. Recuerde que sus huéspedes usan RAM física. La ejecución de demasiados huéspedes o dejar memoria insuficiente para el sistema de host, resulta en uso significativo de memoria virtual y de intercambio. La memoria virtual es mucho más lenta, lo cual produce una respuesta y rendimiento degradado del sistema. Asigne suficiente memoria a todos los huéspedes y al host para funcionar eficazmente.
    Asigne suficientes CPU virtuales para el huésped virtualizado. Si el huésped ejecuta una aplicación multihilos, asigne el número de CPU virtualizadas que éste requiere para ejecutar de modo eficiente. No asigne más CPU virtuales que las que hay de procesadores físicos (o hiperhilos) disponibles en el sistema de host. Es posible asignar más procesadores virtuales, sin embargo, la sobre asignación tiene un efecto negativo importante en el rendimiento del huésped y host debido a las sobrecargas de cambio de contexto de procesador.
    Press Forward to continue.
  11. Verificar e iniciar la instalación de huésped

    Verify the configuration.
    Press Finish to start the guest installation procedure.
  12. Instalar Windows

    Complete the Windows Server 2008 installation sequence. The installation sequence is not covered by this guide, refer to Microsoft's documentation for information on installing Windows.

Parte III. Configuración

Configurar la virtualización en Red Hat Enterprise Linux

These chapters cover configuration procedures for various advanced virtualization tasks. These tasks include adding network and storage devices, enhancing security, improving performance, and using the Para-virtualized drivers on fully virtualized guests.

Tabla de contenidos

9. Virtualized storage devices
9.1. Cómo crear un controlador de disquete virtualizado
9.2. Cómo añadir dispositivos de almacenaje a huéspedes
9.3. Cómo configurar un almacenamiento persistente en Red Hat Enterprise Linux 5
9.4. Cómo añadir dispositivos CD-ROM o DVD a un huésped
10. Configuración de la red
10.1. Traducción de dirección de red (NAT) con libvirt
10.2. Creación de redes en puente con libvirt
11. Creación de redes Xen en Pre-Red Hat Enterprise Linux 5.4
11.1. Configuración de varios puentes de red huéspedes para usar varias tarjetas Ethernet
11.2. Configuración de redes de portátil de Red Hat Enterprise Linux 5.0
12. Controladores para-virtualizados Xen
12.1. Requerimientos del sistema
12.2. Restricciones y soporte de para-virtualización
12.3. Instalación de controladores para-virtualizados
12.3.1. Pasos comunes de instalación
12.3.2. Instalación y configuración de controladores para-virtualizados en Red Hat Enterprise Linux 3
12.3.3. Instalación y configuración de controladores para-virtualizados en Red Hat Enterprise Linux 4
12.3.4. Xen Para-virtualized Drivers on Red Hat Enterprise Linux 5
12.3.5. Xen Para-virtualized Drivers on Red Hat Enterprise Linux 6
12.4. Configuración de controlador para-virtualizado de redes
12.5. Configuración de hardware para-virtualizado adicional
12.5.1. Interfaces de red virtualizadas
12.5.2. Dispositivos de almacenamiento virtualizados
13. Controladores KVM para-virtualizados
13.1. Instalación de controladores KVM Windows para-virtualizados
13.2. Installing drivers with a virtualized floppy disk
13.3. Uso de controladores KVM para-virtualizados para dispositivos existentes
13.4. Uso de controladores KVM para-virtualizados para nuevos dispositivos
14. Paso de PCI
14.1. Adding a PCI device with virsh
14.2. Adding a PCI device with virt-manager
14.3. PCI passthrough with virt-install
14.4. PCI passthrough for para-virtualized Xen guests on Red Hat Enterprise Linux
15. SR-IOV
15.1. Introduction
15.2. Using SR-IOV
15.3. Troubleshooting SR-IOV
16. Administración del tiempo del huésped KVM

Capítulo 9. Virtualized storage devices

This chapter covers installing and configuring storage devices in virtualized guests. The term block devices refers to various forms of storage devices. All the procedures in this chapter work with both Xen and KVM hypervisors.

Valid disk targets

The target variable in libvirt configuration files accepts only the following device names:
  • /dev/xvd[a to z][1 to 15]
    Example: /dev/xvdb13
  • /dev/xvd[a to i][a to z][1 to 15]
    Example: /dev/xvdbz13
  • /dev/sd[a to p][1 to 15]
    Example: /dev/sda1
  • /dev/hd[a to t][1 to 63]
    Example: /dev/hdd3

9.1. Cómo crear un controlador de disquete virtualizado

Los controladores de disquete se requieren para un número de sistemas operativos anteriores, especialmente para la instalación de controladores. Actualmente, los dispositivos de disquete no se pueden acceder desde huéspedes virtualizados. No obstante, se soportan la creación y acceso de imágenes de disquete desde unidades de disquetes virtualizadas. Esta sección cubre la creación de un dispositivo de disquete virtualizado.
An image file of a floppy disk is required. Create floppy disk image files with the dd command. Replace /dev/fd0 with the name of a floppy device and name the disk appropriately.
# dd if=/dev/fd0 of=~/legacydrivers.img

Nota de controladores para-virtualizados

The para-virtualized drivers can map physical floppy devices to fully virtualized guests. For more information on using para-virtualized drivers read Capítulo 13, Controladores KVM para-virtualizados.
Este ejemplo utiliza un huésped creado con virt-manager, el cual ejecuta una instalación totalmente virtualizada de Red Hat Enterprise Linux con una imagen ubicada en /var/lib/libvirt/images/rhel5FV.img. El hipervisor Xen se utiliza en este ejemplo.
  1. Cree el archivo de configuración XML para su imagen de huésped mediante el comando virsh en un huésped en ejecución.
    # virsh dumpxml rhel5FV > rhel5FV.xml
    
    This saves the configuration settings as an XML file which can be edited to customize the operations and devices used by the guest. For more information on using the virsh XML configuration files, refer to Capítulo 33, Creación de scripts libvirt personales.
  2. Cree una imagen de disquete para el huésped.
    # dd if=/dev/zero of=/var/lib/libvirt/images/rhel5FV-floppy.img bs=512 count=2880
    
  3. Add the content below, changing where appropriate, to your guest's configuration XML file. This example is an emulated floppy device using a file-based image.
    <disk type='file' device='floppy'>
    	<source file='/var/lib/libvirt/images/rhel5FV-floppy.img'/>
    	<target dev='fda'/>
    </disk>
    
  4. Force the guest to stop. To shut down the guest gracefully, use the virsh shutdown command instead.
    # virsh destroy rhel5FV
  5. Reinicie al huésped mediante el archivo de configuración XML.
    # virsh create rhel5FV.xml
    
El dispositivo de disquete ahora está disponible en el huésped y está almacenado como un archivo de imagen en el host.

9.2. Cómo añadir dispositivos de almacenaje a huéspedes

Esta sección cubre la adición de dispositivos de almacenaje a un huésped virtualizado. El almacenamiento adicional sólo puede agregarse después de la creación de huéspedes. Los dispositivos de almacenaje con soporte y protocolo incluyen:
  • Particiones de discos duros locales,
  • Volúmenes lógicos,
  • Canal de fibra o iSCSI conectado directamente al host.
  • Contenedores de archivos que residen en un sistema de archivos en el host.
  • Sistemas de archivos NFS montados directamente por la máquina virtual.
  • Almacenamiento iSCSI accedido directamente por el huésped.
  • Sistemas de archivos en cluster (GFS).
Cómo agregar almacenamiento basado en archivo a un huésped
El archivo de almacenamiento o el archivo de contenedores son archivos en el sistema de archivos de huéspedes que actúan como discos duros para huéspedes virtualizados. Para agregar un contenedor de archivo realice los siguientes pasos:
  1. Cree un archivo de contenedor vacío o utilice un contenedor de archivos ya existente (tal como un archivo ISO).
    1. Para crear un archivo disperso utilice el comando dd. Los archivos dispersos no se recomiendan, debido a que presentan problemas con la integridad de datos y el rendimiento. Estos archivos se crean mucho más rápido y pueden utilizarse como prueba, pero no deben utilizarse en entornos de producción.
      # dd if=/dev/zero of=/var/lib/libvirt/images/FileName.img bs=1M seek=4096 count=0
      
    2. Los archivos no-dispersos, pre-asignados se recomiendan para imágenes de almacenamiento basadas en archivos. Para crear un archivo no-disperso, ejecute:
      # dd if=/dev/zero of=/var/lib/libvirt/images/FileName.img bs=1M count=4096
      
    Both commands create a 4GB file which can be used as additional storage for a virtualized guest.
  2. Vacíe la configuración para el huésped. En este ejemplo el huésped se denomina Guest1 y el archivo se guarda en el directorio principal de usuario.
    # virsh dumpxml Guest1 > ~/Guest1.xml
    
  3. Abra el archivo de configuración (Guest1.xml en este ejemplo) en un editor de texto. Busque los elementos <disk>, los cuales describen dispositivos de almacenaje. El siguiente es un ejemplo de un elemento de disco:
    <disk type='file' device='disk'>
        <driver name='tap' type='aio'/>
        <source file='/var/lib/libvirt/images/Guest1.img'/>
        <target dev='xvda'/>
    </disk>
    
  4. Añada el almacenamiento adicional duplicando o escribiendo un nuevo elemento <disk>. Asegúrese de especificar un nombre de dispositivo para el dispositivo de bloque virtual, el cual no está aún en el archivo de configuración. El siguiente es un ejemplo de una entrada que añade un archivo, llamado FileName.img, como un archivo de contenedor de almacenamiento:
    <disk type='file' device='disk'>
        <driver name='tap' type='aio'/>
        <source file='/var/lib/libvirt/images/Guest1.img'/>
        <target dev='xvda'/>
    </disk>
    <disk type='file' device='disk'>
        <driver name='tap' type='aio'/>
        <source file='/var/lib/libvirt/images/FileName.img'/>
        <target dev='hda'/>
    </disk>
    
  5. Reinicie el huésped desde el archivo de configuración actualizado.
    # virsh create Guest1.xml
    
  6. The following steps are Linux guest specific. Other operating systems handle new storage devices in different ways. For other systems, refer to that operating system's documentation
    The guest now uses the file FileName.img as the device called /dev/sdb. This device requires formatting from the guest. On the guest, partition the device into one primary partition for the entire device then format the device.
    1. Pulse n para una nueva partición.
      # fdisk /dev/sdb
      Command (m for help):
      
    2. Pulse p para una partición primaria.
      Command action
         e   extended
         p   primary partition (1-4)
      
    3. Elija el número de partición disponible. En este ejemplo la primera partición es seleccionada ingresando 1.
      Partition number (1-4): 1
      
    4. Ingrese el primer cilindro predeterminado al pulsar Enter.
      First cylinder (1-400, default 1):
      
    5. Seleccione el tamaño de la partición. En este ejemplo todo el disco es asignado al pulsar la tecla Enter.
      Last cylinder or +size or +sizeM or +sizeK (2-400, default 400):
      
    6. Establezca el tipo de partición al pulsar t.
      Command (m for help): t
      
    7. Elija la partición que usted creó en los pasos anteriores. En este ejemplo, la partición es 1.
      Partition number (1-4): 1
      
    8. Ingrese 83 para una partición de Linux.
      Hex code (type L to list codes): 83
      
    9. Escriba los cambios al disco y salga.
      Command (m for help): w 
      Command (m for help): q
      
    10. Dé formato a la nueva partición con el sistema de archivos ext3.
      # mke2fs -j /dev/sdb1
      
  7. Monte el disco en el huésped.
    # mount /dev/sdb1 /myfiles
    
Ahora el huésped tiene un dispositivo de almacenamiento de archivo virtualizado adicional.
Cómo añadir discos duros y otros dispositivos de bloque a un huésped
System administrators use additional hard drives for to provide more storage space or to separate system data from user data. This procedure, Procedimiento 9.1, “Cómo añadir dispositivos de bloque físicos a huéspedes virtualizados.”, describes how to add a hard drive on the host to a virtualized guest.
Los trabajos de procedimiento para todos los dispositivos de bloque físicos, incluyen los CD-ROM, DVD y disquetes.

Block device security

The host should not use disk labels to identify file systems in the fstab file, the initrd file or used by the kernel command line. If less privileged users, especially virtualized guests, have write access to whole partitions or LVM volumes the host system could be compromised.
Guest should not be given write access to whole disks or block devices (for example, /dev/sdb). Virtualized guests with access to block devices may be able to access other block devices on the system or modify volume labels which can be used to compromise the host system. Use partitions (for example, /dev/sdb1) or LVM volumes to prevent this issue.
Procedimiento 9.1. Cómo añadir dispositivos de bloque físicos a huéspedes virtualizados.
  1. Conecte físicamente el dispositivo de disco duro al host. Configure el host si el controlador no es accesible por defecto.
  2. Configure el dispositivo con multipath y si se requiere, persistencia en el host.
  3. Use the virsh attach command. Replace: myguest with your guest's name, /dev/sdb1 with the device to add, and sdc with the location for the device on the guest. The sdc must be an unused device name. Use the sd* notation for Windows guests as well, the guest will recognize the device correctly.
    Append the --type cdrom parameter to the command for CD-ROM or DVD devices.
    Agregue el parámetro --type floppy al comando para dispositivos de disquete.
    # virsh attach-disk myguest
    					/dev/sdb1
    					sdc --driver tap --mode readonly
    
  4. The guest now has a new hard disk device called /dev/sdb on Linux or D: drive, or similar, on Windows. This device may require formatting.

9.3. Cómo configurar un almacenamiento persistente en Red Hat Enterprise Linux 5

Esta sección es para sistemas con almacenamiento externo o de red; es decir, Fibre Channel o dispositivos de almacenaje iSCSI. Se recomienda que dichos sistemas tengan nombres de dispositivos persistentes configurados para sus hosts. Así se ayuda a la migración en vivo como también a proporcionar nombres de dispositivos consistentes y almacenaje para sistemas virtualizados múltiples.
Los Identificadores únicos universales o UUID (Universally Unique Identifiers), son un método estandarizado para la identificación de computadores y dispositivos en entornos informáticos de distribución. Esta sección utiliza los UUID para identificar a iSCSI o LUN de Fibre Channel. Los UUID persisten después del reinicio, desconexión e intercambio de dispositivos. El UUID es similar a una etiqueta en el dispositivo.
Systems which are not running multipath must use Configuración de ruta única. Systems running multipath can use Configuración de multi-rutas.
Configuración de ruta única
This procedure implements LUN device persistence using udev. Only use this procedure for hosts which are not using multipath.
  1. Edite el archivo /etc/scsi_id.config.
    1. Asegúrese de que options=-b sea línea comentada.
      # options=-b
      
    2. Añada la siguiente línea:
      options=-g
      
      Esta opción configura udev para suponer que todos los dispositivos SCSI conectados retornen un UUID.
  2. Para mostrar el UUID para un determinado dispositivo, ejecute el comando scsi_id -g -s /block/sd*. Por ejemplo:
    # scsi_id -g -s /block/sd*
    3600a0b800013275100000015427b625e
    
    La salida puede variar del ejemplo anterior. La salida presenta el UUID del dispositivo /dev/sdc.
  3. Verifique que la salida de UUID mediante el comando scsi_id -g -s /block/sd* sea idéntica desde el computador que accede al dispositivo.
  4. Cree una regla para nombrar el dispositivo. Cree un archivo llamado 20-names.rules en el directorio /etc/udev/rules.d. Añada nuevas reglas a este archivo. Todas las reglas se añaden al mismo archivo utilizando el mismo formato. Las reglas siguen el siguiente formato:
    KERNEL=="sd[a-z]", BUS=="scsi", PROGRAM="/sbin/scsi_id -g -s /block/%k", RESULT="UUID", NAME="devicename"
    
    Remplace UUID y devicename por el UUID recibido anteriormente y el nombre dado para el dispositivo. Esta es una regla para el ejemplo anterior:
    KERNEL="sd*", BUS="scsi", PROGRAM="/sbin/scsi_id -g -s", RESULT="3600a0b800013275100000015427b625e", NAME="rack4row16"
    
    El demonio udev ahora busca todos los dispositivos llamados /dev/sd* para el UUID en la regla. Una vez el dispositivo coincidente esté conectado al sistema se le asigna un nombre desde la regla. En un dispositivo con un UUID de 3600a0b800013275100000015427b625e aparecería como /dev/rack4row16.
  5. Añada esta línea a /etc/rc.local:
    /sbin/start_udev
    
  6. Copie los cambios en los archivos /etc/scsi_id.config, /etc/udev/rules.d/20-names.rules, y /etc/rc.local para los hosts relevantes.
    /sbin/start_udev
    
Los dispositivos de almacenamiento de red con reglas configuradas ahora tienen nombres persistentes en todos los hosts donde los archivos han sido actualizados. Esto significa que puede migrar huéspedes entre hosts mediante el almacenamiento compartido y los huéspedes pueden acceder a los dispositivos de almacenaje en sus archivos de configuración.
Configuración de multi-rutas
El paquete multipath se utiliza para sistemas con más de una ruta física desde el computador a los dispositivos de almacenaje. multipath ofrece tolerancia a fallos, recuperación de fallos y rendimiento mejorado para dispositivos de almacenamiento de red conectados a sistemas de Red Hat Enterprise Linux.
Implementing LUN persistence in a multipath environment requires defined alias names for your multipath devices. Each storage device has a UUID which acts as a key for the aliased names. Identify a device's UUID using the scsi_id command.
# scsi_id -g -s /block/sdc
Los dispositivos multipath serán creados en el directorio /dev/mpath. En el ejemplo a continuación 4 dispositivos están definidos en /etc/multipath.conf:
multipaths { 
	multipath { 
	wwid		3600805f30015987000000000768a0019 
	alias		oramp1 
	} 
	multipath { 
	wwid		3600805f30015987000000000d643001a 
	alias		oramp2 
	} 
	mulitpath { 
	wwid		3600805f3001598700000000086fc001b 
	alias		oramp3 
	} 
	mulitpath { 
	wwid		3600805f300159870000000000984001c 
	alias		oramp4 
	} 
}
This configuration will create 4 LUNs named /dev/mpath/oramp1, /dev/mpath/oramp2, /dev/mpath/oramp3 and /dev/mpath/oramp4. Once entered, the mapping of the devices' WWID to their new names are now persistent after rebooting.

9.4. Cómo añadir dispositivos CD-ROM o DVD a un huésped

To attach an ISO file to a guest while the guest is online use virsh with the attach-disk parameter.
# virsh attach-disk [domain-id] [source] [target] --driver file --type cdrom --mode readonly
The source and target parameters are paths for the files and devices, on the host and guest respectively. The source parameter can be a path to an ISO file or the device from the /dev directory.

Capítulo 10. Configuración de la red

Esta página proporciona una introducción a las configuraciones comunes de red utilizadas por las aplicaciones basadas en libvirt. Esta información se aplica a todas los hipervisores, ya sean Xen, KVM u otro. Para obtener información adicional, consulte los documentos de arquitectura de red de libvirt.
Las dos configuraciones más comunes son "red virtual" y "dispositivo físico compartido". El anterior es idéntico en todos las distribuciones y está disponible fuera de la caja. El último necesita una configuración manual de distribución específica.
Network services on virtualized guests are not accessible by default from external hosts. You must enable either Network address translation (NAT) ir a network Bridge to allow external hosts access to network services on virtualized guests.

10.1. Traducción de dirección de red (NAT) con libvirt

Uno de los métodos más comunes para compartir conexiones de red es utilizar el reenvío de la traducción de dirección de red (NAT) (también conocida como redes virtuales).
Configuración de host
Every standard libvirt installation provides NAT based connectivity to virtual machines out of the box. This is the so called 'default virtual network'. Verify that it is available with the virsh net-list --all command.
# virsh net-list --all
Name                 State      Autostart 
-----------------------------------------
default              active     yes
Si no está disponible, el archivo de configuración XML de ejemplo se puede volver a cargar y activar:
# virsh net-define /usr/share/libvirt/networks/default.xml
La red predeterminada está definida desde /usr/share/libvirt/networks/default.xml
Señale la red predeterminada para iniciar automáticamente:
# virsh net-autostart default
Network default marked as autostarted
Inicie la red predeterminada:
# virsh net-start default
Network default started
Una vez la red predeterminada de libvirt está en ejecución, se podrá ver un dispositivo de puente aislado. Este dispositivo no tiene interferencias físicas agregadas desde que utiliza NAT y reenvío IP para conectarse fuera del mundo. No añada nuevas interfaces.
# brctl show
bridge name     bridge id               STP enabled     interfaces
virbr0          8000.000000000000       yes
libvirt añade reglas iptables que permiten el tráfico hacia y desde huéspedes añadidos al dispositivo virbr0 en las cadenas INPUT, FORWARD, OUTPUT y POSTROUTING. Luego, libvirt intenta activar el parámetro ip_forward. Otras aplicaciones pueden desactivar ip_forward, por eso la mejor opción es añadir lo siguiente a /etc/sysctl.conf.
 net.ipv4.ip_forward = 1
Configuración del huésped
Once the host configuration is complete, a guest can be connected to the virtual network based on its name. To connect a guest to the 'default' virtual network, the following XML can be used in the guest:
<interface type='network'>
  <source network='default'/>
</interface>

Nota

Definir una dirección MAC es opcional. La dirección MAC se genera automáticamente si se omite. Establecer la dirección MAC en forma manual es útil en algunas situaciones.
<interface type='network'>
  <source network='default'/>
  <mac address='00:16:3e:1a:b3:4a'/>
  </interface>

10.2. Creación de redes en puente con libvirt

La creación de redes en puente (también conocido como compartir dispositivos físicos) sirve para dedicar un dispositivo físico a una máquina virtual. El puente se utiliza para configuraciones más avanzadas y en servidores con múltiples interfaces de red.
Inhabilitar los scripts de red Xen
Si su sistema estaba utilizando puente de Xen, se recomienda desactivar el puente predeterminado de red de Xen editando /etc/xen/xend-config.sxp y cambiando la línea:
 (network-script network-bridge)
To:
 (network-script /bin/true)
Inhabilitar el NetworkManager
NetworkManager does not support bridging. Running NetworkManager will overwrite any manual bridge configuration. Because of this, NetworkManager should be disabled in order to use networking via the network scripts (located in the /etc/sysconfig/network-scripts/ directory):
# chkconfig NetworkManager off
# chkconfig network on
# service NetworkManager stop
# service network start

Nota

As an alternative to turning off NetworkManager, add "NM_CONTROLLED=no" to the ifcfg-* scripts used in the examples. If you do not either set this parameter or disable NetworkManager entirely, any bridge configuration will be overwritten and lost when NetworkManager next starts.
Creación de initscripts de redes
Cree o edite los siguientes dos archivos de configuración de redes. Este paso puede repetirse (con nombres diferentes) para puentes de red adicionales.
Cambie al directorio /etc/sysconfig/network-scripts
# cd /etc/sysconfig/network-scripts
Abra el script de redes para el dispositivo que usted está añadiendo al puente. En este ejemplo, ifcfg-eth0 define la interfaz de red física establecida como parte de un puente:
DEVICE=eth0
# change the hardware address to match the hardware address your NIC uses
HWADDR=00:16:76:D6:C9:45
ONBOOT=yes
BRIDGE=br0

Tip

You can configure the device's Maximum Transfer Unit (MTU) by appending an MTU variable to the end of the configuration file.
MTU=9000
Cree un nuevo script de red en el directorio /etc/sysconfig/network-scripts llamado ifcfg-br0 o parecido. El parámetro br0 es el nombre del puente, éste puede ser cualquier cosa, siempre y cuando el nombre del archivo sea el mismo del parámetro de DEVICE.
DEVICE=br0
TYPE=Bridge
BOOTPROTO=dhcp
ONBOOT=yes
DELAY=0

IP address configuration

IP address configuration, be it dynamic or static, should be configured on the bridge itself (for example, in the ifcfg-br0 file). Network access will not function as expected if IP address details are configured on the physical interface that the bridge is connected to.

Advertencia

The line, TYPE=Bridge, is case-sensitive. It must have uppercase 'B' and lower case 'ridge'.
Tras la configuración, reinicie la creación de redes o reinicie.
# service network restart
Configure iptables para permitir que todo el tráfico sea reenviado a través del puente.
# iptables -I FORWARD -m physdev --physdev-is-bridged -j ACCEPT
# service iptables save
# service iptables restart

Desactivar iptables en puentes

Como alternativa, evite que el tráfico en puente sea procesado por reglas iptables. En /etc/sysctl.conf añada las siguientes líneas:
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
Vuelva a cargar los parámetros configurados con sysctl.
# sysctl -p /etc/sysctl.conf
Reinicie el demonio libvirt.
# service libvirtd reload
Deberá tener ahora un "dispositivo físico compartido", cuyos huéspedes pueden conectarse y tienen total acceso de LAN. Verifique su nuevo puente:
# brctl show
bridge name     bridge id               STP enabled     interfaces
virbr0          8000.000000000000       yes
br0             8000.000e0cb30550       no              eth0
Observe que, el puente esté completamente independiente del puente virbr0. No intente conectar el dispositivo físico a virbr0. El puente virbr0 es únicamente para conectividad de Traducción de dirección de redes (NAT).

Capítulo 11. Creación de redes Xen en Pre-Red Hat Enterprise Linux 5.4

Este capítulo cubre temas especiales para creación de redes y configuración de red con el hipervisor Xen.
Most guest network configuration occurs during the guest initialization and installation process. To learn about configuring networking during the guest installation process, read the relevant sections of the installation process, Capítulo 7, Visión general de la tecnología de virtualización.
Network configuration is also covered in the tool specific reference chapters for virsh (Capítulo 25, Administración de huéspedes con virsh) and virt-manager (Capítulo 26, Manejo de huéspedes con un Administrador de máquinas virtuales (virt-manager)). Those chapters provide a detailed description of the networking configuration tasks using both tools.

Tip

Using para-virtualized network drivers improves performance on fully virtualized Linux guests. Capítulo 12, Controladores para-virtualizados Xen explains how to utilize para-virtualized network drivers.

11.1. Configuración de varios puentes de red huéspedes para usar varias tarjetas Ethernet

Proceso para configurar puentes de red (con el hipervisor Xen):
  1. Configure otra interfaz de red con la aplicación system-config-network. Como alternativa, cree un nuevo archivo de configuración llamado ifcfg-ethX en el directorio /etc/sysconfig/network-scripts/ donde X es cualquier número que no esté en uso aún. El siguiente es un ejemplo de archivo de configuración para una segunda interfaz de red llamada eth1:
    $ cat /etc/sysconfig/network-scripts/ifcfg-eth1
    DEVICE=eth1
    BOOTPROTO=static
    ONBOOT=yes
    USERCTL=no
    IPV6INIT=no
    PEERDNS=yes
    TYPE=Ethernet
    NETMASK=255.255.255.0
    IPADDR=10.1.1.1
    GATEWAY=10.1.1.254
    ARP=yes
    
  2. Copie el archivo /etc/xen/scripts/network-bridge, a /etc/xen/scripts/network-bridge.xen.
  3. Comment out any existing network scripts in /etc/xen/xend-config.sxp and add the line (network-xen-multi-bridge). A typical xend-config.sxp file should have the following line. Comment this line out. Use the # symbol to comment out lines.
    network-script network-bridge
    
    Below is the commented out line and the new line, containing the network-xen-multi-bridge parameter to enable multiple network bridges.
    #network-script network-bridge
    network-script network-xen-multi-bridge
  4. Create a script to create multiple network bridges. This example creates a script called network-xen-multi-bridge.sh in the /etc/xen/scripts/ directory. A sample scripts is below, this example script will create two Xen network bridges (xenbr0 and xenbr1) one will be attached to eth1 and the other one to eth0. If you want to create additional bridges just follow the example in the script and copy nad paste the lines as required:
    #!/bin/sh
    # network-xen-multi-bridge
    # Exit if anything goes wrong.
    set -e
    # First arg is the operation.
    OP=$1
    shift
    script=/etc/xen/scripts/network-bridge.xen
    case ${OP} in
    start)
    	$script start vifnum=1 bridge=xenbr1 netdev=eth1
    	$script start vifnum=0 bridge=xenbr0 netdev=eth0
    	;;
    stop)
    	$script stop vifnum=1 bridge=xenbr1 netdev=eth1
    	$script stop vifnum=0 bridge=xenbr0 netdev=eth0
    	;;
    status)
    	$script status vifnum=1 bridge=xenbr1 netdev=eth1
    	$script status vifnum=0 bridge=xenbr0 netdev=eth0
    	;;
    *)
    	echo 'Unknown command: ' ${OP}
    	echo 'Valid commands are: start, stop, status'
    	exit 1
    esac
    
  5. Make the script executable.
    # chmod +x /etc/xen/scripts/network-xen-multi-bridge.sh
  6. Restart networking or restart the system to activate the bridges.
    # service network restart
Multiple bridges should now be configured for guests on the Xen hypervisor.

11.2. Configuración de redes de portátil de Red Hat Enterprise Linux 5.0

For Red Hat Enterprise Linux 5.1 o posterior

Esta sección describe la adición manual de puentes de red. Este procedimiento no se requiere ni se recomienda para todas las versiones de Red Hat Enterprise Linux posteriores a la versión 5.0. Para versiones posteriores use adaptadores de "Red virtual" al crear huéspedes en virt-manager. NetworkManager funciona con dispositivos de red virtuales predeterminados en Red Hat Enterprise Linux 5.1 y posteriores.
Un ejemplo de un archivo de configuración virsh XML para dispositivo de redes virtuales:
<interface type='network'>
	<mac address='AA:AA:AA:AA:AA:AA'/>
	<source network='default'/>
	<target dev='vnet0'/>
	<model type='virtio'/>
</interface>
En archivos de configuración xm, los dispositivos de red virtuales se etiquetan "vif".
The challenge in running the Xen hypervisor on a laptop is that most laptops will connected to the network via wireless network or wired connections. Often these connections are switched multiple times a day. In such an environment, the system assumes it has access to the same interface all the time and it also can perform ifup or ifdown calls to the network interface it is using. In addition wireless network cards do not work well in a virtualization environment due to Xen's (default) bridged network usage.
Este montaje también permite ejecutar Xen en modo desconectado cuando no se tenga una conexión de red activa en el portátil. La solución más fácil para ejecutar Xen en un portátil es seguir el siguiente procedimiento:
  • You will be configuring a 'dummy' network interface which will be used by Xen. In this example the interface is called dummy0. This will also allow you to use a hidden IP address space for your guests.
  • Será necesario utilizar la dirección IP estática como DHCP no escuchará en la interfaz tonta para solicitudes de DCHP. Se puede compilar su propia versión de DCHP para escuchar las interfaces tontas, sin embargo, puede desear mirar en dnsmasq para servicios de DNS, DHCP y tftpboot en un entorno Xen. El montaje y configuración se describen más adelante en esta sección/capítulo.
  • También puede configurar NAT y enmascarar IP con el fin de dar acceso a la red desde sus huéspedes.
Configuración de una interfaz de red tonta
Realizar los siguientes pasos de configuración en su host:
  1. Cree una interfaz de red dummy0 y asígnele una dirección IP estática. En nuestro ejemplo se seleccionó 10.1.1.1 para evitar problemas de enrutamiento en nuestro entorno. Para permitir el soporte de dispositivo tonto añada las siguientes líneas a /etc/modprobe.conf:
    alias dummy0 dummy
    options dummy numdummies=1
    
  2. Para configurar redes para dummy0 edite o cree /etc/sysconfig/network-scripts/ifcfg-dummy0:
    DEVICE=dummy0
    BOOTPROTO=none
    ONBOOT=yes
    USERCTL=no
    IPV6INIT=no
    PEERDNS=yes
    TYPE=Ethernet
    NETMASK=255.255.255.0
    IPADDR=10.1.1.1
    ARP=yes
    
  3. Vincule xenbr0 a dummy0, para poder utilizar las redes incluso cuando no esté conectado a una red física. Edite /etc/xen/xend-config.sxp para incluir la entrada netdev=dummy0:
    (network-script 'network-bridge bridge=xenbr0 netdev=dummy0')
    
  4. Open /etc/sysconfig/network in the guest and modify the default gateway to point to dummy0. If you are using a static IP, set the guest's IP address to exist on the same subnet as dummy0.
    NETWORKING=yes
    HOSTNAME=localhost.localdomain
    GATEWAY=10.1.1.1
    IPADDR=10.1.1.10
    NETMASK=255.255.255.0
    
  5. Configurar la NAT en el host permitirá a los huéspedes acceder a Internet, incluyendo el acceso inalámbrico, resolviendo los problemas de tarjetas Xen e inalámbricas. El script a continuación permitirá la NAT basada en la interfaz actualmente usada para su conexión de redes.
Configuración de NAT para huéspedes virtualizados
La traducción de dirección de red (NAT) permite a varias direcciones de red conectarse a través de una dirección IP única, interceptando paquetes y pasándolos a direcciones IP privadas. Puede copiar el siguiente script a /etc/init.d/xenLaptopNAT y crear un enlace blando para /etc/rc3.d/S99xenLaptopNAT. Así se inicia automáticamente NAT en tiempo de arranque.

NetworkManager y NAT inalámbrica.

El script a continuación puede que no funcione bien con redes inalámbricas o NetworkManager debido a retrasos en el arranque. En este caso ejecute el script de forma manual una vez haya arrancado la máquina.
#!/bin/bash
PATH=/usr/bin:/sbin:/bin:/usr/sbin
export PATH
GATEWAYDEV=`ip route | grep default | awk {'print $5'}`
iptables -F
case "$1" in
start)
	if test -z "$GATEWAYDEV"; then
	echo "No gateway device found"
    else
	echo  "Masquerading using $GATEWAYDEV"
	/sbin/iptables -t nat -A POSTROUTING -o $GATEWAYDEV -j MASQUERADE
fi
	echo "Enabling IP forwarding"
	echo 1 > /proc/sys/net/ipv4/ip_forward
	echo "IP forwarding set to `cat /proc/sys/net/ipv4/ip_forward`"
	echo "done."
	;;
*)
echo "Usage: $0 {start|restart|status}"
;;
esac
Configuración de dnsmasq para los servicios DNS, DHCP y tftpboot
Uno de los retos al ejecutar virtualización en un portátil (o en cualquier otro computador que no esté conectado por una conexión de red estable o única) es el cambio en interfaces de red y la disponibilidad. El uso de una interfaz de red tonta ayuda a construir un entorno más estable, pero a su vez, brinda algunos desafíos al proporcionar los servicios DHCP, DNS y tftpboot para las máquinas /huéspedes virtuales. El demonio predeterminado DHCP, distribuido con Red Hat Enterprise Linux y Fedora Core, no escuchará interfaces tontas, su información de reenvío de DNS puede cambiar al conectarse a diferentes redes y VPN.
Una solución para los retos anteriores es utilizar dnsmasq, el cual proporciona todos los servicios mencionados anteriormente, en un solo paquete y también permitirá controlar su servicio sólo cuando está disponible a solicitudes desde la interfaz tonta. La siguiente es una breve redacción sobre cómo configurar dnsmasq en un portátil ejecutando virtualización:
  • Obtenga la última versión de dnsmasq desde aquí.
  • Documentation for dnsmasq can be found here.
  • Copy the other files referenced below from http://et.redhat.com/~jmh/tools/xen/ and grab the file dnsmasq.tgz. The tar archive includes the following files:
    • nm-dnsmasq puede utilizarse como un script despachador para NetworkManager. Se ejecutará cada vez que NetworkManager detecte un cambio en conectividad y fuerce un reinicio/carga de dnsmasq. Este archivo se debe copiar a /etc/NetworkManager/dispatcher.d/nm-dnsmasq
    • xenDNSmasq puede ser utilizado como el arranque principal o el cierre del script para /etc/init.d/xenDNSmasq
    • dnsmasq.conf es una muestra de un archivo de configuración para /etc/dnsmasq.conf
    • dnsmasq es la imagen binaria para /usr/local/sbin/dnsmasq
  • Una vez que haya desempacado y creado una instalación dnsmasq (la instalación predeterminada será la binaria dentro /usr/local/sbin/dnsmasq), necesitará editar su archivo de configuración dnsmasq. El archivo se localiza en /etc/dnsmaqs.conf
  • Editar la configuración para que se ajuste a sus necesidades y requerimientos locales. Los siguientes parámetros son probablemente los que desea modificar.
    • El parámetro interface permite a dnsmasq estar atento a solicitudes DHCP y DNS sólo en interfaces especificadas. Pueden ser interfaces tontas, pero no interfaces públicas como también la interfaz local de loopback. Añada otra línea de interface para más de una interfaz. interface=dummy0 es un ejemplo que escucha en la interfaz dummy0.
    • dhcp-range para habilitar al servidor integrado DHCP, se necesita proveer el rango de direcciones disponibles para arrendamiento y opcionalmente, un tiempo de arrendamiento. Si se tiene más de una red, será necesario repetir esto para cada red en la cual se desea proporcionar el servicio DHCP. Un ejemplo sería (para red 10.1.1.* y tiempo de arrendamiento de 12horas): dhcp-range=10.1.1.10,10.1.1.50,255.255.255.0,12h
    • dhcp-option para sobrescribir la ruta predeterminada proporcionada por dnsmasq, la cual supone que la ruta es la misma máquina que está ejecutando dnsmasq. Un ejemplo sería dhcp-option=3,10.1.1.1
  • Después de configurar dnsmasq puede copiar el script a continuación como xenDNSmasq para /etc/init.d
  • Si desea iniciar automáticamente dnsmasq durante el arranque del sistema deberá registrarlo mediante chkconfig(8):
    chkconfig --add xenDNSmasq
    
    Actívelo para iniciar de modo automático:
    chkconfig --levels 345 xenDNSmasq on
    
  • Para configurar dnsmasq para reiniciar cada vez que NetworkManager detecte un cambio en conectividad, se puede usar el script proporcionado nm-dnsmasq.
    • Copie el script nm-dnsmasq a /etc/NetworkManager/dispatcher.d/
    • El despachador de NetworkManager ejecutará el script (en orden alfabético si usted tiene scripts en el mismo directorio) cada vez que haya un cambio en conectividad
  • dnsmasq también detectará cambios en su archivo /etc/resolv.conf y los volverá a cargar automáticamente (es decir, si usted inicia una sesión VPN, por ejemplo).
  • Ambos scripts nm-dnsmasq y xenDNSmasq también configurarán NAT si usted tiene huéspedes virtualizados en una red oculta para permitirles acceder a la red pública.

Capítulo 12. Controladores para-virtualizados Xen

Para-virtualized drivers provide increased performance for fully virtualized Red Hat Enterprise Linux guests. Use these drivers if you are using fully virtualized Red Hat Enterprise Linux guests and require better performance.

Otros controladores para-virtualizados

Hay otros controladores para-virtualizados para Windows para hipervisores de Xen y KVM.
Para huéspedes de Windows en huéspedes Xen, consulte La Guía de controladores para-virtualizados de Windows, la cual cubre instalación y administración.
For Windows guests on KVM hosts, refer to Capítulo 13, Controladores KVM para-virtualizados.
Los paquetes RPM para controladores para-virtualizados incluyen los módulos de almacenamiento y controladores de red para-virtualizados para los sistemas operativos del huésped soportado de Red Hat Enterprise Linux. Estos controladores permiten un alto rendimiento de operaciones de E/S en sistemas no modificados de sistemas operativos de huésped de Red Hat Enterprise Linux en un huésped de Red Hat Enterprise Linux 5.1 (o posterior).
Los sistemas operativos de huésped soportados son:
  • Red Hat Enterprise Linux 3
  • Red Hat Enterprise Linux 4
  • Red Hat Enterprise Linux 5

Soporte de arquitectura para controladores para-virtualizados.

Los requisitos de sistema operativo mínimos dependen de la arquitectura. Sólo los huéspedes x86 y x86-64 están soportados.
Los controladores no están soportados en el huésped de Red Hat Enterprise Linux anterior a Red Hat Enterprise Linux 3.
Utilizar Red Hat Enterprise Linux 5 como plataforma de virtualización, permite a los administradores de sistemas consolidar las cargas de Linux y Windows en hardware más moderno y potente con energía aumentada y eficacia de enfriamiento. Red Hat Enterprise Linux 4 (a partir de la actualización 6) y los sistemas operativos de huésped de Red Hat Enterprise Linux 5, reconocen la tecnología de virtualización subyacente y pueden interactuar eficazmente con ella utilizando interfaces y capacidades específicas. Este enfoque puede producir rendimiento similar y características de rendimiento similar a la ejecución en el sistema bare metal.
As para-virtualization requires a modified guest operating system, not all operating systems can use para-virtualization. For operating systems which can not be modified, full virtualization is required. Full virtualization, by default, uses emulated disk, network, video and other hardware devices. Emulated I/O devices can be very slow and are not suited for applications requiring high disk and/or network throughput. The majority of the performance loss with virtualization occurs through the use of emulated devices.
Los controladores de dispositivos para-virtualizados están incluidos en los paquetes de Red Hat Enterprise Linux. Los controladores ofrecen muchas ventajas de sistemas operativos de huésped para-virtualizados a sistemas operativos sin modificar, debido a que únicamente el controlador de dispositivos para-virtualizados (no el resto del sistema operativo) tiene conocimiento de la plataforma de virtualización subyacente.
Después de la instalación de controladores de dispositivos para-virtualizados, un dispositivo de disco o una tarjeta de red pueden aparecerán como normales. Sin embargo, ahora el dispositivo interactúa directamente con la plataforma de virtualización (sin emulación) para entregar de modo eficiente acceso a red y disco, permitiendo a subsistemas de red y disco funcionar a velocidades originales incluso en un entorno virtualizado, sin requerir cambios en los sistemas operativos existentes.
Los controladores para-virtualizados tienen algunos requerimientos de huésped. Los hosts de 64 bits pueden ejecutar:
  • Huéspedes de 32 bits.
  • Huéspedes de 64 bits.
  • Una mezcla de huéspedes de 32 y 64 bits.

12.1. Requerimientos del sistema

Esta sección proporciona los requerimientos para controladores para-virtualizados con Red Hat Enterprise Linux.
Instalación
Antes de instalar los controladores para-virtualizados, se deben cumplir los siguientes requerimientos:

Red Hat Enterprise Linux 4.7, 5.3 y más recientes

Toda versión de Red Hat Enterprise Linux desde 4.7 y 5.3 tiene el módulo de kernel para los controladores para-virtualizados, el módulo pv-on-hvm, en el paquete de kernel predeterminado. Es decir, que los controladores para-virtualizados están disponibles para huéspedes de Red Hat Enterprise Linux 4.7 y más recientes o 5.3 y posteriores.
Necesitará los siguientes paquetes RPM para controladores para-virtualizadas para cada instalación de sistema operativo de huésped.
Minimum host operating system version:
  • Red Hat Enterprise Linux 5.1 or newer.
Minimum guest operating system version:
  • Red Hat Enterprise Linux 5.1 or newer.
  • Red Hat Enterprise Linux 4 Update 6 or newer.
  • Red Hat Enterprise Linux 3 Update 9 or newer.
Red Hat Enterprise Linux 5 requires:
  • kmod-xenpv.
Red Hat Enterprise Linux 4 requires:
  • kmod-xenpv,
  • modules-init-tools (for versions prior to Red Hat Enterprise Linux 4.6z you require modules-init-tools-3.1-0.pre5.3.4.el4_6.1 or greater), and
  • modversions.
Red Hat Enterprise Linux 3 requires:
  • kmod-xenpv.
You require at least 50MB of free disk space in the /lib file system.

12.2. Restricciones y soporte de para-virtualización

Esta sección presenta las restricciones de soporte y los requerimientos para usar controladores para-virtualizados en Red Hat Enterprise Linux. Nuestro soporte y restricciones al soporte se encuentran en las secciones a continuación.
Sistemas de operativos de huésped soportados
El soporte para controladores para-virtualizados está disponible para los sistemas operativos y versiones siguientes:
  • Red Hat Enterprise Linux 5.1 y más recientes.
  • Actualización 6 de Red Hat Enterprise Linux 4 y más recientes.
  • Actualización 9 de Red Hat Enterprise Linux 3 y más recientes.
Usted está soportado para ejecutar un sistema operativo de huésped de 32 bits con controladores para-virtualizados en Red Hat Enterprise Linux 5 Virtualization de 64 bits.
La tabla a continuación indica las variantes de kernel soportadas con los controladores virtualizados. Puede utilizar el comando de abajo para identificar la revisión exacta de kernel actualmente instalada en su host. Compare la salida con la tabla para determinar si está soportada.
# rpm -q --queryformat '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' kernel
Las variantes de kernel de Red Hat Enterprise Linux 5 i686 y x86_64 incluyen Multi-procesamiento simétrico (SMP), no se requiere ningún SMP independiente para RPM de kernel.
Tome notas de los requerimientos de kernel específicos para huéspedes de Red Hat Linux 3 en la tabla a continuación:
Tabla 12.1. Arquitecturas de kernel con huésped soportado para controladores para-virtualizados
Arquitectura de kernel Red Hat Enterprise Linux 3 Red Hat Enterprise Linux 4 Red Hat Enterprise Linux 5
athlon Soportadas (AMD)   
athlon-SMP Soportadas (AMD)   
i32e Soportadas(Intel)   
i686 Soportadas(Intel) Soportadas Soportadas
i686-PAE Soportadas
i686-SMP Soportadas(Intel) Soportadas  
i686-HUGEMEM Soportadas(Intel) Soportadas  
x86_64 Soportadas (AMD) Soportadas Soportadas
x86_64-SMP Soportadas (AMD) Soportadas  
x86_64-LARGESMP Soportadas  
Itanium (IA64) Soportadas

Importante

El sistema de host requiere Red Hat Enterprise Linux 5.1 o más reciente.

Cómo sabe cuál kernel está utilizando

Escriba la salida de su comando abajo o memorícela. Este es el valor que determina qué paquetes y módulos usted necesita descargar.
# rpm -q --queryformat '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' kernel
La salida será similar a la siguiente:
kernel-PAE-2.6.18-53.1.4.el5.i686
El nombre del kernel es PAE, sigla para Physical Address Extensions (Extensiones de dirección físicas), la versión de kernel es 2.6.18, el lanzamiento es 53.1.4.el5 y la arquitectura es i686. El RPM de kernel debe siempre estar en formato kernel-name-version-release.arch.rpm.
Restricciones importantes
Los controladores de dispositivos para-virtualizados pueden ser instalados después de instalar correctamente un sistema operativo huésped. Necesitará un host y huésped funcionando antes de instalar estos controladores.

Controladores de bloque para-virtualizados y GRUB

GRUB no puede en este momento, acceder a dispositivos de bloque para-virtualizados. Por lo tanto, un huésped no puede arrancar desde un dispositivo que usa controladores de dispositivo de bloque para-virtualizados. Específicamente, el disco que contiene el Registro de arranque principal o MBR, el disco que contiene el cargador de gestor de arranque (GRUB), o un disco que contiene las imágenes de kernel initrd. Es decir, cualquier disco que contenga el directorio o la partición de /boot no puede usar controladores de dispositivos de bloque para-virtualizados.
Dependencias de arquitectura de la variante de kernel de Red Hat Enterprise Linux 3
Para sistemas operativos de huésped basados en Red Hat Enterprise Linux 3, debe usar el kernel específico del procesador y los RPM del controlador para-virtualizado como se puede ver en las tablas abajo. Si la instalación falla, la descarga del paquete de controlador para-virtualizado coincidente del módulo xen-pci-platform fallará.
La tabla a continuación muestra que el kernel de host es requerido para ejecutar en un huésped de Red Hat Enterprise Linux 3 si el huésped fue compilado para un procesador de Intel.
Tabla 12.2. Arquitectura de kernel requerida para huéspedes que utilizan controladores para-virtualizados en Red Hat Enterprise Linux 3 para procesadores Intel
Tipo de kernel de huésped Tipo de kernel de huésped requerido
ia32e (UP y SMP) x86_64
i686 i686
i686-SMP i686
i686-HUGEMEM i686

La tabla a continuación muestra cuál kernel de host es requerido para ejecutar un huésped de Red Hat Enterprise Linux 3 si el huésped fue compilado para un procesador de AMD.
Tabla 12.3. Arquitecturas requeridas de kernel de host para huéspedes que utilizan controladores para-virtualizados en Red Hat Enterprise Linux 3 para procesadores AMD.
Tipo de kernel de huésped Tipo de kernel de huésped requerido
athlon i686
athlon-SMP i686
x86_64 x86_64
x86_64-SMP x86_64

12.3. Instalación de controladores para-virtualizados

Los siguientes tres capítulos describen cómo instalar y configurar sus huéspedes completamente virtualizados para que se ejecuten en Red Hat Enterprise Linux 5.1 o posteriores con controladores para-virtualizados.

Antes de proseguir, verifique si su arquitectura sea compatible

Los controladores para-virtualizados sólo son compatibles con algunas combinaciones de versiones y hardware. Verifique que los requerimientos de su sistema operativo y hardware se cumplan antes de proseguir a instalar controladores para-virtualizados.

Utilizar al máximo los beneficios de los controladores de paravirtualización para nuevas instalaciones

Si está instalando un nuevo sistema de huésped, para obtener máximo beneficio de los controladores de dispositivo de bloque para-virtualizados, cree el huésped con al menos dos discos.
Utilizar los controladores para-virtualizados para el disco que contiene el MBR y el gestor de arranque (GRUB), y para la partición de /boot. Esta partición puede ser muy pequeña, puesto que sólo necesita la capacidad suficiente para guardar la partición de /boot.
Use el segundo disco y los discos adicionales para todas las particiones (por ejemplo, /, /usr) o volúmenes lógicos.
Utilizar este método de instalación cuando los controladores de dispositivos de bloque para-virtualizados sean instalados después de completar la instalación del huésped, sólo al arrancar el huésped y acceder a la partición de /boot utilizará los controladores de dispositivos de bloque para-virtualizados.

12.3.1. Pasos comunes de instalación

La lista a continuación contiene los pasos comunes de nivel superior en todas las versiones de sistemas operativos.
  1. Copy the RPMs for your hardware architecture to a suitable location in your guest operating system. Your home directory is sufficient. If you do not know which RPM you require verify against the table at Sección 12.2, “Restricciones y soporte de para-virtualización”.
  2. Use los comandos rpm o yum para instalar los paquetes. La utilidad rpm instalará los cuatro nuevos módulos de kernel en /lib/modules/[%kversion][%kvariant]/extra/xenpv/%release:
    • the PCI infrastructure module, xen_platform_pci.ko,
    • the ballooning module, xen_balloon.ko,
    • the virtual block device module, xen_vbd.ko,
    • and the virtual network device module, xen_vnif.ko.
  3. Si el huésped en ejecución no soporta automáticamente cargar los controladores para-virtualizados (por ejemplo, Red Hat Enterprise Linux 3), realice los pasos requeridos post-instalación para copiar los controladores en los sitios específicos del sistema que está operando.
  4. Apague su sistema operativo de huésped
  5. Reconfigure the guest operating system's configuration file on the host to use the installed para-virtualized drivers.
  6. Elimine la entrada “type=ioemu” para el dispositivo de red.
  7. Add any additional disk partitions, volumes or LUNs to the guest so that they can be accessed via the para-virtualized (xen-vbd) disk driver.
  8. For each physical device, LUN, partition or volume you want to use the para-virtualized drivers you must edit the disk entry for that device in the libvirt configuration file.
  9. A typical disk entry resembles the following:
    <disk type='file' device='disk'>
      <driver name='file'/>
      <source file='/dev/hda6'/>
      <target dev='hda'/>
    </disk>
    
    Modify each disk entry, as desired, to use the para-virtualized by changing the driver elements as shown below.
    <disk type='file' device='disk'>
      <driver name='tap' type='aio'/>
      <source file='/dev/hda6'/>
      <target dev='xvda'/>
    </disk>
    
  10. Añada las entidades de almacenaje que desea utilizar para el controlador de dispositivo de bloque para-virtualizado.
  11. Reinicie su huésped:
    # xm start YourGuestName
    Where YourGuestName is the name of the configuration file or the guest operating system's name as defined in its configuration file in the name = "os_name" parameter.
  12. Reconfigure the guest network.

12.3.2. Instalación y configuración de controladores para-virtualizados en Red Hat Enterprise Linux 3

Esta sección contiene instrucciones detalladas para los controladores para-virtualizados en un sistema operativo de huésped de Red Hat Enterprise 3.

Nota

Estos paquetes no soportan arranque desde un disco para-virtualizado. El arranque del sistema operativo de kernel de huésped aún requiere el uso del controlador emulado IDE, mientras que cualquier otra aplicación de espacio de usuario (no de sistema) y datos pueden utilizar los controladores de dispositivo de bloque para-virtualizados.
Instalación de controlador
La lista a continuación cubre los pasos para instalar un huésped de Red Hat Enterprise Linux 3 con controladores para-virtualizados.
  1. Install the latest kernel version. The para-virtualized drivers require at least Red Hat Enterprise Linux 3.9 kernel version kernel-2.4.21-60.EL for all the required headers.
  2. Copie el RPM de kmod-xenpv para su arquitectura de hardware y variante de kernel a su sistema operativo de huésped.
  3. Use la utilidad rpm para instalar los paquetes de RPM. Asegúrese de haber identificado correctamente qué paquete necesita para su variante de sistema operativo huésped y arquitectura.
    [root@rhel3]# rpm -ivh kmod-xenpv*
    
  4. Use the commands below load the para-virtualized driver modules. %kvariant is the kernel variant the para-virtualized drivers have been build against and %release corresponds to the release version of the para-virtualized drivers.
    [root@rhel3]# mkdir -p /lib/modules/'uname -r'/extra/xenpv
    [root@rhel3]# cp -R /lib/modules/2.4.21-52.EL[%kvariant]/extra/xenpv/%release \
    /lib/modules/'uname -r'/extra/xenpv
    [root@rhel3]# depmod -ae
    [root@rhel3]# modprobe xen-vbd
    [root@rhel3]# modprobe xen-vnif
    

    Nota

    Las advertencias serán generadas por insmod al instalar los módulos del controlador binario debido a MODVERSIONS de Red Enterprise Linux está habilitado. Estas advertencias pueden pasarse por alto.
  5. Verifique /etc/modules.conf y asegúrese de tener un alias para eth0 como el de abajo. Si está planeando configurar interfaces múltiples, añada una línea para cada interfaz.
    alias eth0 xen-vnif
    
    Edite /etc/rc.local y añada la línea:
    insmod /lib/modules/'uname -r'/extra/xenpv/%release/xen-vbd.o
    

    Nota

    Substituya “%lanzamiento” por la versión actual de lanzamiento (por ejemplo 0.1-5.el) para los controladores para-virtualizados. Si actualiza el controlador para-virtualizado, asegúrese de actualizar la versión de lanzamiento a la versión correcta.
  6. Apague la máquina virtual (use “#shutdown -h now” dentro del huésped).
  7. Edit the guest configuration file in /etc/xen/YourGuestName with a text editor, performing the following changes:
    • Elimine la entrada “type=ioemu” de la entradas “vif=”.
    • Añada las particiones de disco adicionales, los volúmenes o LUN al huésped para poder acceder a ellos a través del controlador de disco para-virtualizado (xen-vbd).
    • For each physical device, LUN, partition or volume you want to use the para-virtualized drivers you must edit the disk entry for that device in the libvirt configuration file.
    • A typical disk entry resembles the following:
      <disk type='file' device='disk'>
        <driver name='file'/>
        <source file='/dev/hda6'/>
        <target dev='hda'/>
      </disk>
      
      Modify each disk entry, as desired, to use the para-virtualized by changing the driver elements as shown below.
      <disk type='file' device='disk'>
        <driver name='tap' type='aio'/>
        <source file='/dev/hda6'/>
        <target dev='xvda'/>
      </disk>
      
      
    • Once complete, save the modified configuration file and restart the guest.
  8. Boot the virtual machine:
    # xm start YourGuestName
    Where YourGuestName is the name of the configuration file or the guest operating system's name as defined in its configuration file in the name = "os_name" parameter.

Tenga presente que

Los controladores para-virtualizados no se agregan y cargan al sistema automáticamente porque no se proporciona soporte para weak-modules y modversions en Red Hat Enterprise Linux 3. Para insertar el módulo, ejecute el siguiente comando:
insmod xen_vbd.ko
Red Hat Enterprise Linux 3 requiere la creación manual de los archivos especiales para dispositivos de bloque que utilizan xen-vbd. Los pasos a continuación cubren cómo crear y registrar los dispositivos de bloque para-virtualizados.
Use el siguiente script para crear los archivos especiales después de que el controlador de dispositivo de bloque para-virtualizado sea cargado.
#!/bin/sh
module="xvd"
mode="664"
major=`awk "\\$2==\"$module\" {print \\$1}" /proc/devices`
# < mknod for as many or few partitions on xvd disk attached to FV guest >
# change/add xvda to xvdb, xvbd, etc. for 2nd, 3rd, etc., disk added in
# in xen config file, respectively.
mknod /dev/xvdb b $major 16
mknod /dev/xvdb1 b $major 17
mknod /dev/xvdb2 b $major 18
chgrp disk /dev/xvd*
chmod 0660 /dev/xvd*
Para cada disco virtual adicional, incremente el número menor por 16. En el ejemplo a continuación, un dispositivo adicional, de número menor 16, es creado.
# mknod /dev/xvdc b $major 16
# mknod /dev/xvdc1 b $major 17
Esto haría que el próximo dispositivo sea 32 que puede ser creado por:
# mknod /dev/xvdd b $major 32
# mknod /dev/xvdd1 b $major 33
Ahora debe verificar que las particiones que ha creado, estén disponibles.
[root@rhel3]# cat /proc/partitions
major   minor     #blocks   name

  3        0      10485760  hda
  3        1        104391  hda1
  3        2      10377990  hda2
202        16         64000  xvdb
202        17         32000  xvdb1
202        18        32000  xvdb2
253        0       8257536  dm-0
253        1       2031616  dm-1
En la salida anterior, puede observar que el dispositivo dividido “xvdb” está disponible para el sistema.
El procedimiento a continuación, añade el nuevo dispositivo al huésped y lo hace persistente tras el reinicio. Todos estos comandos se ejecutan en el huésped.
  1. Crea directorios en donde se monta la imagen de dispositivo de bloque.
    [root@rhel3]# mkdir /mnt/pvdisk_p1
    [root@rhel3]# mkdir /mnt/pvdisk_p2
    
  2. Monta los dispositivos a las nuevas carpetas.
    [root@rhel3]# mount /dev/xvdb1 /mnt/pvdisk_p1
    [root@rhel3]# mount /dev/xvdb2 /mnt/pvdisk_p2
    
  3. Verifica si los dispositivos están montados correctamente.
    [root@rhel3]# df /mnt/pvdisk_p1
    Filesystem           1K-blocks      Used   Available Use%  Mounted on
    /dev/xvdb1               32000        15       31985   1%  /mnt/pvdisk_p1
    
  4. Actualiza el archivo /etc/fstab dentro del huésped para montar los dispositivos durante la secuencia de arranque. Añada las siguientes líneas:
    /dev/xvdb1   /mnt/pvdisk_p1   ext3    defaults        1 2
    /dev/xvdb2   /mnt/pvdisk_p2   ext3    defaults        1 2
    

Consejo de rendimiento

Using a Red Hat Enterprise Linux 5.1 host (dom0), the "noapic" parameter should be added to the kernel boot line in your virtual guest's /boot/grub/grub.conf entry as seen below. Keep in mind your architecture and kernel version may be different.
kernel /vmlinuz-2.6.9-67.EL ro root=/dev/VolGroup00/rhel4_x86_64 rhgb noapic
Un dom0 de Red Hat Enterprise Linux 5.2 no necesitará este parámetro de kernel para huésped.

Importante

Los paquetes RPM binarios de Itanium (ia64) y los diseños no están disponibles actualmente.

12.3.3. Instalación y configuración de controladores para-virtualizados en Red Hat Enterprise Linux 4

Esta sección contiene instrucciones detalladas para controladores para-virtualizados en un sistema operativo de huésped de Red Hat Enterprise 4.

Nota

Estos paquetes no soportan arranque desde un disco para-virtualizado. El arranque del kernel del sistema operativo de huésped aún requiere el uso de controlador emulado IDE, aunque otras aplicaciones de espacio de usuario (no- sistema) y datos pueden usar los controladores de dispositivo de bloque para-virtualizados.
Instalación de controlador
La lista que aparece a continuación cubre los pasos para instalar un huésped de Red Hat Enterprise Linux 4 con controladores para-virtualizados.
  1. Copie los RPM kmod-xenpv, modules-init-tools y modversions para su variante de arquitectura y kernel de hardware de su sistema operativo de huésped.
  2. Use la utilidad de rpm para instalar los paquetes RPM. Asegúrese de haber identificado correctamente el paquete que necesita para su variante de sistema operativo de huésped y arquitectura. Se requiere un 'module-init-tools' actualizado para este paquete, el cual está disponible con el kernel de Red Hat Enterprise Linux 4-6-z o más reciente.
    [root@rhel4]# rpm -ivh modversions
    [root@rhel4]# rpm -Uvh module-init-tools
    [root@rhel4]# rpm -ivh kmod-xenpv*
    

    Nota

    Existen diferentes paquetes UP, SMP, Hugemem y arquitecturas, así que asegúrese de que los RPM sean los adecuados para su kernel.
  3. Execute cat /etc/modprobe.conf to verify you have an alias for eth0 like the one below. If you are planning to configure multiple interfaces add an additional line for each interface. If it does not look like the entry below change it.
    alias eth0 xen-vnif
    
  4. Apague la máquina virtual (utilice “#shutdown -h now” dentro del huésped).
  5. Edite el archivo de configuración en /etc/xen/YourGuestsName de la siguiente manera:
    • Elimine la entrada “type=ioemu” desde la entrada “vif=”.
    • Añada particiones de disco adicionales, volúmenes o LUN al huésped para que puedan ser accedidos a través de un controlador de disco para-virtualizado (xen-vbd).
    • Para cada dispositivo físico adicional, LUN, partición o volumen, agregue una entrada similar a la que se muestra debajo de la sección “disk=” en el archivo de configuración de huésped. La entrada original “disk=” podría verse como la entrada siguiente.\t
      disk = [ "file:/var/lib/libvirt/images/rhel4_64_fv.dsk,hda,w"]
      
    • Una vez que haya agregado dispositivos físicos, LUN, particiones o volúmenes; la entrada de controladores para-virtualizados en el archivo de configuración XML debe ser similar a la entrada que se muestra a continuación.
      disk = [ "file:/var/lib/libvirt/images/rhel3_64_fv.dsk,hda,w",
      "tap:aio:/var/lib/libvirt/images/UserStorage.dsk,xvda,w" ]
      

      Nota

      Use “tap:aio”para el dispositivo para-virtualizado si se utiliza una imagen basada en archivo.
  6. Arranque la máquina virtual mediante el comando virsh:
    # virsh start YourGuestName
En el primer reinicio del huésped virtual, kudzu le pedirá "Mantener o eliminar el dispositivo de red Realtek"y "Configurar el dispositivo de puente-xen". Debe configurar xen-bridge y eliminar el dispositivo de red Realtek.

Consejo de rendimiento

Using a Red Hat Enterprise Linux 5.1 host (dom0), the "noapic" parameter should be added to the kernel boot line in your virtual guest's /boot/grub/grub.conf entry as seen below. Keep in mind your architecture and kernel version may be different.
kernel /vmlinuz-2.6.9-67.EL ro root=/dev/VolGroup00/rhel4_x86_64 rhgb noapic
Un parámetro de Red Hat Enterprise Linux 5.2 dom0 no necesitará este parámetro de kernel para el huésped.
Ahora verifique si las particiones que usted ha creado están disponibles.
[root@rhel4]# cat /proc/partitions
major    minor   #blocks   name

   3        0    10485760  hda
   3        1      104391  hda1
   3        2    10377990  hda2
 202        0       64000  xvdb
 202        1       32000  xvdb1
 202        2       32000  xvdb2
 253        0     8257536  dm-0
 253        1     2031616  dm-1
En la salida anterior, puede ver que el dispositivo dividido en particiones “xvdb” está disponible para el sistema.
El procedimiento a continuación añade el nuevo dispositivo al huésped y lo hace persistente tras el reinicio. Todos estos comandos se ejecutan en el huésped.
  1. Crea directorios en donde se monta la imagen de dispositivos de bloque.
    [root@rhel4]# mkdir /mnt/pvdisk_p1
    [root@rhel4]# mkdir /mnt/pvdisk_p2
    
  2. Monta los dispositivos a las nuevas carpetas.
    [root@rhel4]# mount /dev/xvdb1 /mnt/pvdisk_p1
    [root@rhel4]# mount /dev/xvdb2 /mnt/pvdisk_p2
    
  3. Verifica si los dispositivos están montados correctamente.
    [root@rhel4]# df /mnt/pvdisk_p1
    Filesystem           1K-blocks      Used   Available Use%  Mounted on
    /dev/xvdb1               32000        15       31985   1%  /mnt/pvdisk_p1
    
  4. Actualiza el archivo /etc/fstab dentro del huésped para montar los dispositivos durante la secuencia de arranque. Añada las siguientes líneas:
    /dev/xvdb1   /mnt/pvdisk_p1   ext3    defaults        1 2
    /dev/xvdb2   /mnt/pvdisk_p2   ext3    defaults        1 2
    

Nota

Este paquete no es compatible con Red Hat Enterprise Linux 4-GA a través de sistemas de Red Hat Enterprise Linux 4 actualización 2 y kernels.

Nota importante

Los paquetes RPM binarios IA64 y prototipos no están disponibles actualmente.

Carga automática de módulo

El controlador xen-vbd puede que no se cargue automáticamente. Ejecute el siguiente comando en el huésped, sustituyendo %release con la versión correcta para controladores para-virtualizados.
# insmod /lib/modules/'uname -r'/weak-updates/xenpv/%release/xen_vbd.ko

12.3.4. Xen Para-virtualized Drivers on Red Hat Enterprise Linux 5

This section contains detailed instructions for the para-virtualized drivers in a Red Hat Enterprise Linux 5 guest operating system.

Nota

Estos paquetes no soportan el arranque desde un disco para-virtualizado. El arranque del sistema operativo huésped aún requiere el uso del controlador emulado IDE, mientras que cualquier otra aplicación y datos de espacio de usuario (no-sistema) puede usar los controladores de dispositivo para-virtualizados.
The procedure below covers the steps to enable the para-virtualized drivers for a Red Hat Enterprise Linux 5 guest.
Procedimiento 12.1. Enable para-virtualized drivers for a Red Hat Enterprise Linux Guest
  1. Apague la máquina virtual (use “#shutdown -h now” dentro del huésped).
  2. Edite el archivo de configuración en /etc/xen/<Your GuestsName> así:
    1. Elimine la entrada “type=ioemu” de la entrada “vif=”.
    2. Añada las particiones de disco adicionales, los volúmenes o LUN al huésped para poder acceder a ellos mediante el controlador de disco para-virtualizado (Xen-vbd).
    3. Para cada dispositivo físico adicional, LUN, partición o volumen añada una entrada a la sección “disk=” en archivo de configuración de huésped. La entrada original de “disk=” podría se también como la siguiente entrada.
      disk = [ "file:/var/lib/libvirt/images/rhel4_64_fv.dsk,hda,w"]
      
    4. Una vez que haya agregado dispositivos físicos, LUN, particiones o volúmenes adicionales; la entrada de controlador para-virtualizado en el archivo de configuración XML debe ser similar a la entrada que se muestra a continuación.
      disk = [ "file:/var/lib/libvirt/images/rhel3_64_fv.dsk,hda,w",
      "tap:aio:/var/lib/libvirt/images/UserStorage.dsk,xvda,w" ]
      

      Nota

      Use “tap:aio” para el dispositivo para-virtualizado si se utiliza una imagen basada en archivo.
  3. Arranque la máquina virtual mediante el comando virsh:
    # virsh start YourGuestName
    
Para comprobar la interfaz de red ha aparecido tras instalar los controladores para-virtualizados ejecute el siguiente comando en el huésped. Debe mostrar la información de interfaz, incluyendo una dirección IP asignada.
[root@rhel5]# ifconfig eth0
Ahora, verifique si las particiones que ha creado están disponibles.
[root@rhel5]# cat /proc/partitions
major minor  #blocks    name
   3     0   10485760   hda
   3     1     104391   hda1
   3     2   10377990   hda2
 202     0      64000   xvdb
 202     1      32000   xvdb1
 202     2      32000   xvdb2
 253     0    8257536   dm-0
 253     1    2031616   dm-1
En la salida anterior, puede ver que el dispositivo dividido “xvdb” está disponible para el sistema.
El procedimiento a continuación añade el nuevo dispositivo al huésped y lo hace persistente tras el reinicio. Todos estos comandos se ejecutan en el huésped.
  1. Crea los directorios en donde se monta la imagen de dispositivos de bloque.
    [root@rhel5]# mkdir /mnt/pvdisk_p1
    [root@rhel5]# mkdir /mnt/pvdisk_p2
    
  2. Monta los dispositivos a las nuevas carpetas.
    [root@rhel5]# mount /dev/xvdb1 /mnt/pvdisk_p1
    [root@rhel5]# mount /dev/xvdb2 /mnt/pvdisk_p2
    
  3. Verifica si los dispositivos están montados correctamente.
    [root@rhel5]# df /mnt/pvdisk_p1
    Filesystem           1K-blocks      Used   Available Use%  Mounted on
    /dev/xvdb1               32000        15       31985   1%  /mnt/pvdisk_p1
    
  4. Actualiza el archivo /etc/fstab dentro del huésped para montar los dispositivos durante la secuencia de arranque. Añada las siguientes líneas:
    /dev/xvdb1   /mnt/pvdisk_p1   ext3    defaults        1 2
    /dev/xvdb2   /mnt/pvdisk_p2   ext3    defaults        1 2
    

Consejo de rendimiento

Using a Red Hat Enterprise Linux 5.1 host (dom0), the "noapic" parameter should be added to the kernel boot line in your virtual guest's /boot/grub/grub.conf entry as seen below. Keep in mind your architecture and kernel version may be different.
kernel /vmlinuz-2.6.9-67.EL ro root=/dev/VolGroup00/rhel4_x86_64 rhgb noapic
El dom0 de Red Hat Enterprise Linux 5.2 no necesita este parámetro de kernel para el huésped.
Hiding fake interfaces
Sometimes, activating the para-virtualized drivers does not delete the old virtualized network interfaces. To remove these interfaces from guests use the following procedure.
  1. Add the following lines to the /etc/modprobe.d/blacklist file. Blacklist 8139cp and 8139too for the RealTek 8139 and e1000 for the virtualized Intel e1000 NIC.
    8139cp
    8139too
    e1000
    
  2. Remove the old network scripts from the /etc/sysconfig/network-scripts directory.
  3. Reboot the guest. The default network interface should now use the para-virtualized drivers.

12.3.5. Xen Para-virtualized Drivers on Red Hat Enterprise Linux 6

This section describes the use of para-virtualized drivers in a Red Hat Enterprise Linux 6 guest.
The para-virtualized drivers are enabled by default for a Red Hat Enterprise Linux 6 guest. The guest will automatically unplug any emulated devices that are presented to it, and will use the para-virtualized drivers instead.
Although the para-virtualized drivers are enabled by default, they can be disabled. Add the following to the guest kernel command line upon boot to disable the para-virtualized drivers:
xen_emul_unplug=never

12.4. Configuración de controlador para-virtualizado de redes

Once the para-virtualized network driver is loaded you may need to reconfigure the guest's network interface to reflect the driver and virtual Ethernet card change.
Realice los siguientes pasos para reconfigurar la interfaz de red dentro del huésped.
  1. En virt-manager abra la ventana de la consola para el huésped e ingrese como root.
  2. En Red Hat Enterprise Linux 4 verifique el archivo /etc/modprobe.conf que contiene la línea “alias eth0 xen-vnif”.
    # cat /etc/modprobe.conf
    alias eth0 xen-vnif
    
  3. To display the present settings for eth0 execute “# ifconfig eth0”. If you receive an error about the device not existing you should load the modules manually as outlined in Sección 36.4, “Cargar manualmente los controladores para- virtualizados”.
    ifconfig eth0
    eth0      Link encap:Ethernet  HWaddr 00:00:00:6A:27:3A  
              BROADCAST MULTICAST  MTU:1500  Metric:1
              RX packets:630150 errors:0 dropped:0 overruns:0 frame:0
              TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000 
              RX bytes:109336431 (104.2 MiB)  TX bytes:846 (846.0 b)
    
  4. Start the network configuration utility(NetworkManager) with the command “# system-config-network”. Click on the “Forward” button to start the network card configuration.
  5. Select the 'Xen Virtual Ethernet Card (eth0)' entry and click 'Forward'.
    Configure the network settings as required.
  6. Complete the configuration by pressing the 'Apply' button.
  7. Press the 'Activate' button to apply the new settings and restart the network.
  8. Ahora verá la nueva interfaz de red con una dirección IP asignada.
    ifconfig eth0
    eth0      Link encap:Ethernet  HWaddr 00:16:3E:49:E4:E0
              inet addr:192.168.78.180  Bcast:192.168.79.255  Mask:255.255.252.0
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:630150 errors:0 dropped:0 overruns:0 frame:0
              TX packets:501209 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000 
              RX bytes:109336431 (104.2 MiB)  TX bytes:46265452 (44.1 MiB)
    

12.5. Configuración de hardware para-virtualizado adicional

Esta sección explicará cómo añadir una red adicional o almacenaje virtual a un sistema operativo de huésped. Para obtener mayor información sobre redes adicionales o recursos de almacenamiento virtual para un sistema operativo de huésped en Red Hat Enterprise Linux 5 Virtualization, por favor lea el documento disponible en Emerging Technologies, Red Hat.com

12.5.1. Interfaces de red virtualizadas

Realice los siguientes pasos para configurar dispositivos de red adicionales para su huésped.
Edite su archivo de configuración en /etc/xen/YourGuestName remplazando YourGuestName por su nombre de huésped.
La entrada original puede verse como la siguiente:
vif = [ "mac=00:16:3e:2e:c5:a9,bridge=xenbr0" ]
Añada una entrada adicional a la sección “vif=” del archivo de configuración, similar a la siguiente:
vif = [ "mac=00:16:3e:2e:c5:a9,bridge=xenbr0",
    "mac=00:16:3e:2f:d5:a9,bridge=xenbr0" ]
Asegúrese de generar una dirección única MAC para la nueva interfaz. Puede usar el comando a continuación.
# echo 'import virtinst.util ; print virtinst.util.randomMAC()' | python
Después de reiniciar, realice el siguiente paso en el sistema operativo de huésped. Verifique que a actualización haya sido agregada a /etc/modules.conf en Red Hat Enterprise Linux 3 o /etc/modprobe.conf en Red Hat Enterprise Linux 4 y Red Hat Enterprise Linux 5. Añada un alias a cada nueva interfaz agregada.
alias eth1 xen-vnif
Ahora, pruebe cada interfaz nueva que haya agregado para asegurarse de que está disponible dentro del huésped.
# ifconfig eth1
El comando anterior debe mostrar las propiedades de eth1, repita el comando para eth2 si agregó una tercera interfaz y así sucesivamente.
Ahora puede configurar las nuevas interfaces de red mediante redhat-config-network en Red Hat Enterprise Linux3 o system-config-network en Red Hat Enterprise Linux 4 y Red Hat Enterprise Linux 5.

12.5.2. Dispositivos de almacenamiento virtualizados

Realice los siguientes pasos para configurar dispositivos de almacenamiento virtualizados para su huésped,
Edite su archivo de configuración en /etc/xen/YourGuestName remplazando YourGuestName por el nombre de su huésped. La entrada original puede verse como la siguiente:
disk = [ "file:/var/lib/libvirt/images/rhel5_64_fv.dsk,hda,w"]
Ahora, añada una entrada adicional para su nuevo dispositivo físico, LUN, partición o volumen, al parámetro “disk=” en el archivo de configuración. Las entidades de almacenaje que utilizan el controlador para-virtualizado se parecen a la entrada de abajo. El parámetro “tap:aio” le ordena al hipervisor utilizar el controlador para-virtualizado.
disk = [ "file:/var/lib/libvirt/images/rhel5_64_fv.dsk,hda,w",
    "tap:aio:/var/lib/libvirt/images/UserStorage1.dsk,xvda,w" ]
Si desea añadir más entradas, agréguelas a la sección “disk=” como una lista separada por comas.

Nota

You need to increment the letter for the 'xvd' device, that is for your second storage entity it would be 'xvdb' instead of 'xvda'.
disk = [ "file:/var/lib/libvirt/images/rhel5_64_fv.dsk,hda,w",
    "tap:aio:/var/lib/libvirt/images/UserStorage1.dsk,xvda,w",
    "tap:aio:/var/lib/libvirt/images/UserStorage2.dsk,xvdb,w" ]
Verifique que las particiones hayan sido creadas y que estén disponibles.
# cat /proc/partitions
major minor  #blocks    name
   3     0   10485760   hda
   3     1     104391   hda1
   3     2   10377990   hda2
 202     0      64000   xvda
 202     1      64000   xvdb
 253     0    8257536   dm-0
 253     1    2031616   dm-1
En la salida anterior se puede ver la partición o dispositivo “xvdb” disponible para su sistema.
Monte los nuevos dispositivos y discos en los puntos de montaje locales y actualice el archivo /etc/fstab dentro del huésped para montar los dispositivos y particiones en tiempo de arranque.
# mkdir /mnt/pvdisk_xvda
# mkdir /mnt/pvdisk_xvdb
# mount /dev/xvda /mnt/pvdisk_xvda
# mount /dev/xvdb /mnt/pvdisk_xvdb
# df /mnt
Filesystem           1K-blocks      Used   Available Use%  Mounted on
/dev/xvda                64000        15       63985   1%  /mnt/pvdisk_xvda
/dev/xvdb                64000        15       63985   1%  /mnt/pvdisk_xvdb

Capítulo 13. Controladores KVM para-virtualizados

Para-virtualized drivers are available for virtualized Windows guests running on KVM hosts. These para-virtualized drivers are included in the virtio-win package. The virtio-win package supports block (storage) devices and network interface controllers.
As with the KVM module, the virtio-win drivers package is only available on hosts running Red Hat Enterprise Linux 5.4 and newer.
Los controladores para-virtualizados aumentan el rendimiento de los huéspedes totalmente para-virtualizados. Con los controladores para-virtualizados la latencia de E/S disminuye y el rendimiento aumenta los niveles a casi bare- metal. Es recomendable utilizar controladores para-virtualizados para huéspedes completamente virtualizados ejecutando tareas pesadas de E/S y aplicaciones.
The KVM para-virtualized drivers are automatically loaded and installed on the following versions of Red Hat Enterprise Linux:
  • Red Hat Enterprise Linux 4.8 and newer
  • Red Hat Enterprise Linux 5.3 and newer
  • Red Hat Enterprise Linux 6.
Those Red Hat Enterprise Linux versions detect and install the drivers so additional installation steps are not required.

Nota

PCI devices are limited by the virtualized system architecture. Out of the 32 available PCI devices for a guest 4 are not removable. This means there are up to 28 PCI slots available for additional devices per guest. Each PCI device can have up to 8 functions; some PCI devices have multiple functions and only use one slot. Para-virtualized network, para-virtualized disk devices, or other PCI devices using VT-d all use slots or functions. The exact number of devices available is difficult to calculate due to the number of available devices. Each guest can use up to 32 PCI devices with each device having up to 8 functions.
Las siguientes versiones de Microsoft Windows tienen controladores para-virtualizados KVM:
  • Windows XP (32-bit only)
  • Windows Server 2003 (32-bit and 64-bit versions)
  • Windows Server 2008 (32-bit and 64-bit versions)
  • Windows 7 (32-bit and 64-bit versions)

13.1. Instalación de controladores KVM Windows para-virtualizados

Esta sección cubre el proceso de instalación para los controladores KVM Windows para-virtualizados. Los controladores KVM para-virtualizados pueden ser cargados durante la instalación de Windows o después de la instalación del huésped.
You can install the para-virtualized drivers on your guest by one of the following methods:
  • hosting the installation files on a network accessible to the guest,
  • using a virtualized CD-ROM device of the driver installation disk .iso file, or
  • using a virtualized floppy device to install the drivers during boot time (for Windows guests).
This guide describes installation from the para-virtualized installer disk as a virtualized CD-ROM device.
  1. Descargar los controladores

    The virtio-win package contains the para-virtualized block and network drivers for all supported Windows guests.
    If the Red Hat Enterprise Linux Supplementary channel entitlements are not enabled for the system, the download will not be available. Enable the Red Hat Enterprise Linux Supplementary channel to access the virtio-win package.
    Download the virtio-win package with the yum command.
    # yum install virtio-win
    
    The drivers are also available on the Red Hat Enterprise Linux Supplementary disc or from Microsoft (windowsservercatalog.com). Note that the Red Hat Enterprise Virtualization Hypervisor and Red Hat Enterprise Linux are created on the same code base so the drivers for the same version (for example, 5.5) are supported for both environments.
    El paquete virtio-win instala una imagen de CD-ROM, virtio-win.iso, en el directorio /usr/share/virtio-win/.
  2. Instale los controladores para-virtualizados

    Se recomienda instalar los controladores en el huésped antes de anexar o modificar un dispositivo para usar los controladores para-virtualizados.
    Para dispositivos de bloque que almacenan sistemas de archivos de root u otros dispositivos de bloque requeridos para arrancar el huésped, los controladores deben ser instalados antes que el dispositivo sea modificado. Si los controladores no están instalados en el huésped y el controlador está configurado para el controlador de virtio, el huésped no podrá arrancar.
Installing drivers with a virtualized CD-ROM
This procedure covers installing the para-virtualized drivers with a virtualized CD-ROM after Windows is installed.
Follow Procedimiento 13.1, “Uso de virt-manager para montar una imagen de CD-ROM para un huésped de a Windows” to add a CD-ROM image with virt-manager and then install the drivers.
Procedimiento 13.1. Uso de virt-manager para montar una imagen de CD-ROM para un huésped de a Windows
  1. Open virt-manager and the virtualized guest

    Open virt-manager, select your virtualized guest from the list by double clicking the guest name.
  2. Open the hardware tab

    Click the Add Hardware button in the Hardware tab.
  3. Select the device type

    This opens a wizard for adding the new device. Select Storage from the dropdown menu.
    Click the Forward button to proceed.
  4. Select the ISO file

    Choose the File (disk image) option and set the file location of the para-virtualized drivers .iso image file. The location file is named /usr/share/virtio-win/virtio-win.iso.
    Si los controladores están almacenados en un CD-ROM físico, utilice la opción Normal Disk Partition.
    Set the Device type to IDE cdrom and click Forward to proceed.
  5. Disc assigned

    The disk has been assigned and is available for the guest once the guest is started. Click Finish to close the wizard or back if you made a mistake.
  6. Reboot

    Reboot or start the guest to add the new device. Virtualized IDE devices require a restart before they can be recognized by guests.
Once the CD-ROM with the drivers is attached and the guest has started, proceed with Procedimiento 13.2, “Windows installation”.
Procedimiento 13.2. Windows installation
  1. Open My Computer

    On the Windows guest, open My Computer and select the CD-ROM drive.
  2. Select the correct installation files

    There are four files available on the disc. Select the drivers you require for your guest's architecture:
    • the para-virtualized block device driver (RHEV-Block.msi for 32-bit guests or RHEV-Block64.msi for 64-bit guests),
    • the para-virtualized network device driver (RHEV-Network.msi for 32-bit guests or RHEV-Block64.msi for 64-bit guests),
    • or both the block and network device drivers.
    Double click the installation files to install the drivers.
  3. Install the block device driver

    1. Start the block device driver installation

      Double click RHEV-Block.msi or RHEV-Block64.msi.
      Press Next to continue.
    2. Confirm the exception

      Windows may prompt for a security exception.
      Press Yes if it is correct.
    3. Finish

      Press Finish to complete the installation.
  4. Install the network device driver

    1. Start the network device driver installation

      Double click RHEV-Network.msi or RHEV-Network64.msi.
      Press Next to continue.
    2. Performance setting

      This screen configures advanced TCP settings for the network driver. TCP timestamps and TCP window scaling can be enabled or disabled. The default is, 1, for window scaling to be enabled.
      TCP window scaling is covered by IETF RFC 1323. The RFC defines a method of increasing the receive window size to a size greater than the default maximum of 65,535 bytes up to a new maximum of 1 gigabyte (1,073,741,824 bytes). TCP window scaling allows networks to transfer at closer to theoretical network bandwidth limits. Larger receive windows may not be supported by some networking hardware or operating systems.
      TCP timestamps are also defined by IETF RFC 1323. TCP timestamps are used to better calculate Return Travel Time estimates by embedding timing information is embedded in packets. TCP timestamps help the system to adapt to changing traffic levels and avoid congestion issues on busy networks.
      ValueAction
      0Disable TCP timestamps and window scaling.
      1Enable TCP window scaling.
      2Enable TCP timestamps.
      3Enable TCP timestamps and window scaling.
      Press Next to continue.
    3. Confirm the exception

      Windows may prompt for a security exception.
      Press Yes if it is correct.
    4. Finish

      Press Finish to complete the installation.
  5. Reboot

    Reboot the guest to complete the driver installation.
Change the device configuration to use the para-virtualized drivers (Sección 13.3, “Uso de controladores KVM para-virtualizados para dispositivos existentes”) or install a new device which uses the para-virtualized drivers (Sección 13.4, “Uso de controladores KVM para-virtualizados para nuevos dispositivos”).

13.2. Installing drivers with a virtualized floppy disk

Este procedimiento cubre la instalación de controladores para-virtualizados durante una instalación de Windows.
  • Tras instalar el VM de Windows por primera vez mediante el menú de ejecución de una sola vez añada viostor.vfd como un disquete.
    1. Windows Server 2003

      Cuando Windows le pida pulsar F6 para controladores de tercera parte, hágalo y siga las instrucciones en pantalla.
    2. Windows Server 2008

      Cuando el instalador le solicite el controlador, haga clic en Controlador de carga, señale el instalador para el controlador A: y seleccione el controlador que se ajuste a su sistema operativo y arquitectura.

13.3. Uso de controladores KVM para-virtualizados para dispositivos existentes

Modify an existing hard disk device attached to the guest to use the virtio driver instead of virtualized IDE driver. This example edits libvirt configuration files. Alternatively, virt-manager, virsh attach-disk or virsh attach-interface can add a new device using the para-virtualized drivers Sección 13.4, “Uso de controladores KVM para-virtualizados para nuevos dispositivos”.
  1. A continuación está el dispositivo de bloque basado en archivo utilizando el controlador IDE virtualizado. Esta es una entrada típica para un huésped virtualizado que no utiliza controladores para-virtualizados.
    <disk type='file' device='disk'>
       <source file='/var/lib/libvirt/images/disk1.img'/>
       <target dev='vda' bus='ide'/>
    </disk>
    
  2. Cambie la entrada para usar el dispositivo para-virtualizado modificando la entrada bus= para virtio.
    <disk type='file' device='disk'>
       <source file='/var/lib/libvirt/images/disk1.img'/>
       <target dev='vda' bus='virtio'/>
    </disk>
    

13.4. Uso de controladores KVM para-virtualizados para nuevos dispositivos

Este procedimiento cubre la creación de nuevos dispositivos mediante los controladores para-virtualizados con virt-manager.
Como alternativa, los comandos virsh attach-disk o virsh attach-interface se pueden utilizar para añadir dispositivos mediante los controladores para-virtualizados.

Instale los controladores virtuales primero

Asegúrese que los controladores hayan sido instalados en el huésped de Windows antes de proseguir a instalar nuevos dispositivos. Si los controladores no están disponibles, el dispositivo no será identificado y no funcionará.
  1. Abra el huésped virtualizado al hacer doble clic en el nombre del huésped en virt-manager.
  2. Abra la pestaña Hardware.
  3. Pulse el botón Agregar Hardware.
  4. En la pestaña de Agregar hardware virtual, seleccione Almacenamiento o Red para el tipo de dispositivo.
    1. New disk devices
      Seleccione el dispositivo de almacenamiento o imagen basada en archivo. Seleccione Virtio Disk como el Tipo de dispositivo y pulse Adelante.
    2. New network devices
      Seleccione Red virtual o Dispositivo físico compartido. Seleccione virtio como el Tipo de dispositivo y presione Adelante.
  5. Presione Terminar para guardar el dispositivo.
  6. Reinicie el huésped. El dispositivo no puede ser reconocido hasta que el huésped de Windows reinicie.

Capítulo 14. Paso de PCI

Este capítulo cubre el uso de paso de PCI con hipervisores Xen y KVM.
KVM and Xen hypervisors support attaching PCI devices on the host system to virtualized guests. PCI passthrough allows guests to have exclusive access to PCI devices for a range of tasks. PCI passthrough allows PCI devices to appear and behave as if they were physically attached to the guest operating system.
PCI devices are limited by the virtualized system architecture. Out of the 32 available PCI devices for a guest 4 are not removable. This means there are up to 28 PCI slots available for additional devices per guest. Each PCI device can have up to 8 functions; some PCI devices have multiple functions and only use one slot. Para-virtualized network, para-virtualized disk devices, or other PCI devices using VT-d all use slots or functions. The exact number of devices available is difficult to calculate due to the number of available devices. Each guest can use up to 32 PCI devices with each device having up to 8 functions.
The VT-d or AMD IOMMU extensions must be enabled in BIOS.
Procedimiento 14.1. Preparing an Intel system for PCI passthrough
  1. Enable the Intel VT-d extensions

    The Intel VT-d extensions provides hardware support for directly assigning a physical devices to guest. The main benefit of the feature is to improve the performance as native for device access.
    The VT-d extensions are required for PCI passthrough with Red Hat Enterprise Linux. The extensions must be enabled in the BIOS. Some system manufacturers disable these extensions by default.
    These extensions are often called various terms in BIOS which differ from manufacturer to manufacturer. Consult your system manufacturer's documentation.
  2. Activate Intel VT-d in the kernel

    Activate Intel VT-d in the kernel by appending the intel_iommu=on parameter to the kernel line of the kernel line in the /boot/grub/grub.conf file.
    The example below is a modified grub.conf file with Intel VT-d activated.
    default=0
    timeout=5
    splashimage=(hd0,0)/grub/splash.xpm.gz
    hiddenmenu
    title Red Hat Enterprise Linux Server (2.6.18-190.el5)
       root (hd0,0)
       kernel /vmlinuz-2.6.18-190.el5 ro root=/dev/VolGroup00/LogVol00 intel_iommu=on
       initrd /initrd-2.6.18-190.el5.img
  3. Ready to use

    Reboot the system to enable the changes. Your system is now PCI passthrough capable.
Procedimiento 14.2. Preparing an AMD system for PCI passthrough
  • Enable AMD IOMMU extensions

    The AMD IOMMU extensions are required for PCI passthrough with Red Hat Enterprise Linux. The extensions must be enabled in the BIOS. Some system manufacturers disable these extensions by default.
AMD systems only require that the IOMMU is enabled in the BIOS. The system is ready for PCI passthrough once the IOMMU is enabled.

PCI passthrough with Xen

Xen and KVM require different kernel arguments to enable PCI passthrough. The previous instructions are for KVM. For both AMD and Intel systems, PCI passthrough on Xen requires the iommu=on parameter to the hypervisor command line. Modify the /boot/grub/grub.conf file as follows to enable PCI passthrough:
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Red Hat Enterprise Linux Server (2.6.18-192.el5)
   root (hd0,0)
   kernel /xen.gz-2.6.18-192.el5 iommu=on
   module /vmlinuz-2.6.18-192.el5xen ro root=/dev/VolGroup00/LogVol00 
   module /initrd-2.6.18-190.el5xen.img

14.1. Adding a PCI device with virsh

These steps cover adding a PCI device to a fully virtualized guest under the Xen or KVM hypervisors using hardware-assisted PCI passthrough. Refer to Sección 14.4, “PCI passthrough for para-virtualized Xen guests on Red Hat Enterprise Linux” for details on adding a PCI device to a para-virtualized Xen guest.

Importante

The VT-d or AMD IOMMU extensions must be enabled in BIOS.
This example uses a USB controller device with the PCI identifier code, pci_8086_3a6c, and a fully virtualized guest named win2k3.
  1. Identify the device

    Identify the PCI device designated for passthrough to the guest. The virsh nodedev-list command lists all devices attached to the system. The --tree option is useful for identifying devices attached to the PCI device (for example, disk controllers and USB controllers).
    # virsh nodedev-list --tree
    For a list of only PCI devices, run the following command:
    # virsh nodedev-list | grep pci
    Each PCI device is identified by a string in the following format (Where **** is a four digit hexadecimal code):
    pci_8086_****
    

    Tip: determining the PCI device

    Comparing lspci output to lspci -n (which turns off name resolution) output can assist in deriving which device has which device identifier code.
    Record the PCI device number; the number is needed in other steps.
  2. Information on the domain, bus and function are available from output of the virsh nodedev-dumpxml command:
    # virsh nodedev-dumpxml pci_8086_3a6c
    <device>
      <name>pci_8086_3a6c</name>
      <parent>computer</parent>
      <capability type='pci'>
        <domain>0</domain>
        <bus>0</bus>
        <slot>26</slot>
        <function>7</function>
        <id='0x3a6c'>82801JD/DO (ICH10 Family) USB2 EHCI Controller #2</product>
        <vendor id='0x8086'>Intel Corporation</vendor>
      </capability>
    </device>
  3. Detach the device from the system. Attached devices cannot be used and may cause various errors if connected to a guest without detaching first.
    # virsh nodedev-dettach pci_8086_3a6c 
    Device pci_8086_3a6c dettached
  4. Convert slot and function values to hexadecimal values (from decimal) to get the PCI bus addresses. Append "0x" to the beginning of the output to tell the computer that the value is a hexadecimal number.
    For example, if bus = 0, slot = 26 and function = 7 run the following:
    $ printf %x 0
    0
    $ printf %x 26
    1a
    $ printf %x 7
    7
    The values to use:
    bus='0x00'
    slot='0x1a'
    function='0x7'
  5. Run virsh edit (or virsh attach device) and add a device entry in the <devices> section to attach the PCI device to the guest. Only run this command on offline guests. Red Hat Enterprise Linux does not support hotplugging PCI devices at this time.
    # virsh edit win2k3
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <source>
          <address domain='0x0000' bus='0x00' slot='0x1a' function='0x7'/>
      </source>
    </hostdev>
  6. Once the guest system is configured to use the PCI address, we need to tell the host system to stop using it. The ehci driver is loaded by default for the USB PCI controller.
    $ readlink /sys/bus/pci/devices/0000\:00\:1d.7/driver
    ../../../bus/pci/drivers/ehci_hcd
  7. Detach the device:
    $ virsh nodedev-dettach pci_8086_3a6c
  8. Verify it is now under the control of pci_stub:
    $ readlink /sys/bus/pci/devices/0000\:00\:1d.7/driver
    ../../../bus/pci/drivers/pci-stub
  9. Set a sebool to allow the management of the PCI device from the guest:
    # setsebool -P virt_use_sysfs 1
  10. Start the guest system :
    # virsh start win2k3
    
The PCI device should now be successfully attached to the guest and accessible to the guest operating system.

14.2. Adding a PCI device with virt-manager

PCI devices can be added to guests using the graphical virt-manager tool. The following procedure adds a 2 port USB controller to a virtualized guest.
  1. Identify the device

    Identify the PCI device designated for passthrough to the guest. The virsh nodedev-list command lists all devices attached to the system. The --tree option is useful for identifying devices attached to the PCI device (for example, disk controllers and USB controllers).
    # virsh nodedev-list --tree
    For a list of only PCI devices, run the following command:
    # virsh nodedev-list | grep pci
    Each PCI device is identified by a string in the following format (Where **** is a four digit hexadecimal code):
    pci_8086_****
    

    Tip: determining the PCI device

    Comparing lspci output to lspci -n (which turns off name resolution) output can assist in deriving which device has which device identifier code.
    Record the PCI device number; the number is needed in other steps.
  2. Detach the PCI device

    Detach the device from the system.
    # virsh nodedev-dettach pci_8086_3a6c 
    Device pci_8086_3a6c dettached
  3. Power off the guest

    Power off the guest. Hotplugging PCI devices into guests is presently unsupported and may fail or crash.
  4. Open the hardware settings

    Open the virtual machine and select the Hardware tab. Click the Add Hardware button to add a new device to the guest.
  5. Add the new device

    Select Physical Host Device from the Hardware type list. The Physical Host Device represents PCI devices. Click Forward to continue.
  6. Select a PCI device

    Select an unused PCI device. Note that selecting PCI devices presently in use on the host causes errors. In this example a PCI to USB interface device is used.
  7. Confirm the new device

    Click the Finish button to confirm the device setup and add the device to the guest.
The setup is complete and the guest can now use the PCI device.

14.3. PCI passthrough with virt-install

To use PCI passthrough with the virt-install parameter, use the additional --host-device parameter.
  1. Identify the PCI device

    Identify the PCI device designated for passthrough to the guest. The virsh nodedev-list command lists all devices attached to the system. The --tree option is useful for identifying devices attached to the PCI device (for example, disk controllers and USB controllers).
    # virsh nodedev-list --tree
    For a list of only PCI devices, run the following command:
    # virsh nodedev-list | grep pci
    Each PCI device is identified by a string in the following format (Where **** is a four digit hexadecimal code):
    pci_8086_****
    

    Tip: determining the PCI device

    Comparing lspci output to lspci -n (which turns off name resolution) output can assist in deriving which device has which device identifier code.
  2. Add the device

    Use the PCI identifier output from the virsh nodedev command as the value for the --host-device parameter.
    # virt-install \
     -n hostdev-test -r 1024 --vcpus 2 \
     --os-variant fedora11 -v --accelerate \
     -l http://download.fedoraproject.org/pub/fedora/linux/development/x86_64/os \
     -x 'console=ttyS0 vnc' --nonetworks --nographics  \
     --disk pool=default,size=8 \
     --debug --host-device=pci_8086_10bd 
    
  3. Complete the installation

    Complete the guest installation. The PCI device should be attached to the guest.

14.4. PCI passthrough for para-virtualized Xen guests on Red Hat Enterprise Linux

PCI passthrough is used to allow a Xen guest exclusive access to a PCI device, rather than sharing with other guests or with dom0. PCI passthrough for para-virtualized Xen guests is supported on all Red Hat Enterprise Linux 5 systems, however PCI passthrough with fully virtualized guests is only supported on Red Hat Enterprise Linux 5.4 and newer.

Aviso

PCI passthrough to para-virtualized guests is considered insecure and is not supported for Red Hat Enterprise Linux 6 guests.
Limitations of Xen PCI passthrough:
Any guest using PCI passthrough will no longer be available for save, restore, or migration capabilities, as it will be tied to a particular non-virtualized hardware configuration.
A guest which has access to a non-virtualized PCI device via PCI passthrough also has the potential to access the DMA address space of dom0, which is a potential security concern.
To link a PCI device to a guest the device must first be hidden from the host. If the host is using the device the device cannot be assigned to the guest.
Procedimiento 14.3. Example: attaching a PCI device
  1. Given a network device which uses the bnx2 driver and has a PCI id of 0000:09:00.0, the following lines added to /etc/modprobe.conf hides the device from dom0. Either the bnx2 module must be reloaded or the host must be restarted.
    install bnx2 /sbin/modprobe pciback; /sbin/modprobe --first-time --ignore-install bnx2
    options pciback hide=(0000:09:00.0)
  2. Multiple PCI identifiers can be added to /etc/modprobe.conf to hide multiple devices.
    options pciback hide=(0000:09:00.0)(0000:0a:04.1)
  3. Use one of the following methods to add the passed-through device to the guest's configuration file:

Capítulo 15. SR-IOV

15.1. Introduction

The PCI-SIG (PCI Special Interest Group) developed the Single Root I/O Virtualization (SR-IOV) specification. The PCI-SIG Single Root IOV specification is a standard for a type of PCI passthrough which natively shares a single device to multiple guests. SR-IOV does not require hypervisor involvement in data transfer and management by providing an independent memory space, interrupts, and DMA streams for virtualized guests.
SR-IOV enables a Single Root Function (for example, a single Ethernet port), to appear as multiple, separate, physical devices. A physical device with SR-IOV capabilities can be configured to appear in the PCI configuration space as multiple functions, each device has its own configuration space complete with Base Address Registers (BARs).
SR-IOV uses two new PCI functions:
  • Physical Functions (PFs) are full PCIe devices that include the SR-IOV capabilities. Physical Functions are discovered, managed, and configured as normal PCI devices. Physical Functions configure and manage the SR-IOV functionality by assigning Virtual Functions.
  • Virtual Functions (VFs) are simple PCIe functions that only process I/O. Each Virtual Function is derived from a Physical Function. The number of Virtual Functions a device may have is limited by the device hardware. A single Ethernet port, the Physical Device, may map to many Virtual Functions that can be shared to virtualized guests.
The hypervisor can map one or more Virtual Functions to a virtualized guest. The Virtual Function's configuration space is mapped, by the hypervisor, to the virtualized guest's configuration space.
Each Virtual Function can only be mapped once as Virtual Functions require real hardware. A virtualized guest can have multiple Virtual Functions. A Virtual Function appears as a network card in the same way as a normal network card would appear to an operating system.
The SR-IOV drivers are implemented in the kernel. The core implementation is contained in the PCI subsystem, but there must also be driver support for both the Physical Function (PF) and Virtual Function (VF) devices. With an SR-IOV capable device one can allocate VFs from a PF. The VFs appear as PCI devices which are backed on the physical PCI device by resources (queues, and register sets).
Advantages of SR-IOV
SR-IOV devices can share a single physical port with multiple virtualized guests.
Virtual Functions have near-native performance and provide better performance than para-virtualized drivers and emulated access. Virtual Functions provide data protection between virtualized guests on the same physical server as the data is managed and controlled by the hardware.
These features allow for increased virtualized guest density on hosts within a data center.
Disadvantages of SR-IOV
Live migration is presently unsupported. As with PCI passthrough, identical device configurations are required for live (and offline) migrations. Without identical device configurations, guest's cannot access the passed-through devices after migrating.

15.2. Using SR-IOV

This section covers attaching Virtual Function to a guest as an additional network device.
SR-IOV requires Intel VT-d support.

SR-IOV with Xen

Xen requires additional kernel arguments to use SR-IOV. Modify the /boot/grub/grub.conf file to enable SR-IOV. To enable SR-IOV with Xen for Intel systems append the pci_pt_e820_access=on parameter to the kernel.
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Red Hat Enterprise Linux Server (2.6.18-192.el5xen)
   root (hd0,0)
   kernel /xen.gz-2.6.18-192.el5 iommu=1
   module /vmlinuz-2.6.18-192.el5xen ro root=/dev/VolGroup00/LogVol00 pci_pt_e820_access=on
   module /initrd-2.6.18-192.el5xen.img
Procedimiento 15.1. Attach an SR-IOV network device
  1. Enable Intel VT-d in BIOS and in the kernel

    Enable Intel VT-D in BIOS. Refer to Procedimiento 14.1, “Preparing an Intel system for PCI passthrough” for more information on enabling Intel VT-d in BIOS and the kernel, or refer to your system manufacturer's documentation for specific instructions.
  2. Verify support

    Verify if the PCI device with SR-IOV capabilities are detected. This example lists an Intel 82576 network interface card which supports SR-IOV. Use the lspci command to verify if the device was detected.
    # lspci
    03:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
    03:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
    

    Nota

    Note that the output has been modified to remove all other devices.
  3. Start the SR-IOV kernel modules

    If the device is supported the driver kernel module should be loaded automatically by the kernel. Optional parameters can be passed to the module using the modprobe command. The Intel 82576 network interface card uses the igb driver kernel module.
    # modprobe igb [<option>=<VAL1>,<VAL2>,]
    # lsmod |grep igb
    igb    87592  0
    dca    6708    1 igb
    
  4. Activate Virtual Functions

    The max_vfs parameter of the igb module allocates the maximum number of Virtual Functions. The max_vfs parameter causes the driver to spawn, up to the value of the parameter in, Virtual Functions. For this particular card the valid range is 0 to 7.
    Remove the module to change the variable.
    # modprobe -r igb
    Restart the module with the max_vfs set to 1 or any number of Virtual Functions up to the maximum supported by your device.
    # modprobe igb max_vfs=1
    
  5. Inspect the new Virtual Functions

    Using the lspci command, list the newly added Virtual Functions attached to the Intel 82576 network device.
    # lspci | grep 82576
    03:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
    03:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
    03:10.0 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
    03:10.1 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
    
    The identifier for the PCI device is found with the -n parameter of the lspci command.
    # lspci -n | grep 03:00.0
    03:00.0 0200: 8086:10c9 (rev 01)
    # lspci -n | grep 03:10.0
    03:10.0 0200: 8086:10ca (rev 01)
    
    The Physical Function corresponds to 8086:10c9 and the Virtual Function to 8086:10ca.
  6. Find the devices with virsh

    The libvirt service must find the device to add a device to a guest. Use the virsh nodedev-list command to list available host devices.
    # virsh nodedev-list | grep 8086
    pci_8086_10c9
    pci_8086_10c9_0
    pci_8086_10ca
    pci_8086_10ca_0
    [output truncated]
    
    The serial numbers for the Virtual Functions and Physical Functions should be in the list.
  7. Get advanced details

    The pci_8086_10c9 is one of the Physical Functions and pci_8086_10ca_0 is the first corresponding Virtual Function for that Physical Function. Use the virsh nodedev-dumpxml command to get advanced output for both devices.
    # virsh nodedev-dumpxml pci_8086_10ca
    # virsh nodedev-dumpxml pci_8086_10ca_0
    <device>
      <name>pci_8086_10ca_0</name>
      <parent>pci_8086_3408</parent>
      <driver>
        <name>igbvf</name>
      </driver>
      <capability type='pci'>
        <domain>0</domain>
        <bus>3</bus>
        <slot>16</slot>
        <function>1</function>
        <product id='0x10ca'>82576 Virtual Function</product>
        <vendor id='0x8086'>Intel Corporation</vendor>
      </capability>
    </device>
    
    This example adds the Virtual Function pci_8086_10ca_0 to the guest in Paso 8. Note the bus, slot and function parameters of the Virtual Function, these are required for adding the device.
  8. Add the Virtual Function to the guest

    1. Shut down the guest.
    2. Use the output from the virsh nodedev-dumpxml pci_8086_10ca_0 command to calculate the values for the configuration file. Convert slot and function values to hexadecimal values (from decimal) to get the PCI bus addresses. Append "0x" to the beginning of the output to tell the computer that the value is a hexadecimal number.
      The example device has the following values: bus = 3, slot = 16 and function = 1. Use the printf utility to convert decimal values to hexadecimal values.
      $ printf %x 3
      3
      $ printf %x 16
      10
      $ printf %x 1
      1
      This example would use the following values in the configuration file:
      bus='0x03'
      slot='0x10'
      function='0x01'
    3. Open the XML configuration file with the virsh edit command. This example edits a guest named MyGuest.
      # virsh edit MyGuest
      
    4. The default text editor will open the libvirt configuration file for the guest. Add the new device to the devices section of the XML configuration file.
      <hostdev mode='subsystem' type='pci' managed='yes'>
            <source>
              <address bus='0x03' slot='0x10' function='0x01'/>
            </source>
      </hostdev>
      
    5. Save the configuration.
  9. Restart

    Restart the guest to complete the installation.
    # virsh start MyGuest
    
The guest should start successfully and detect a new network interface card. This new card is the Virtual Function of the SR-IOV device.

15.3. Troubleshooting SR-IOV

This section contains some issues and solutions for problems which may affect SR-IOV.
Error starting the guest
Start the configured vm , an error reported as follows:
# virsh start test
error: Failed to start domain test
error: internal error unable to start guest: char device redirected to
/dev/pts/2
get_real_device: /sys/bus/pci/devices/0000:03:10.0/config: Permission denied
init_assigned_device: Error: Couldn't get real device (03:10.0)!
Failed to initialize assigned device host=03:10.0
This error is often caused by a device which is already assigned to another guest or to the host itself.

Capítulo 16. Administración del tiempo del huésped KVM

La virtualización presenta varios retos para administrar el tiempo de huésped. Los huéspedes que utilizan el Contador de marca de tiempo (TSC) como una fuente de reloj, pueden sufrir graves percances de tiempo, puesto que algunas CPU no tienen un Contador de marca de tiempo constante. Los huéspedes sin el manejo del tiempo exacto, presentan problemas con algunas aplicaciones en red y procesos, ya que el huésped se ejecuta más rápido o más lento que el tiempo real actual y se fallan en la sincronización.
KVM trata de solucionar este problema al proporcionar a huéspedes un reloj para-virtualizado. Igualmente, algunos huéspedes pueden usar otras fuentes de reloj x86 para su conteo de tiempo en próximas versiones de esos sistemas operativos.
Actualmente, sólo Red Hat Enterprise Linux 5.4 y huéspedes más recientes soportan completamente el reloj para-virtualizado.
Los huéspedes pueden tener varios problemas debido a relojes y contadores inexactos:
  • Los relojes pueden no coincidir con el tiempo real que invalida sesiones y afecta redes.
  • Los huéspedes con relojes más lentos pueden tener problemas con la migración.
Estos problemas existen en otras plataformas de virtualización y el control de tiempo siempre debe someterse a prueba.

NTP

El demonio de Protocolo de tiempo de red (NTP) debe estar ejecutándose en el host y en los huéspedes. Habilite el servicio ntpd:
# service ntpd start
Añada el servicio ntpd a la secuencia de arranque predeterminada:
# chkconfig ntpd on
Al utilizar el servicio ntpd se deben minimizar los efectos del desplazamiento del reloj en todos los casos
Cómo determinar si su CPU tiene el contador de tiempo de marca constante
Su CPU tiene un contador de marca de tiempo constante si el indicador constant_tsc está presente. Para determinar si su CPU tiene el indicador constant_tsc, ejecute el siguiente comando:
$ cat /proc/cpuinfo | grep constant_tsc
Si se entrega alguna salida su CPU tiene el bit constant_tsc. Si no hay ninguna salida siga las instrucciones dadas a continuación.
Configuración de hosts sin un contador de tiempo de marca constante
Los sistemas sin contadores de tiempo de marca constante requieren una configuración adicional. Las funciones de administración de energía interfieren con el control preciso de la puntualidad y deben desactivarse para que los huéspedes puedan mantener la puntualidad exacta con KVM.

Nota

Estas instrucciones son para la revisión de AMD únicamente CPU de F.
Si la CPU carece del bit constant_tsc, inhabilite todas las funciones (BZ#513138). Cada sistema tiene varios contadores que sirven para controlar el tiempo. El TSC no es estable en el host, lo cual se debe, algunas veces, a cambios de cpufreq, estado deep C, o migración a un host con un TSC más rápido. Para detener al kernel con estados deep C, añada "processor.max_cstate=1" a las opciones de arranque del kernel al archivo grub.conf en el host:
term Red Hat Enterprise Linux Server (2.6.18-159.el5)
        root (hd0,0)
	kernel /vmlinuz-2.6.18-159.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet processor.max_cstate=1
Desactive cpufreq (sólo necesario en sin constant_tsc) editando el archivo de configuración /etc/sysconfig/cpuspeed y cambiando las variables MIN_SPEED y MAX_SPEED a la frecuencia más alta disponible. Los límites válidos se pueden encontrar en los archivos /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies.
Uso del reloj para-virtualizado con huéspedes de Red Hat Enterprise Linux
Para algunos huéspedes de Red Hat Enterprise Linux, se requieren parámetros de kernel adicionales. Dichos parámetros se pueden establecer añadiéndolos al final de la línea de /kernel en el archivo /boot/grub/grub.conf del huésped.
La tabla a continuación presenta versiones de Red Hat Enterprise Linux y los parámetros requeridos para huéspedes en sistemas sin un Contador de marca de tiempo constante.
Red Hat Enterprise LinuxParámetros adicionales de kernel de huésped
5.4 AMD64/Intel 64 con el reloj para-virtualizadoNo se requieren parámetros adicionales
5.4 AMD64/Intel 64 sin el reloj para-virtualizadodivider=10 notsc lpj=n
5.4 x86 con el reloj para-virtualizadoNo se requieren parámetros adicionales
5.4 x86 sin el reloj para-virtualizadodivider=10 clocksource=acpi_pm lpj=n
5.3 AMD64/Intel 64divider=10 notsc
5.3 x86divider=10 clocksource=acpi_pm
4.8 AMD64/Intel 64notsc divider=10
4.8 x86clock=pmtmr divider=10
3.9 AMD64/Intel 64No se requieren parámetros adicionales
3.9 x86No se requieren parámetros adicionales
Using the Real-Time Clock with Windows Server 2003 and Windows XP guests
Windows usa tanto el reloj de tiempo real (RTC) como el contador de marca de tiempo (TSC). Para huéspedes de Windows el reloj de tiempo real puede utilizarse en lugar del TSC para todas las fuentes de tiempo que resuelvan problemas de tiempo de huésped.
Para habilitar el reloj de tiempo real para la fuente de reloj PMTIMER (la PMTIMER por lo general usa el TSC) añada la siguiente línea a la configuración de arranque de Windows. la configuración de arranque de Windows está almacenada en el archivo boot.ini. Añada la siguiente línea al archivo boot.ini:
/use pmtimer
Para obtener mayor información sobre arranque en Windows y la opción pmtimer, consulte Opciones disponibles de cambio para Windows XP y los archivos Windows Server 2003 Boot.ini files.
Using the Real-Time Clock with Windows Vista, Windows Server 2008 and Windows 7 guests
Windows usa tanto el reloj de tiempo real (RTC) como el contador de marca de tiempo (TSC). Para huéspedes de Windows el reloj de tiempo real puede utilizarse en lugar del TSC para todas las fuentes de tiempo que resuelvan problemas de tiempo de huésped.
The boot.ini file is no longer used from Windows Vista and newer. Windows Vista, Windows Server 2008 and Windows 7 use the Boot Configuration Data Editor (bcdedit.exe) to modify the Windows boot parameters.
This procedure is only required if the guest is having time keeping issues. Time keeping issues may not affect guests on all host systems.
  1. Open the Windows guest.
  2. Open the Accessories menu of the start menu. Right click on the Command Prompt application, select Run as Administrator.
  3. Confirm the security exception, if prompted.
  4. Set the boot manager to use the platform clock. This should instruct Windows to use the PM timer for the primary clock source. The system UUID ({default} in the example below) should be changed if the system UUID is different than the default boot device.
    C:\Windows\system32>bcdedit /set {default} USEPLATFORMCLOCK on
    The operation completed successfully
This fix should improve time keeping for Windows Vista, Windows Server 2008 and Windows 7 guests.

Parte IV. Administración

Capítulo 17. Mejores prácticas de servidor

Las siguientes tareas pueden ayudarle a asegurar y garantizar la confiabilidad de su host de servidor (domo0).
  • Ejecute SELinux en modo impositivo. Puede activar SELinux con el siguiente comando:
    # setenforce 1
    
  • Remueva o desactive los servicios innecesarios (tales como AutoFS, NFS, FTP, HTTP, NIS, telnetd, sendmail, etc.).
  • Sólo añada las cuentas de usuario necesarias para la administración de la plataforma en el servidor y elimine las que no se necesiten.
  • Evite ejecutar las aplicaciones que no sean esenciales en su host. La ejecución de aplicaciones en el host puede impactar el rendimiento de la máquina virtual y puede afectar la estabilidad del servidor. Cualquier aplicación que pueda dañar el servidor también hará que todas las máquinas virtuales en el servidor se caigan.
  • Utilice una ubicación central para las imágenes e instalaciones de la máquina virtual. Las imágenes de máquina virtual deben ser almacenadas bajo /var/lib/libvirt/images/. Si utiliza un directorio diferente para las imágenes de máquina virtual, asegúrese de añadir el directorio a su política de SELinux y de etiquetarlo antes de iniciar la instalación.
  • Las fuentes de instalación, árboles e imágenes se deben almacenar en una ubicación central, usualmente la ubicación de su servidor vsftpd.

Capítulo 18. Seguridad para virtualización

Al implementar las tecnologías de virtualización en la infraestructura de su organización, debe asegurarse de que Domain0 no pueda estar comprometido. El host, en el hipervisor Xen, es un dominio privilegiado que maneja la administración del sistema y todas la máquinas virtuales. Si el host es inseguro, todos los demás dominios en el sistema serán vulnerables. Hay varias formas de mejorar la seguridad en sistemas que utilizan la virtualización. Usted o su organización deben crear un Plan de implementación que comprenda las especificaciones operativas y especifique los servicios necesarios en sus servidores de huéspedes y host virtualizados al igual que el soporte requerido para estos servicios. A continuación se presentan aspectos de seguridad que se deben considerar durante el desarrollo del plan de implementación:
  • Ejecute sólo el número de servicios necesarios en hosts. Entre menos procesos y servicios se estén ejecutando en el host, mayor será el nivel de seguridad y rendimiento requerido.
  • Enable Security-Enhanced Linux (SELinux) on the hypervisor. Read Sección 18.2, “SELinux y virtualización completas” for more information on using SELinux and virtualization.
  • Utilice un cortafuegos para limitar el tráfico a dom0. Puede establecer un cortafuegos con reglas de rechazo predeterminadas que ayuden a asegurar dom0. También es importante limitar los servicios expuestos a la red.
  • No permita que usuarios normales tengan acceso a dom0. Si permite que los usuarios normales tengan acceso a dom0, se corre el riesgo de aumentar la vulnerabilidad de dom0. Recuerde, dom0 es privilegiado y otorgar cuentas sin privilegios puede comprometer el nivel de seguridad.

18.1. Storage security issues

Administrators of virtualized guests can change the partitions the host boots in certain circumstances. To prevent this administrators should follow these recommendations:
The host should not use disk labels to identify file systems in the fstab file, the initrd file or used by the kernel command line. If less privileged users, especially virtualized guests, have write access to whole partitions or LVM volumes.
Guest should not be given write access to whole disks or block devices (for example, /dev/sdb). Use partitions (for example, /dev/sdb1) or LVM volumes.

18.2. SELinux y virtualización completas

Security Enhanced Linux was developed by the NSA with assistance from the Linux community to provide stronger security for Linux. SELinux limits an attackers abilities and works to prevent many common security exploits such as buffer overflow attacks and privilege escalation. It is because of these benefits that Red Hat recommends all Red Hat Enterprise Linux systems should run with SELinux enabled and in enforcing mode.
SELinux prevents guest images from loading if SELinux is enabled and the images are not correctly labeled. SELinux requires that image files have the virt_image_t label applied to them. The /var/lib/libvirt/images directory has this label applied to it and its contents by default. This does not mean that images must be stored in this directory; images can be stored anywhere, provided they are labeled with virt_image_t.
Adición de almacenamiento basado en LVM con SELinux en modo impositivo.
La siguiente sección es un ejemplo de la adición de un volumen lógico a un huésped virtualizado con SELinux habilitado. Estas instrucciones también se aplican a particiones de disco duro.
Procedimiento 18.1. Creación y montaje de un volumen lógico en un huésped virtualizado con SELinux habilitado.
  1. Cree un volumen lógico. Este ejemplo crea un volumen lógico de 5 GB denominado NewVolumeName en el grupo de volumen denominado volumegroup.
    # lvcreate -n NewVolumeName -L 5G volumegroup
  2. De formato al volumen lógico NewVolumeName con un sistema de archivos que soporta atributos, tales como ext3.
    # mke2fs -j /dev/volumegroup/NewVolumeName
    
  3. Cree un nuevo directorio para montar el nuevo volumen lógico. Este directorio puede estar en cualquier parte de su sistema de archivos. Se recomienda ponerlo en directorios de sistema importantes (/etc, /var, /sys) o en directorios principales (/home o /root). Este ejemplo utiliza un directorio llamado /virtstorage
    # mkdir /virtstorage
    
  4. Monte el volumen lógico.
    # mount /dev/volumegroup/NewVolumeName /virtstorage
  5. Set the correct SELinux type for a Xen folder.
    semanage fcontext -a -t xen_image_t "/virtstorage(/.*)?"
    
    Otra posibilidad es establecer el tipo de SELinux apropiado para una carpeta de KVM.
    semanage fcontext -a -t virt_image_t "/virtstorage(/.*)?"
    
    Si se utiliza la política objetivo (la objetivo es la predeterminada por defecto) el comando añadirá una línea al archivo /etc/selinux/targeted/contexts/files/file_contexts.local, el cual hace el cambio persistente. La línea añadida puede ser similar a ésta:
    /virtstorage(/.*)?    system_u:object_r:xen_image_t:s0
    
  6. Label the device node (for example, /dev/volumegroup/NewVolumeName with the correct label:
    # semanage fcontext -a -t xen_image_t /dev/volumegroup/NewVolumeName
    # restorecon /dev/volumegroup/NewVolumeName
    

18.3. SELinux

Estas sección contiene información que debe tenerse en cuenta cuando se utilice SELinux con su implementación de virtualización. Cuando se implementan los cambios del sistema o se añaden dispositivos, se debe actualizar la política de SELinux. Para configurar un volumen LVM para un huésped, se debe modificar el contexto SELinux para el dispositivo de bloque y el grupo de volumen respectivos.
# semanage fcontext -a -t xen_image_t -f -b /dev/sda2
# restorecon /dev/sda2
El parámetro booleano xend_disable_t puede establecer el xend al modo ilimitado después de reiniciar el demonio. Es mejor desactivar la protección para un solo demonio que para todo el sistema. Es aconsejable que no vuelva a etiquetar los directorios como xen_image_t, los cuales utilizará en otras partes.
KVM and SELinux
There are several SELinux booleans which affect KVM. These booleans are listed below for your convenience.
KVM SELinux Booleans
SELinux BooleanDescription
allow_unconfined_qemu_transitionDefault: off. This boolean controls whether KVM guests can be transitioned to unconfined users.
qemu_full_networkDefault: on. This boolean controls full network access to KVM guests.
qemu_use_cifsDefault: on. This boolean controls KVM's access to CIFS or Samba file systems.
qemu_use_commDefault: off. This boolean controls whether KVM can access serial or parallel communications ports.
qemu_use_nfsDefault: on. This boolean controls KVM's access to NFS file systems.
qemu_use_usbDefault: on. This boolean allows KVM to access USB devices.

18.4. Virtualization firewall information

Various ports are used for communication between virtualized guests and management utilities.

Guest network services

Any network service on a virtualized guest must have the applicable ports open on the guest to allow external access. If a network service on a guest is firewalled it will be inaccessible. Always verify the guests network configuration first.
  • ICMP requests must be accepted. ICMP packets are used for network testing. You cannot ping guests if ICMP packets are blocked.
  • Port 22 should be open for SSH access and the initial installation.
  • Ports 80 or 443 (depending on the security settings on the RHEV Manager) are used by the vdsm-reg service to communicate information about the host.
  • Ports 5634 to 6166 are used for guest console access with the SPICE protocol.
  • Port 8002 is used by Xen for live migration.
  • Ports 49152 to 49216 are used for migrations with KVM. Migration may use any port in this range depending on the number of concurrent migrations occurring.
  • Enabling IP forwarding (net.ipv4.ip_forward = 1) is required for virtual bridge devices. Note that installing libvirt enables this variable so it will be enabled when the virtualization packages are installed unless it was manually disabled.

Nota

Note that enabling IP forwarding is not required for physical bridge devices. When a guest is connected through a physical bridge, traffic only operates at a level that does not require IP configuration such as IP forwarding.

Capítulo 19. Administración de huéspedes con xend

El demonio de control de nodos xend ejecuta ciertas funciones de administración de sistemas relacionadas con las máquinas virtuales. Este demonio controla los recursos virtuales y xend debe estar ejecutándose para interactuar con máquinas virtuales. Antes de comenzar xend, debe especificar los parámetros de operación editando el archivo de configuración de xend en /etc/xen/xend-config.sxp. A continuación se presentan los parámetros que puede activar o desactivar en el archivo de configuración xend-config.sxp.
Tabla 19.1. Parámetros de configuración xend
Ítem Descripción
(console-limit)
Determines the console server's memory buffer limit and assigns that limit on a per domain basis.
(min-mem)
Determina el número mínimo de megabytes reservados para domain0 (si el valor ingresado es 0, el valor no cambia).
(dom0-cpus)
Determina el número de CPU que domain0 usa (al menos 1 CPU es asignada por defecto).
(enable-dump)
Si está habilitado, cuando se presenta una falla Xen crea un archivo de volcado (el valor predeterminado es 0).
(external-migration-tool)
Determina el script o la aplicación que controla la migración de dispositivos externos. Los scripts deben residir en el directorio /etc/xen/scripts/external-device-migrate.
(logfile)
Determina la ubicación del archivo del registro (por defecto está en /var/log/xend.log).
(loglevel)
Filtra los valores para los modos de registro: DEBUG, INFO, WARNING, ERROR o CRITICAL (por defecto es DEBUG).
(network-script)
Determina el script que activa el entorno de red. Los scripts deben residir en el directorio /etc/xen/scripts/.
(xend-http-server)
Activa el servidor de administración de paquetes de flujo http (el valor predeterminado es 'no').
(xend-unix-server)
Activa el servidor de socket de dominio Unix. El servidor de socket es un punto de comunicación que maneja conexiones de red de bajo nivel y acepta o rechaza conexiones entrantes. El valor predeterminado es 'Yes'.
(xend-relocation-server)
Activa el servidor de ubicación para las migraciones entre máquinas (el valor por defecto es no).
(xend-unix-path)
Determina la ubicación a donde el comando xend-unix-server envía mensajes de salida (el valor por defecto es /var/lib/xend/xend-socket)
(xend-port)
Determina el puerto que el servidor de administración http utiliza (el valor predeterminado es 8000).
(xend-relocation-port)
Determina el puerto que el servidor de ubicación utiliza (el valor predeterminado es 8002).
(xend-relocation-address)
Determina las direcciones de host permitidas para migración. El valor predeterminado es el de xend-address.
(xend-address)
Determina la dirección a la cual el servidor de socket del dominio está vinculado. El valor predeterminado permite todas las conexiones.

Después de establecer estos parámetros de operación, verifique si xend está en ejecución y si no lo está, inicialice el demonio. En el intérprete de comandos, inicie el demonio xend con lo siguiente:
service xend start
Puede utilizar xend para detener el demonio:
service xend stop
Este comando detiene la ejecución del demonio.
Puede utilizar xend para reiniciar el demonio:
service xend restart
El demonio inicia de nuevo.
Puede ejecutar el estado del demonio xend.
service xend status
The output displays the daemon's status.

Habilitar xend en el tiempo de arranque

Utilice el comando chkconfig para añadir xend al initscript.
chkconfig --level 345 xend
El xend ahora iniciará en los niveles de ejecución 3, 4 y 5.

Capítulo 20. Migración Xen en vivo

The Xen hypervisor supports Virtualization Migration for para-virtualized guests and fully virtualized guests. Migration is only supported on Red Hat Enterprise Linux 5.1 and newer systems. Migration can be performed offline or live.
  • La migración desconectada interrumpe al huésped virtualizado en el huésped original, lo transfiere al host de destino y luego lo reactiva cuando el huésped es transferido totalmente. La migración desconectada emplea el comando virsh migrate.
    # virsh migrate GuestName libvirtURI
  • A live migration keeps the guest running on the source host and begins moving the memory without stopping the guest. All modified memory pages are monitored for changes and sent to the destination while the image is sent. The memory is updated with the changed pages. The process continues until the amount of pause time allowed for the guest equals the predicted time for the final few pages to be transfer. The Xen hypervisor estimates the time remaining and attempts to transfer the maximum amount of page files from the source to the destination until Xen predicts the amount of remaining pages can be transferred during a very brief time while the virtualized guest is paused. The registers are loaded on the new host and the guest is then resumed on the destination host. If the guest cannot be merged (which happens when guests are under extreme loads) the guest is paused and then an offline migration is started instead.
    La migración utiliza la opción --live para el comando virsh migrate.
    # virsh migrate--live GuestName libvirtURI

Nota de soporte Itanium®

La migración no está actualmente soportada en la arquitectura de Itanium®.
Para activar la migración con Xen se deben hacer algunos cambios al archivo de configuración /etc/xen/xend-config.sxp. Por defecto, la migración está desactivada, ya que puede ser un peligro potencial de seguridad si no está configurada correctamente. Abrir el puerto de migración permite a un host sin autorización iniciar una migración o conectarse a los puertos de migración. La autenticación y autorización no están configuradas para solicitudes de migración y el único mecanismo de control se basa en nombres de hosts y direcciones IP. Asegúrese de que el puerto de migración no tenga acceso a hosts no autorizados.

Seguridad de migración virtualización

La dirección IP y los filtros de nombre de host sólo ofrecen seguridad mínima. Ambos atributos pueden ser si el atacante conoce la dirección o el nombre de host del cliente de migración. El mejor método para asegurar la migración es aislar la red de las conexiones externas y de las conexiones internas no autorizadas.
Habilitar migración
Modifique las siguientes entradas en /etc/xen/xend-config.sxp para habilitar la migración. Modifique los valores, cuando sea necesario, y quite los comentarios (el símbolo #) que preceden a los siguientes parámetros:
(xend-relocation-server yes)
El valor por defecto, el cual inhabilita la migración, es no. Cambie el valor de xend-relocation-server a yes para habilitar la migración.
(xend-relocation-port 8002)
El parámetro, (xend-relocation-port), especifica el puerto que xend debe usar para la interfaz de reubicación, si xend-relocation-server está establecido a yes
El valor por defecto es la variable que debe funcionar para la mayoría de las instalaciones. Si cambia el valor, utilice un puerto no usado en el servidor de reubicación.
El puerto establecido por el parámetro xend-relocation-port debe estar en ambos sistemas.
(xend-relocation-address '')
(xend-relocation-address) es la dirección donde el xend escucha comandos de migración en la conexión relocation-socket si xend-relocation-server se establece.
The default is to listen on all active interfaces. The (xend-relocation-address) parameter restricts the migration server to only listen to a specific interface. The default value in /etc/xen/xend-config.sxp is an empty string(''). This value should be replaced with a single, valid IP address. For example:
(xend-relocation-address '10.0.0.1')
(xend-relocation-hosts-allow '')
The (xend-relocation-hosts-allow 'hosts') parameter controls which hostnames can communicate on the relocation port.
Unless you are using SSH or TLS, the guest's virtual memory is transferred in raw form without encryption of the communication. Modify the xend-relocation-hosts-allow option to restrict access to the migration server.
Si el valor está vacío, como es indicado en el ejemplo anterior por una cadena vacía entre comillas simples, entonces, todas las conexiones están permitidas. Esto supone que la conexión llega al puerto e interfaz que el servidor de reubicación escucha, vea también xend-relocation-port
De lo contrario, el parámetro (xend-relocation-hosts-allow) debe ser una secuencia de expresiones regulares separadas por espacios. Cualquier host con un nombre de dominio totalmente cualificado o una dirección IP coincidente con una de las expresiones regulares, se acepta.
Ejemplo de un atributo (xend-relocation-hosts-allow):
(xend-relocation-hosts-allow '^localhost$ ^localhost\\.localdomain$')
Despues de que haya configurado los parámetros en su archivo de configuración, debe reiniciar el servicio Xen.
# service xend restart

20.1. Ejemplo de migración en vivo

El ejemplo a continuación, muestra cómo configurar un entorno simple para migración en vivo. Esta configuración está utilizando NFS para el almacenamiento compartido. NFS es apropiado para entornos de demostración, sin embargo, para un entorno de producción es recomendable una configuración de almacenaje compartido más robusta con Fibre Channel o iSCSI y GFS.
La configuración a continuación, consta de dos servidores: et-virt07 y et-virt08. Ambos servidores utilizan eth1 como la interfaz de red predeterminada, por lo tanto, están usando xenbr1 como puente de red Xen. Se utiliza un disco SCSI conectado localmente (/dev/sdb) en el servidor et-virt07 para almacenamiento compartido con el NFS.
Configuración para migración en vivo
Cree y monte el directorio utilizado para la migración:
# mkdir /var/lib/libvirt/images
# mount /dev/sdb /var/lib/libvirt/images

Importante

Asegúrese de exportar el directorio con las opciones correctas. Si está exportando el directorio predeterminado /var/lib/libvirt/images/, exporte únicamente /var/lib/libvirt/images/ y no/var/lib/xen/, ya que este directorio es utilizado por el demonio xend y otras herramientas. Si comparte /var/lib/xen/ ocasionará una conducta imprevisible.
# cat /etc/exports
/var/lib/libvirt/images  *(rw,async,no_root_squash)
Verifique que se exporte a través del NFS:
# showmount -e et-virt07
Export list for et-virt07:
/var/lib/libvirt/images *
Instale el huésped
Comando de instalación en el ejemplo utilizado para instalar el huésped:
# virt-install -p -f /var/lib/libvirt/images/testvm1.dsk -s 5 -n\
testvm1 --vnc -r 1024 -l http://example.com/RHEL5-tree\
Server/x86-64/os/ -b xenbr1
For step by step installation instructions, refer to Capítulo 8, Procedimiento de instalación de sistema operativo de huésped.
Verifique el entorno para migración
Asegúrese de que los puentes de red virtualizados estén configurados correctamente y tengan el mismo nombre en ambos hosts:
[et-virt08 ~]# brctl show
bridge name     bridge id               STP enabled     interfaces
xenbr1          8000.feffffffffff       no              peth1
vif0.1
[et-virt07 ~]# brctl show
bridge name     bridge id               STP enabled     interfaces
xenbr1          8000.feffffffffff       no              peth1
vif0.1
Verifique si los parámetros de reubicación están configurados en ambos hosts:
[et-virt07 ~]# grep xend-relocation /etc/xen/xend-config.sxp |grep -v '#'
(xend-relocation-server yes)
(xend-relocation-port 8002)
(xend-relocation-address '')
(xend-relocation-hosts-allow '')
[et-virt08 ~]# grep xend-relocation /etc/xen/xend-config.sxp |grep -v '#'
(xend-relocation-server yes)
(xend-relocation-port 8002)
(xend-relocation-address '')
(xend-relocation-hosts-allow '')
Asegúrese de que el servidor de reubicación haya iniciado y esté escuchando en el puerto dedicado para migraciones de Xen (8002):
[et-virt07 ~]# lsof -i :8002
COMMAND  PID  USER   FD   TYPE  DEVICE SIZE NODE NAME
python 3445 root 14u IPv4 10223 TCP *:teradataordbms (LISTEN)
[et-virt08 ~]# lsof -i :8002
COMMAND  PID USER   FD   TYPE DEVICE SIZE NODE NAME
python 3252 root 14u IPv4 10901 TCP *:teradataordbms (LISTEN)
That the default /var/lib/libvirt/images directory is available and mounted with networked storage on both hosts. Shared, networked storage is required for migrations.
[et-virt08 ~]# df /var/lib/libvirt/images
Filesystem           1K-blocks      Used Available Use% Mounted on
et-virt07:/var/lib/libvirt/images    70562400   2379712  64598336   4% /var/lib/libvirt/images
[et-virt08 ~]# file /var/lib/libvirt/images/testvm1.dsk 
/var/lib/libvirt/images/testvm1.dsk: x86 boot sector; partition 1: ID=0x83,
active, starthead 1, startsector 63, 208782 sectors; partition 2: ID=0x8e, 
starthead 0, startsector 208845, 10265535 sectors, code offset 0x48
[et-virt08 ~]# touch /var/lib/libvirt/images/foo
[et-virt08 ~]# rm -f /var/lib/libvirt/images/foo
Verifique guardar y restaurar el huésped
Inicie la máquina virtual (si la máquina virtual aún no lo ha hecho):
[et-virt07 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
[et-virt07 ~]# virsh start testvm1
Domain testvm1 started
Verifique si la máquina virtual está ejecutándose:
[et-virt07 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
testvm1        blocked
Guarde la máquina virtual en el host local:
[et-virt07 images]# time virsh save testvm1 testvm1.sav
real    0m15.744s
user    0m0.188s
sys     0m0.044s
[et-virt07 images]# ls -lrt testvm1.sav
-rwxr-xr-x 1 root root 1075657716 Jan 12 06:46 testvm1.sav
[et-virt07 images]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
Restablezca la máquina virtual en el host local:
[et-virt07 images]# virsh restore testvm1.sav
[et-virt07 images]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
testvm1        blocked
Start the live migration of domain-id from et-virt08 to et-virt07. The hostname you are migrating to and <domain-id> must be replaced with valid values. This example uses the et-virt08 host which must have SSH access to et-virt07
[et-virt08 ~]# xm migrate --live testvm1 et-virt07
Verify the virtual machine is no longer present on et-virt08
[et-virt08 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
Verify the virtual machine has been migrated to et-virt07:
[et-virt07 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
testvm1        running
Pruebe el progreso e inicie la migración en vivo
Create the following script inside the virtual machine to log date and hostname during the migration. This script performs I/O tasks on the guest's file system.
#!/bin/bash

while true
do
touch /var/tmp/$$.log
echo `hostname` >>  /var/tmp/$$.log
	echo `date`     >>  /var/tmp/$$.log
	cat  /var/tmp/$$.log
	df /var/tmp
	ls -l  /var/tmp/$$.log
	sleep 3
	done
Recuerde que ese script es únicamente para propósitos de prueba y no es necesario para una migración en vivo en un entorno de producción.
Verifique si la máquina virtual está ejecutándose en et-virt08 antes de tratar de migrarla a et-virt07:
[et-virt08 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
testvm1        blocked
Inicie una migración en vivo a et-virt07. Puede agregar el comando time para ver cuánto tiempo se toma la migración:
[et-virt08 ~]# xm migrate --live testvm1 et-virt07
Ejecute el script dentro del huésped:
# ./doit
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:27 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 62 Jan 12 02:26 /var/tmp/2279.log
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:27 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:30 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 124 Jan 12 02:26 /var/tmp/2279.log
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:27 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:30 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:33 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 186 Jan 12 02:26 /var/tmp/2279.log
Fri Jan 12 02:26:45 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:48 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:51 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:54:57 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:55:00 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:55:03 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 744 Jan 12 06:55 /var/tmp/2279.log
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:27 EST 2007
Verifique si la máquina virtual ha sido apagada en et-virt08:
[et-virt08 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
Verifique si la máquina virtual ha iniciado en et-virt07
[et-virt07 images]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
testvm1        blocked
Ejecute otro ciclo de migración de et-virt07 a et-virt08. Inicie una migración de et-virt07 a et-virt08:
[et-virt07 images]# xm migrate --live testvm1 et-virt08
Verifique si la máquina virtual ha sido apagada:
[et-virt07 images]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
Antes de iniciar la migración, inicie el script simple en el huésped y observe el cambio en el tiempo al migrar el huésped:
# ./doit
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:53 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 62 Jan 12 06:57 /var/tmp/2418.log
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:53 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:56 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 124 Jan 12 06:57 /var/tmp/2418.log
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:53 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:56 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:58:00 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 186 Jan 12 06:57 /var/tmp/2418.log
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:53 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:56 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:58:00 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:30:00 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 248 Jan 12 02:30 /var/tmp/2418.log
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:53 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:56 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:58:00 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:30:00 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:30:03 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 310 Jan 12 02:30 /var/tmp/2418.log
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:53 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:56 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:58:00 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:30:00 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:30:03 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:30:06 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 372 Jan 12 02:30 /var/tmp/2418.log
Después de que el comando de migración termina en et-virt07 verifique en et-virt08 si la máquina virtual ha iniciado:
[et-virt08 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
testvm1        blocked
y ejecute otro ciclo:
[et-virt08 ~]# time virsh migrate --live testvm1 et-virt07
real    0m10.378s
user    0m0.068s
sys     0m0.052s
Hasta el momento usted ha realizado con éxito una prueba de migración en vivo y desconectada.

20.2. Configurar la migración en vivo del huésped

Esta sección cubre la migración desconectada de huéspedes Xen a servidores que ejecutan Red Hat Enterprise Linux. Más adelante la migración se realiza en un método desconectado (utilizando el comando xm migrate). La migración en vivo se puede hacer con el mismo comando. Sin embargo, hay modificaciones adicionales que se deben llevar a cabo en el archivo de configuración xend-config. Este ejemplo identifica las entradas que deben ser modificadas para asegurar una migración exitosa:
(xend-relocation-server yes)
The default for this parameter is 'no', which keeps the relocation/migration server deactivated (unless on a trusted network) and the domain virtual memory is exchanged in raw form without encryption.
(xend-relocation-port 8002)
Este parámetro establece el puerto que xend utiliza para la migración. Utilice este valor a menos que su entorno de red requiera un valor específico. Remueva el símbolo de comentario para activarlo.
(xend-relocation-address )
Este parámetro es la dirección desde la cual se escuchan conexiones de socket de reubicación después de activar xend-relocation-server. El hipervisor Xen sólo escucha el tráfico de migración de red en una interfaz determinada.
(xend-relocation-hosts-allow )
Este parámetro controla el host que se comunica con el puerto de reubicación. Si el valor está vacío, entonces todas las conexiones entrantes son permitidas. Cámbielo a secuencias de expresiones regulares separadas por espacios, por ejemplo:
(xend-relocation-hosts-allow- '^localhost\\.localdomain$' )>
Los valores aceptados incluyen nombres de dominio completamente calificado, direcciones IP o expresiones regulares separadas por espacios.
Después de configurar, reinicie el host para cargar nuevas configuraciones.

Capítulo 21. Migración KVM en vivo

Este capítulo cubre el tema de huéspedes de migración que se ejecutan en un hipervisor de KVM a otro host de KVM.
Migration is the process of moving a virtualized guest from one host to another. Migration is a key feature of virtualization as software is completely separated from hardware. Migration is useful for:
  • Equilibrio de carga - Equilibrio de carga - los huéspedes pueden desplazarse a hosts de menor uso cuando un host aparece sobrecargado.
  • Recuperación de fallos de Hardware - cuando los dispositivos de hardware en el host comienzan a fallar, los huéspedes se pueden reubicar para que el host pueda ser apagado y reparado.
  • Ahorro de energía - los huéspedes pueden redistribuirse a otros hosts y sistemas de host apagados para ahorrar energía y cortar gastos en periodos de poco uso.
  • Migración geográfica - los huéspedes pueden ser desplazados a otro sitio para una latencia menor o en circunstancias graves.
Migrations can be performed live or offline. To migrate guests the storage must be shared. Migration works by sending the guests memory to the destination host. The shared storage stores the guest's default file system. The file system image is not sent over the network from the source host to the destination host.
Una migración desconectada interrumpe el huésped, luego desplaza una imagen de la memoria de huéspedes al host de destino. El huésped es retomado en el host de destino y la memoria que el huésped utilizó es liberada.
El tiempo de una migración desconectada depende del ancho de banda y de la latencia. Un huésped con 2GB de memoria debe tomarse un promedio de ten o más segundos en un enlace de Ethernet de 1 Gbit.
Una migración en vivo mantiene al huésped en ejecución en el host de origen y comienza por desplazar la memoria sin detener al huésped. Todas las páginas modificadas de memoria son monitorizadas para cambios y enviadas a su destino mientras se envía la imagen. La memoria se actualiza con las páginas cambiadas. El proceso continúa hasta que la cantidad de tiempo de pausa permitido para el huésped, sea igual al tiempo esperado para que las últimas páginas sean transferidas. KVM estima el tiempo restante e intenta transferir la cantidad máxima de archivos de página de la fuente al destino hasta que KVM prediga la cantidad de páginas restantes que pueden ser transferidas en un tiempo muy breve mientras el huésped virtualizado está en pausa. Los registros se cargan en el nuevo host y el huésped se reanuda entonces en el host de destino. Si el huésped no se puede fusionar (lo que sucede cuando los huéspedes están bajo cargas extremas), se interrumpe y, en su lugar, se inicia una migración desconectada.
El tiempo de una migración desconectada depende del ancho de banda y de la latencia. Si la red está utilizando una cantidad significativa de E/S o de CPU de banda ancha baja, la migración tomará más tiempo.

21.1. Requerimientos de migración en vivo

La migración de huéspedes requiere lo siguiente:
Requerimientos de migración
  • Un huésped virtualizado instalado en un almacenaje de red compartido mediante uno de los siguientes protocolos:
    • Canal de fibra
    • iSCSI
    • NFS
    • GFS2
  • Dos o más sistemas de Red Hat Enterprise Linux de la misma versión con algunas actualizaciones.
  • Ambos sistemas deben tener los puertos abiertos apropiados.
  • Ambos sistemas deben tener configuraciones de red idénticas. Todas las configuraciones de puente y de red deben ser exactamente iguales en ambos hosts.
  • El almacenaje compartido debe montarse en la misma ubicación en los sistemas de fuente y destino. El nombre de directorio montado debe ser idéntico.
Configuración de almacenaje de redes
Configure shared storage and install a guest on the shared storage. For shared storage instructions, refer to Parte V, “Virtualization Storage Topics”.

21.2. Ejemplo de almacenaje compartido: NFS para una migración sencilla

Este ejemplo utiliza NFS para compartir imágenes de huésped con otros hosts de KVM. Este ejemplo no es práctico para instalaciones grandes, este ejemplo es únicamente para demostrar técnicas de migración y pequeñas implementaciones. No utilice este ejemplo para migrar o ejecutar más de unos pocos huéspedes virtualizados.
For advanced and more robust shared storage instructions, refer to Parte V, “Virtualization Storage Topics”
  1. Exporte su directorio de imagen libvirt

    Añada el directorio de imagen predeterminado al archivo /etc/exports:
    /var/lib/libvirt/images *.example.com(rw,no_root_squash,async)
    
    Cambie el parámetro de huéspedes como se requiere para su entorno.
  2. Inicie NFS

    1. Instale los paquetes NFS si aún no han sido instalados:
      # yum install nfs
      
    2. Abra los puertos para NFS en iptables y añada NFS al archivo /etc/hosts.allow.
    3. Inicie el servicio NFS:
      # service nfs start
      
  3. Monte el almacenaje compartido de destino

    En el sistema de destino, monte el directorio /var/lib/libvirt/images:
    # mount sourceURL:/var/lib/libvirt/images /var/lib/libvirt/images
    

    Las ubicaciones deben ser las mismas en fuente y destino

    Sea cual sea el directorio que se escoja para los huéspedes debe ser exactamente lo mismo en host como en huésped. Esto también se aplica a todos los tipos de almacenaje compartido. El directorio deber ser el mismo o de lo contrario, la migración fallará.

21.3. Migración KVM en vivo con virsh

Un huésped puede ser migrado a otro host con el comando virsh. El comando migrate acepta parámetros en el siguiente formato:
# virsh migrate --live GuestName DestinationURL
El parámetro GuestName representa el nombre del huésped que usted quiere migrar.
El parámetro DestinationURL es la URL o el nombre de host del sistema de destino. El sistema de destino debe ejecutar la misma versión de Red Hat Enterprise Linux, estar usando el mismo hipervisor y tener a libvirt en ejecución.
Una vez se ha ingresado el comando, se le solicitará su contraseña de root del sistema de destino.
Ejemplo: migración en vivo con virsh
Este ejemplo migra desde test1.example.com a test2.example.com. Cambie los nombres de host para su entorno. Este ejemplo migra una máquina virtual llamada RHEL4test.
This example assumes you have fully configured shared storage and meet all the prerequisites (listed here: Requerimientos de migración).
  1. Verificar si el huésped está ejecutándose

    Desde el sistema fuente, test1.example.com, verifique si RHEL4test se está ejecutando:
    [root@test1 ~]# virsh list
    Id Name                 State
    ----------------------------------
     10 RHEL4                running
    
  2. Migrar el huésped

    Ejecute el siguiente comando para migrar en vivo el huésped al destino, test2.example.com. Añada /system al final de la URL de destino para decirle a libvirt que usted necesita acceso total.
    # virsh migrate --live RHEL4test qemu+ssh://test2.example.com/system
    Una vez se ha ingresado el comando, se le solicitará su contraseña de root del sistema de destino.
  3. Esperar

    La migración puede tomarse algún tiempo dependiendo de la carga y del tamaño del huésped. virsh sólo reporta errores. El huésped continúa ejecutándose en el host fuente hasta migrar completamente.
  4. Verificar si el huésped ha llegado al host de destino

    Desde el sistema de destino, test2.example.com, verifique si RHEL4test se está ejecutando:
    [root@test2 ~]# virsh list
    Id Name                 State
    ----------------------------------
     10 RHEL4                running
    
La migración en vivo ahora está completa.

Otros métodos de red

libvirt supports a variety of networking methods including TLS/SSL, unix sockets, SSH, and unencrypted TCP. Refer to Capítulo 22, Administración remota de huéspedes virtualizados for more information on using other methods.

21.4. Migración con virt-manager

Esta sección cubre la migración de huéspedes basados en KVM con virt-manager.
  1. Conecte los hosts de origen y destino. En el menú Archivo, haga clic en Añadir conexión, la ventana Añadir conexión aparecerá.
    Ingrese la siguiente información:
    • Hipervisor: Seleccione QEMU.
    • Conexión: Seleccione el tipo de conexión.
    • Nombredehost: Ingrese el nombre del host.
    Haga clic en Conectar.
    El administrador de la máquina virtual muestra una lista de los hosts conectados.
  2. Agregue un grupo de almacenaje con el mismo NFS a la fuente y hosts de destino.
    En el menú Editar, haga clic en Información de host, la ventana de información de host aparecerá.
    Haga clic en la pestaña Almacenaje.
  3. Agregue un nuevo grupo de almacenaje. En la esquina inferior izquierda de la ventana, haga clic en el botón +. La ventana de Agregar un nuevo grupo de almacenaje, aparecerá.
    Ingrese la siguiente información:
    • Nombre: Entrar el nombre del grupo de almacenaje.
    • Tipo: Seleccionar netfs: Directorio de red exportado.
    Haga clic en Adelante.
  4. Ingrese la siguiente información:
    • Formato: Seleccione el tipo de almacenaje. Éste debe ser NFS o iSCSI para migraciones en vivo.
    • Nombre de host: Entra la dirección IP o el nombre de dominio totalmente cualificado del servidor de almacenaje.
    Haga clic en Terminar.
  5. Cree un nuevo volumen en el grupo de almacenaje compartido, haga clic en Nuevo volumen.
  6. Ingrese los detalles, luego haga clic en Crear volumen.
  7. Cree una máquina virtual con el nuevo volumen, luego ejecute la máquina virtual.
    Aparecerá la Ventana de máquina virtual.
  8. En la ventana de la máquina virtual, haga clic derecho en la máquina virtual, seleccione Migrar, luego haga clic en la ubicación de la migración.
  9. Haga clic en para confirmar la migración.
    The Virtual Machine Manager displays the virtual machine in its new location.
    The VNC connection displays the remote host's address in its title bar.

Capítulo 22. Administración remota de huéspedes virtualizados

Esta sección explica cómo administrar de forma remota los huéspedes virtualizados mediante ssh o TLS y SSL.

22.1. Administración remota con SSH

El paquete ssh proporciona un protocolo de red encriptado, el cual puede enviar funciones de administración seguras a servidores de virtualización remotos. El método descrito utiliza administración de conexión segura de libvirt en túnel en conexión SSH para administrar máquinas remotas. Toda la autenticación se realiza a través de la criptografía de llave pública SSH y contraseñas y frases de acceso reunidas por el agente local SSH. Además la consola VNC para cada máquina virtual de huésped es puesta en túnel a través de SSH.
SSH suele estar configurado por defecto, por lo tanto, probablemente ya tiene llaves SSH configuradas y no necesita reglas de Firewall adicionales para acceder al servicio de administración o consola VNC.
Tenga presentes los problemas que se pueden presentar al usar SSH para manejar de forma remota sus máquinas virtuales, incluyendo:
  • Se requiere registro de root para acceder a la máquina remota para máquinas virtuales,
  • El proceso de configuración de conexión inicial puede ser lento,
  • there is no standard or trivial way to revoke a user's key on all hosts or guests, and
  • ssh no escala bien con grandes cantidades de máquinas remotas
Configuring password less or password managed SSH access for virt-manager
The following instructions assume you are starting from scratch and do not already have SSH keys set up. If you have SSH keys set up and copied to the other systems you can skip this procedure.

The user is important for remote management

SSH keys are user dependent. Only the user who owns the key may access that key.
virt-manager must run as the user who owns the keys to connect to the remote host. That means, if the remote systems are managed by a non-root user virt-manager must be run in unprivileged mode. If the remote systems are managed by the local root user then the SSH keys must be own and created by root.
You cannot manage the local host as an unprivileged user with virt-manager.
  1. Optional: Changing user

    Change user, if required. This example uses the local root user for remotely managing the other hosts and the local host.
    $ su -
  2. Generating the SSH key pair

    Generate a public key pair on the machine virt-manager is used. This example uses the default key location, in the ~/.ssh/ directory.
    $ ssh-keygen -t rsa
    
  3. Coping the keys to the remote hosts

    Remote login without a password, or with a passphrase, requires an SSH key to be distributed to the systems being managed. Use the ssh-copy-id command to copy the key to root user at the system address provided (in the example, root@example.com).
    # ssh-copy-id -i ~/.ssh/id_rsa.pub root@example.com root@example.com's password: Now try logging into the machine, with "ssh 'root@example.com'", and check in: .ssh/authorized_keys to make sure we haven't added extra keys that you weren't expecting 
    
    Repeat for other systems, as required.
  4. Optional: Add the passphrase to the ssh-agent

    Add the passphrase for the SSH key to the ssh-agent, if required. On the local host, use the following command to add the passphrase (if there was one) to enable password-less login.
    # ssh-add ~/.ssh/id_rsa.pub
The SSH key was added to the remote system.
El demonio libvirt (libvirtd)
The libvirt daemon provide an interface for managing virtual machines. You must have the libvirtd daemon installed and running on every remote host that needs managing.
$ ssh root@somehost
# chkconfig libvirtd on
# service libvirtd start
Después de que libvirtd y SSH sean configurados, debe poder acceder y administrar las máquinas virtuales de forma remota. También podrá tener acceso a los huéspedes con VNC en este punto.
Accessing remote hosts with virt-manager
Remote hosts can be managed with the virt-manager GUI tool. SSH keys must belong to the user executing virt-manager for password-less login to work.
  1. Start virt-manager.
  2. Open the File->Add Connection menu.
  3. Input values for the hypervisor type, the connection, Connection->Remote tunnel over SSH, and enter the desired hostname, then click connection.

22.2. Administración remota en TLS y SSL

You can manage virtual machines using TLS and SSL. TLS and SSL provides greater scalability but is more complicated than ssh (refer to Sección 22.1, “Administración remota con SSH”). TLS and SSL is the same technology used by web browsers for secure connections. The libvirt management connection opens a TCP port for incoming connections, which is securely encrypted and authenticated based on x509 certificates. In addition the VNC console for each guest virtual machine will be setup to use TLS with x509 certificate authentication.
This method does not require shell accounts on the remote machines being managed. However, extra firewall rules are needed to access the management service or VNC console. Certificate revocation lists can revoke users' access.
Pasos para configurar el acceso a TLS/SSL para virt-manager
La siguiente guía supone que se esta empezando de cero y que no se tiene conocimiento del certificado TLS/SSL. Si tiene la suerte de contar con un servidor de administración de certificado, probablemente puede pasar por alto estos pasos.
Configurar servidor de libvirt
Para mayor información sobre la creación de certificados, consulte libvirt en el sitio Web, http://libvirt.org/remote.html.
Servidor Xen VNC
El servidor Xen VNC puede habilitar TLS al editar el archivo de configuración, /etc/xen/xend-config.sxp. Elimine el comentario en el parámetro de configuración (vnc-tls 1) en el archivo de configuración.
The /etc/xen/vnc directory needs the following 3 files:
  • ca-cert.pem - The CA certificate
  • server-cert.pem - The Server certificate signed by the CA
  • server-key.pem - The server private key
This provides encryption of the data channel. It might be appropriate to require that clients present their own x509 certificate as a form of authentication. To enable this remove the commenting on the (vnc-x509-verify 1) parameter.
Configuración de cliente virt-manager y virsh
La configuración para cliente es un poco inconsistente en este momento. Para permitir la administración API de libvirt en TLS, los certificados CA y de cliente se deben ubicar en /etc/pki. Para mayor información, consulte http://libvirt.org/remote.html
In the virt-manager user interface, use the 'SSL/TLS' transport mechanism option when connecting to a host.
Para virsh, el URI tiene el siguiente formato:
  • qemu://hostname.guestname/system para KVM.
  • xen://hostname.guestname/ para Xen.
Para habilitar SSL y TLS para VNC, es necesario poner la autoridad de certificado y los certificados de cliente dentro de $HOME/.pki, es decir en los tres archivos siguientes:
  • El certificado de CA - CA o ca-cert.pem.
  • El certificado de cliente firmado por la CA - libvirt-vnc o clientcert.pem.
  • La llave privada de cliente - libvirt-vnc o clientkey.pem.

22.3. Modos de transporte

Para administración remota, libvirt soporta los siguientes modos de transporte:
Seguridad de la capa de transporte, TLS (siglas en Inglés para Transport Layer Security)
La seguridad de capa de transporte TLS 1.0 (SSL 3.1) autenticada y el socket TCP/IP encriptado, el cual escucha generalmente en un número de puerto público. Para utilizarlo es necesario generar certificados de cliente y servidor. El puerto estándar es 16514.
sockets de UNIX
Los sockets de dominio UNIX sólo se pueden acceder en la máquina local. Los sockets no están encriptados y utilizan permisos de UNIX o SELinux para autenticación. Los nombres de socket estándar son /var/run/libvirt/libvirt-sock y /var/run/libvirt/libvirt-sock-ro (para conexiones de sólo lectura).
SSH
Conexión de protocolo de Shell segura (SSH). Necesita que Netcat (el paquete nc) esté instalado. El demonio libvirt (libvirtd) debe estar ejecutándose en una máquina remota. El puerto 22 debe estar abierto para acceso de SSH. Se debe utilizar una clase de administración de llave SSH (por ejemplo, la utilidad de ssh-agent) de lo contrario, se le pedirá una contraseña.
ext
El parámetro ext se utiliza para cualquier programa externo que pueda hacer una conexión a una máquina remota por medios que están fuera del ámbito de libvirt. Este parámetro no tiene soporte.
tcp
El socket TCP/IP sin encriptar. No se recomienda para uso de producción, por lo general está desactivado, pero un administrador lo puede habilitar para ensayarlo o utilizarlo en una red de confianza. El puerto predeterminado es 16509.
El transporte predeterminado es TLS, si no se especifica otro.
URI remotos
Un Identificador de recursos uniforme, URI (siglas en Inglés para Uniform Resource Identifier), es utilizado por virsh y libvirt para conectar a un host remoto. Los URI también se utilizan con el parámetro --connect para que el comando virsh ejecute comandos sencillos o migraciones en hosts remotos.
Los URI de libvirt adquieren la forma general (contenido en paréntesis cuadrados, "[]", representan las funciones opcionales):
driver[+transport]://[username@][hostname][:port]/[path][?extraparameters]
El método de transporte o el nombre de host se debe indicar para apuntar a una ubicación externa.
Ejemplos de parámetros de administración remotos
  • Conectar un hipervisor Xen remoto en el host llamado towada, mediante el transporte SSH y el nombre de usuario ccurran.
    xen+ssh://ccurran@towada/
    
  • Conectar a un hipervisor Xen remoto en el host llamado towada mediante TLS.
    xen://towada/
    
  • Connect to a remote Xen hypervisor on host towada using TLS. The no_verify=1 tells libvirt not to verify the server's certificate.
    xen://towada/?no_verify=1
    
  • Conectar a un hipervisor KVM remoto en un host towada mediante SSH.
    qemu+ssh://towada/system
    
Prueba de ejemplos
  • Conectar al hipervisor KVM local con un socket UNIX estándar. La ruta completa del socket de UNIX se proporciona explícitamente en este caso.
    qemu+unix:///system?socket=/opt/libvirt/run/libvirt/libvirt-sock
    
  • Conectar al demonio libvirt con una conexión encriptada de TCP/IP al servidor con la dirección IP 10.1.1.10 en puerto 5000. Éste utiliza el controlador de prueba con configuración predeterminada.
    test+tcp://10.1.1.10:5000/default
    
Parámetros adicionales del URI
Extra parameters can be appended to remote URIs. The table below Tabla 22.1, “Parámetros adicionales del URI” covers the recognized parameters. All other parameters are ignored. Note that parameter values must be URI-escaped (that is, a question mark (?) is appended before the parameter and special characters are converted into the URI format).
Tabla 22.1. Parámetros adicionales del URI
Nombre Modo de transporte Descripción Uso de ejemplo
nombre todos los modos El nombre pasado a la función remota virConnectOpen. El nombre se forma generalmente al eliminar transporte, nombre de host, número de puerto, nombre de usuario y parámetros adicionales desde el URI remoto, pero en algunos casos muy complejos puede ser mejor proporcionar explícitamente el nombre. name=qemu:///system
comando ssh y ext El comando externo. Para transporte ext este comando es requerido. Para ssh el predeterminado es ssh. La ruta es buscada por el comando. command=/opt/openssh/bin/ssh
socket unix y ssh La ruta al socket de dominio de UNIX, la cual sobrescribe la predeterminada. Para transporte ssh, pasa al comando netcat remoto (ver netcat). socket=/opt/libvirt/run/libvirt/libvirt-sock
netcat ssh
El comando netcat sirve para conectar sistemas remotos. El parámetro predeterminado de netcat utiliza el comando nc. Para transporte SSH, libvirt construye un comando SSH de la siguiente manera:
								command -p port [-l username] hostname
								netcat -U socket
Los parámetros port, username y hostname se pueden especificar como parte del URI remoto. command, netcat y socket surgen de parámetros adicionales.
netcat=/opt/netcat/bin/nc
no_verify tls If set to a non-zero value, this disables client checks of the server's certificate. Note that to disable server checks of the client's certificate or IP address you must change the libvirtd configuration. no_verify=1
no_tty ssh Si se establece a un valor de no-cero, ssh deja de pedir la contraseña si no puede ingresar automáticamente a una máquina remota (para usar el agente ssh o similar). Utilícelo cuando no tenga acceso a la terminal - por ejemplo, en programas gráficos que utilizan libvirt. no_tty=1

Parte V. Virtualization Storage Topics

Introduction to storage administration for virtualization

This part covers using shared, networked storage with virtualization on Red Hat Enterprise Linux.
The following methods are supported for virtualization:
  • Fibre Channel
  • iSCSI
  • NFS
  • GFS2
Networked storage is essential for live and offline guest migrations. You cannot migrate guests without shared storage.

Capítulo 23. Using shared storage with virtual disk images

This chapter covers the use of shared and network storage devices for virtual disks.

23.1. Using iSCSI for storing virtual disk images

This section demonstrates how to set up an iSCSI target on Red Hat Enterprise Linux and how to configure iSCSI on a libvirt KVM host using virsh, and finally how to provision a guest on iSCSI using virt-install.

Importante

Setting up a Red Hat Enterprise Linux server as an iSCSI target is not recommended. The example used in this section should not be used in production, and is provided as an example which should only be referred to for basic shared storage testing and educational purposes.

23.1.1. How to set up an iSCSI target on Red Hat Enterprise Linux

  1. Install and enable the iSCSI target service

    Install and enable the iSCSI target service with the following commands:
    # yum install scsi-target-utils
    # chkconfig tgtd on
    # service tgtd start
    

    Importante

    The scsi-target-utils package required for this example is provided only in the Cluster Storage add-on for Red Hat Enterprise Linux 5, and may not be available for your system. Contact your support agent to activate this add-on if you are currently unable to install this package.
  2. Allocate storage for the LUNs

    The iSCSI target service is not dependent on a particular type of exported LUN. The LUNs can be plain files, LVM volumes, or block devices. There is however a performance overhead if using the LVM and/or file system layers as compared to block devices. The guest providing the iSCSI service in this example has no spare block or LVM devices, so raw files will be used.
    This example demonstrates the creation of two LUNs; one is a 10GB thin-provisioned (sparse file) LUN, and the other has 500MB, of which are fully-allocated. The following commands will achieve this configuration. Be aware that your environment will be different and this is provided only as an example:
    # mkdir -p /var/lib/tgtd/kvmguest
    # dd if=/dev/zero of=/var/lib/tgtd/kvmguest/rhelx86_64.img bs=1M seek=10240 count=0
    # dd if=/dev/zero of=/var/lib/tgtd/kvmguest/shareddata.img bs=1M count=512
    # restorecon -R /var/lib/tgtd
    
  3. Export the iSCSI target and LUNs

    For Red Hat Enterprise Linux 5, a series of tgtadm commands is required to create a target and associate the storage volumes created earlier. First, the following command adds a target using an iSCSI Qualified Name (IQN):
    # tgtadm --lld iscsi --op new --mode target --tid 1 --targetname \ 
    iqn.2004-04.rhel:rhel5:iscsi.kvmguest
    
    Now the storage volumes must be associated with LUNs in the iSCSI target with these two commands:
    # tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 1 \
    --backing-store /var/lib/tgtd/kvmguest/rhelx86_64.img
    
    # tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 2 \
    --backing-store /var/lib/tgtd/kvmguest/shareddata.img
    

    Importante

    Add the previous 3 tgtadm commands to the end of the /etc/rc.local file to ensure normal operation upon restarting of the system.
    To confirm the successful operation of the previous commands, query the iSCSI target setup:
    tgtadm --lld iscsi --op show --mode target
    Target 1: iqn.2004-04.rhel:rhel5:iscsi.kvmguest
        System information:
            Driver: iscsi
            State: ready
        I_T nexus information:
        LUN information:
            LUN: 0
                Type: controller
                SCSI ID: IET     00010000
                SCSI SN: beaf10
                Size: 0 MB, Block size: 1
                Online: Yes
                Removable media: No
                Readonly: No
                Backing store type: null
                Backing store path: None
                Backing store flags: 
            LUN: 1
                Type: disk
                SCSI ID: IET     00010001
                SCSI SN: beaf11
                Size: 10737 MB, Block size: 512
                Online: Yes
                Removable media: No
                Readonly: No
                Backing store type: rdwr
                Backing store path: /var/lib/tgtd/kvmguest/rhelx86_64.img
                Backing store flags: 
            LUN: 2
                Type: disk
                SCSI ID: IET     00010002
                SCSI SN: beaf12
                Size: 537 MB, Block size: 512
                Online: Yes
                Removable media: No
                Readonly: No
                Backing store type: rdwr
                Backing store path: /var/lib/tgtd/kvmguest/shareddata.img
                Backing store flags: 
        Account information:
        ACL information:
    
  4. Allow client access to the target

    Finally, this example command allows access to all clients without any authentication:
    # tgtadm --lld iscsi --op bind --mode target --tid 1 --initiator-address ALL
    

Two common mistakes

The two most common problems encountered when configuring the iSCSI target are SELinux and iptables. If adding plain files as LUNs in an iSCSI target, ensure the files are labelled system_u:object_r:tgtd_var_lib_t:s0. TCP port 3260 must also be open in your iptables configuration.

23.1.2. How to configure iSCSI on a libvirt KVM host and provision a guest using virt-install

The previous section described how to set up an iSCSI target. This section demonstrates how to configure iSCSI on a libvirt KVM instance using virsh, and then how to provision a guest using virt-install.
  1. Defining the storage pool

    All libvirt storage is managed through storage pools, of which there are many possible types: SCSI, NFS, ext4, plain directory and iSCSI. All libvirt objects are configured via XML description files, and storage pools are no different in this regard. For an iSCSI storage pool there are three important pieces of information to provide:
    • The target path - this determines how libvirt will expose device paths for the pool. Paths like /dev/sda and /dev/sdb are not an ideal choice as they can change between reboots, and can change across machines within a cluster; in other words, the names are assigned on a first come, first served basis by the kernel. It is strongly recommended to use the /dev/disk/by-path format. This results in a consistent naming scheme across all machines.
    • The host name - this is simply the fully-qualified DNS name of the iSCSI server.
    • The source path - this is the iSCSI qualified name (IQN) seen in the previous setup procedure (iqn.2004-04.rhel:rhel5:iscsi.kvmguest).
    Although your environment will likely be different, the following text is what an iSCSI configuration will look like:
    <pool type='iscsi'>
        <name>kvmguest</name>
        <source>
            <host name='myiscsi.example.com'/>
            <device path='iqn.2004-04.rhel:rhel5:iscsi.kvmguest'/>
        </source>
        <target>
            <path>/dev/disk/by-path</path>
        </target>
    </pool>
    
    Save this XML code to a file named iscsirhel5.xml and load it into libvirt using the pool-define command:
    # virsh pool-define iscsirhel5.xml
    Pool kvmguest defined from iscsirhel5.xml
    
    # virsh pool-list --all
    Name                 State      Autostart
    -----------------------------------------
    default              active     yes
    kvmguest             inactive   no
    
  2. Starting the storage pool

    The configuration is saved, but the iSCSI target has not yet been logged into, so no LUNs will be visible on the host at this point. Use the pool-start command the make the LUNs visible with the vol-list command.
    # virsh pool-start kvmguest
    Pool kvmguest started
    
    # virsh vol-list kvmguest
    Name                 Path
    -----------------------------------------
    10.0.0.1             /dev/disk/by-path/ip-192.168.122.2:3260-iscsi-iqn.2004-04.rhel:rhel5:iscsi.kvmguest-lun-1
    10.0.0.2             /dev/disk/by-path/ip-192.168.122.2:3260-iscsi-iqn.2004-04.rhel:rhel5:iscsi.kvmguest-lun-2
    
  3. Querying LUN information

    Further information about each LUN can be obtained using the vol-info and vol-dumpxml commands:
    # virsh vol-info /dev/disk/by-path/ip-192.168.122.2:3260-iscsi-iqn.2004-04.rhel:rhel5:iscsi.kvmguest-lun-1
    
    Name:           10.0.0.1
    Type:           block
    Capacity:       10.00 GB
    Allocation:     10.00 GB
    
    
    # virsh vol-dumpxml /dev/disk/by-path/ip-192.168.122.2:3260-iscsi-iqn.2004-04.rhel:rhel5:iscsi.kvmguest-lun-1
    <volume>
      <name>10.0.0.1</name>
      <key>/dev/disk/by-path/ip-192.168.122.2:3260-iscsi-iqn.2004-04.rhel:rhel5:iscsi.kvmguest-lun-1</key>
      <source>
      </source>
      <capacity>10737418240</capacity>
      <allocation>10737418240</allocation>
      <target>
        <path>/dev/disk/by-path/ip-192.168.122.2:3260-iscsi-iqn.2004-04.rhel:rhel5:iscsi.kvmguest-lun-2</path>
        <format type='unknown'/>
        <permissions>
          <mode>0660</mode>
          <owner>0</owner>
          <group>6</group>
          <label>system_u:object_r:fixed_disk_device_t:s0</label>
        </permissions>
      </target>
    </volume>
    
  4. Activating the storage at boot time

    If everything is configured properly, the pool can be set to start automatically upon booting of the host:
    # virsh pool-autostart kvmguest
    Pool kvmguest marked as autostarted
    
  5. Provisioning a guest on iSCSI

    The virt-install command can be used to install new guests from the command line. The --disk argument can take the name of a storage pool, followed by the name of any contained volumes. Continuing this example, the following command will begin the installation of a guest with two disks; the first disk is the root file system, the second disk can be shared between multiple guests for common data:
    # virt-install --accelerate --name rhelx86_64 --ram 800 --vnc --disk \ vol=kvmguest/10.0.0.1 --disk vol=kvmguest/10.0.0.2,perms=sh --pxe
    
    Once this rhelx86_64 guest is installed, the following command and output shows the XML that virt-install used to associate the guest with the iSCSI LUNs:
    # virsh dumpxml rhelx86_64
    
    <domain type='kvm' id='4'>
      <name>rhelx86_64</name>
      <uuid>ad8961e9-156f-746f-5a4e-f220bfafd08d</uuid>
      <memory>819200</memory>
      <currentMemory>819200</currentMemory>
      <vcpu>1</vcpu>
      <os>
        <type arch='x86_64' machine='rhel'>hvm</type>
        <boot dev='network'/>
      </os>
      <features>
        <acpi/>
        <apic/>
        <pae/>
      </features>
      <clock offset='utc'/>
      <on_poweroff>destroy</on_poweroff>
      <on_reboot>destroy</on_reboot>
      <on_crash>destroy</on_crash>
      <devices>
        <emulator>/usr/libexec/qemu-kvm</emulator>
        <disk type='block' device='disk'>
          <driver name='qemu' type='raw'/>
          <source dev='/dev/disk/by-path/ip-192.168.122.170:3260-iscsi-iqn.2004-04.rhel:rhel5:iscsi.kvmguest-lun-1'/>
          <target dev='hda' bus='ide'/>
          <alias name='ide0-0-0'/>
          <address type='drive' controller='0' bus='0' unit='0'/>
        </disk>
        <disk type='block' device='disk'>
          <driver name='qemu' type='raw'/>
          <source dev='/dev/disk/by-path/ip-192.168.122.170:3260-iscsi-iqn.2004-04.rhel:rhel5:iscsi.kvmguest-lun-2'/>
          <target dev='hdb' bus='ide'/>
          <shareable/>
          <alias name='ide0-0-1'/>
          <address type='drive' controller='0' bus='0' unit='1'/>
        </disk>
        <controller type='ide' index='0'>
          <alias name='ide0'/>
          <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
        </controller>
        <interface type='network'>
          <mac address='52:54:00:0a:ca:84'/>
          <source network='default'/>
          <target dev='vnet1'/>
          <alias name='net0'/>
          <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
        </interface>
        <serial type='pty'>
          <source path='/dev/pts/28'/>
          <target port='0'/>
          <alias name='serial0'/>
        </serial>
        <console type='pty' tty='/dev/pts/28'>
          <source path='/dev/pts/28'/>
          <target port='0'/>
          <alias name='serial0'/>
        </console>
        <input type='mouse' bus='ps2'/>
        <graphics type='vnc' port='5901' autoport='yes' keymap='en-us'/>
        <video>
          <model type='cirrus' vram='9216' heads='1'/>
          <alias name='video0'/>
          <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
        </video>
      </devices>
    </domain>
    
    There are two important items of note in this output:
    • The guest uses the large /dev/disk/by-path paths to refer to the LUNs. As described earlier, this is so that file names and paths will remain constant.
    • The second disk has the <shareable/> flag set. Critical for the disk to be safely shared between guests, this ensures that the SELinux labelling will be appropriate for multiple guests to access the disk and that all I/O caching is disabled on the host.
For migration of guests between hosts to succeed, some form of shared storage is required. Although NFS is often used for this purpose, the lack of SELinux labelling for NFS means there is limited sVirt protection between guests. This lack of sVirt support could allow one guest to use another guest's disks, which is usually undesirable.
Using iSCSI provides full sVirt isolation between guests to the same degree of non-shared storage.

Parte VI. Manual de referencia de virtualización

Capítulo 24. Herramientas de virtualización

La siguiente es una lista para la administración de las herramientas de virtualización, depuración y redes que sirven para los sistemas que ejecutan Xen.
Herramientas de administración de sistemas
  • vmstat
  • iostat
  • lsof
    # lsof -i :5900
    xen-vncfb 10635  root  5u  IPv4 218738  TCP grumble.boston.redhat.com:5900 (LISTEN)
    
  • qemu-img
Herramientas avanzadas de depuración
  • systemTap
  • crash
  • xen-gdbserver
  • sysrq
  • sysrq t
  • sysrq w
  • sysrq c
Creación de redes
brtcl
  • # brctl show
    bridge name  bridge id            STP enabled    interfaces
    xenbr0       8000.feffffffffff    no             vif13.0
    						 pdummy0
                                                     vif0.0
    
  • # brctl showmacs xenbr0
    port no  mac addr                is local?       aging timer
      1      fe:ff:ff:ff:ff:ff       yes             0.00
    
  • # brctl showstp xenbr0
    xenbr0
    bridge id              8000.feffffffffff
    designated root        8000.feffffffffff
    root port              0                    path cost                 0
    max age                20.00                bridge max age            20.00
    hello time             2.00                 bridge hello time         2.00
    forward delay          0.00                 bridge forward delay      0.00
    aging time            300.01
    hello timer            1.43                 tcn timer                 0.00
    topology change timer  0.00                 gc timer                  0.02
    flags
    
    vif13.0 (3)
    port id                8003                 state                    forwarding
    designated root        8000.feffffffffff    path cost                100
    designated bridge      8000.feffffffffff    message age timer        0.00
    designated port        8003                 forward delay timer      0.00
    designated cost        0                    hold timer               0.43
    flags
    
    pdummy0 (2)
    port id                8002                 state                    forwarding
    designated root        8000.feffffffffff    path cost                100
    designated bridge      8000.feffffffffff    message age timer        0.00
    designated port        8002                 forward delay timer      0.00
    designated cost        0                    hold timer               0.43
    flags
    
    vif0.0 (1)
    port id                8001                 state                    forwarding
    designated root        8000.feffffffffff    path cost                100
    designated bridge      8000.feffffffffff    message age timer        0.00
    designated port        8001                 forward delay timer      0.00
    designated cost        0                    hold timer               0.43
    flags
    
  • ifconfig
  • tcpdump
Herramientas KVM
  • ps
  • pstree
  • top
  • kvmtrace
  • kvm_stat
Herramientas Xen
  • xentop
  • xm dmesg
  • xm log

Capítulo 25. Administración de huéspedes con virsh

virsh es una herramienta de línea de comando para administrar a los huéspedes y al hipervisor.
La herramienta virsh se crea en la API de administración libvirt y funciona como una alternativa para el comando xm y el Administrador de huésped gráfico (virt-manager). virsh puede ser utilizado en modo de sólo lectura por usuarios sin privilegios. Se puede utilizar virsh para ejecutar scripts para las máquinas de huésped.
referencia rápida del comando virsh
La siguientes tablas son una rápida referencia para todas las opciones de línea de comandos de virsh.
Tabla 25.1. Comandos de administración de huésped
Comando Descripción
help Imprime información de ayuda básica.
list Lista todos los huéspedes.
dumpxml Entrega el archivo de configuración XML para el huésped.
create Crea un huésped desde un archivo de configuración XML e inicia el nuevo huésped.
start Inicia un huésped inactivo.
destroy Obliga a un huésped a detenerse.
define Entrega un archivo de configuración XML para un huésped.
domid Displays the guest's ID.
domuuid Displays the guest's UUID.
dominfo Muestra información de huésped.
domname Displays the guest's name.
domstate Muestra el estado de un huésped.
quit Sale de la terminal interactiva.
reboot Reinicia un huésped.
restore Restaura una sesión guardada anteriormente en un archivo.
resume Reanuda un huésped en pausa.
save Guarda el estado de un huésped en un archivo
shutdown Apaga un huésped de forma apropiada.
suspend Pone en pausa a un huésped.
undefine Borra todos los archivos asociados con un huésped.
migrate Migra un huésped a otros host.

Las siguientes opciones de comandos de virsh administran los recursos de huésped e hipervisor:
Tabla 25.2. Opciones de administración de recursos
Comando Descripción
setmem Establece la memoria asignada para un huésped.
setmaxmem Establece el límite máximo de memoria para el hipervisor.
setvcpus Cambia el número de CPU virtuales asignadas a un huésped.
vcpuinfo Muestra información de CPU virtual sobre un huésped.
vcpupin Controla la afinidad de CPU virtual de un huésped.
domblkstat Muestra las estadísticas de dispositivo de bloque para un huésped en ejecución.
domifstat Muestra estadísticas de interfaz de red para un huésped en ejecución.
attach-device Conecta un dispositivo a un huésped, mediante la definición de un dispositivo en un archivo XML.
attach-disk Conecta un nuevo dispositivo de disco para un huésped.
attach-interface Conecta una nueva interfaz de red para un huésped.
detach-device Desconecta un dispositivo de un huésped, adquiere la misma clase de descripciones del comando attach-device.
detach-disk Desconecta un dispositivo de disco desde un huésped.
detach-interface Desconecta una interfaz de red de un huésped.

Estas son las opciones misceláneas de virsh:
Tabla 25.3. Opciones misceláneas
Comando Descripción
version Muestra la versión de virsh
nodeinfo Entrega información acerca del hipervisor

Conexión al hipervisor
Conectar a la sesión del hipervisor con virsh:
# virsh connect {hostname OR URL}
Donde <name> es el nombre de la máquina del hipervisor. Para iniciar una conexión de sólo-lectura, añada el comando anterior a -readonly.
Creación de un volcado de máquina virtual XML (archivo de configuración)
Output a guest's XML configuration file with virsh:
# virsh dumpxml {domain-id, domain-name or domain-uuid}
This command outputs the guest's XML configuration file to standard out (stdout). You can save the data by piping the output to a file. An example of piping the output to a file called guest.xml:
# virsh dumpxml GuestID > guest.xml
This file guest.xml can recreate the guest (refer to Editing a guest's configuration file. You can edit this XML configuration file to configure additional devices or to deploy additional guests. Refer to Sección 33.1, “Uso de los archivos de configuración XML con virsh” for more information on modifying files created with virsh dumpxml.
Un ejemplo de salida de virsh dumpxml:
# virsh dumpxml r5b2-mySQL01
<domain type='xen' id='13'>
    <name>r5b2-mySQL01</name>
    <uuid>4a4c59a7ee3fc78196e4288f2862f011</uuid>
    <bootloader>/usr/bin/pygrub</bootloader>
    <os>
        <type>linux</type>
        <kernel>/var/lib/libvirt/vmlinuz.2dgnU_</kernel>
	<initrd>/var/lib/libvirt/initrd.UQafMw</initrd>
        <cmdline>ro root=/dev/VolGroup00/LogVol00 rhgb quiet</cmdline>
    </os>
    <memory>512000</memory>
    <vcpu>1</vcpu>
    <on_poweroff>destroy</on_poweroff>
    <on_reboot>restart</on_reboot>
    <on_crash>restart</on_crash>
    <devices>
        <interface type='bridge'>
            <source bridge='xenbr0'/>
            <mac address='00:16:3e:49:1d:11'/>
            <script path='vif-bridge'/>
        </interface>
        <graphics type='vnc' port='5900'/>
        <console tty='/dev/pts/4'/>
    </devices>
</domain>
Creación de un huésped desde el archivo de configuración
Guests can be created from XML configuration files. You can copy existing XML from previously created guests or use the dumpxml option (refer to Creación de un volcado de máquina virtual XML (archivo de configuración)). To create a guest with virsh from an XML file:
# virsh create configuration_file.xml
Editing a guest's configuration file
Instead of using the dumpxml option (refer to Creación de un volcado de máquina virtual XML (archivo de configuración)) guests can be edited either while they run or while they are offline. The virsh edit command provides this functionality. For example, to edit the guest named softwaretesting:
# virsh edit softwaretesting
Éste abre un editor de texto. El editor de texto predeterminado es el parámetro de shell $EDITOR (configure vi por defecto).
Suspender un huésped
Suspende un huésped con virsh:
# virsh suspend {domain-id, domain-name or domain-uuid}
When a guest is in a suspended state, it consumes system RAM but not processor resources. Disk and network I/O does not occur while the guest is suspended. This operation is immediate and the guest can be restarted with the resume (Reanudar un huésped) option.
Reanudar un huésped
Restaure un huésped suspendido con virsh mediante la opción resume:
# virsh resume {domain-id, domain-name or domain-uuid}
Esta operación es inmediata y los parámetros de huésped son preservados para operaciones suspend y resume.
Guardar un huésped
Guarde el estado actual de un huésped en un archivo mediante el comando virsh:
# virsh save {domain-name, domain-id or domain-uuid} filename
This stops the guest you specify and saves the data to a file, which may take some time given the amount of memory in use by your guest. You can restore the state of the guest with the restore (Restaurar un huésped) option. Save is similar to pause, instead of just pausing a guest the present state of the guest is saved.
Restaurar un huésped
Restore a guest previously saved with the virsh save command (Guardar un huésped) using virsh:
# virsh restore filename
This restarts the saved guest, which may take some time. The guest's name and UUID are preserved but are allocated for a new id.
Apagar un huésped
Apaga un huésped mediante el comando virsh:
# virsh shutdown {domain-id, domain-name or domain-uuid}
You can control the behavior of the rebooting guest by modifying the on_shutdown parameter in the guest's configuration file.
Reiniciar un huésped
Reiniciar un huésped mediante el comando virsh:
#virsh reboot {domain-id, domain-name or domain-uuid}
You can control the behavior of the rebooting guest by modifying the on_reboot element in the guest's configuration file.
Forzar al huésped a detenerse
Obliga a un huésped a detenerse con el comando virsh:
# virsh destroy {domain-id, domain-name or domain-uuid}
This command does an immediate ungraceful shutdown and stops the specified guest. Using virsh destroy can corrupt guest file systems . Use the destroy option only when the guest is unresponsive. For para-virtualized guests, use the shutdown option(Apagar un huésped) instead.
Obtener el ID de dominio de un huésped
Para obtener el ID de dominio de un huésped:
# virsh domid {domain-name or domain-uuid}
Obtener el nombre de dominio de un huésped
Para obtener el nombre de dominio de un huésped:
# virsh domname {domain-id or domain-uuid}
Obtener el UUID para un huésped
Para obtener el Identificador único universal (UUID) para un huésped:
# virsh domuuid {domain-id or domain-name}
Un ejemplo de la salida de virsh domuuid:
# virsh domuuid r5b2-mySQL01
4a4c59a7-ee3f-c781-96e4-288f2862f011
Mostrar la información de huésped
Using virsh with the guest's domain ID, domain name or UUID you can display information on the specified guest:
# virsh dominfo {domain-id, domain-name or domain-uuid}
Este es un ejemplo de salida de virsh dominfo:
# virsh dominfo r5b2-mySQL01
id:             13
name:           r5b2-mysql01
uuid:           4a4c59a7-ee3f-c781-96e4-288f2862f011
os type:      	linux
state:          blocked
cpu(s):         1
cpu time:     	11.0s
max memory:     512000 kb
used memory:    512000 kb
Mostrar información del host
Para ver información sobre el huésped:
# virsh nodeinfo
Un ejemplo de salida de virsh nodeinfo:
# virsh nodeinfo
CPU model                    x86_64
CPU (s)                      8
CPU frequency                2895 Mhz
CPU socket(s)                2      
Core(s) per socket           2
Threads per core:            2
Numa cell(s)                 1
Memory size:                 1046528 kb
Muestra la información del nodo y de la máquina que soporta el proceso de virtualización.
Mostrar los huéspedes
Para ver la lista de huéspedes y su estado actual con virsh:
# virsh list
Otras opciones incluyen:
La opción --inactive para listar los huéspedes inactivos (es decir, los huéspedes que han sido definidos pero que no están activos) y
La opción --all lista todos los huéspedes. Por ejemplo:
# virsh list --all
 Id Name                 State
----------------------------------
  0 Domain-0             running
  1 Domain202            paused
  2 Domain010            inactive
  3 Domain9600           crashed
La salida desde virsh list se categoriza como uno de los seis estados (listados abajo).
  • El estado running se refiere a los huéspedes que están actualmente activos en una CPU.
  • Los huéspedes listados como blocked están bloqueados y no se están ejecutando o no son ejecutables. Esto es causado por un huésped esperando en E/S (un estado de espera tradicional) o huéspedes en modo durmiente.
  • El estado paused lista los dominios que están en pausa. Esto se presenta si un administrador utiliza el botón pause en virt-manager, xm pause o virsh suspend. Cuando un huésped es puesto en pausa, consume memoria y otros recursos, pero no tiene derecho a programación ni recursos de CPU desde el hipervisor.
  • El estado shutdown es para huéspedes en el proceso de apagado. El huésped recibe una señal de apagado y debe estar en el proceso de detener las operaciones correctamente. Esto puede que no funcione para todos los sistemas operativos, algunos sistemas operativos no responden a estas señales.
  • Los dominios en el estado dying están en el proceso de muerte, el cual es el estado en el que el dominio no se ha bloqueado o apagado totalmente.
  • Los huéspedes de crashed han fallado en la ejecución y ya no funcionan. Este estado sólo puede ocurrir si el huésped ha sido configurado para no reiniciarse en bloqueo.
Mostrar información de la CPU virtual
Para ver la información de la CPU virtual desde un huésped con virsh:
# virsh vcpuinfo {domain-id, domain-name or domain-uuid}
Un ejemplo de salida de virsh vcpuinfo:
# virsh vcpuinfo r5b2-mySQL01
VCPU:           0
CPU:            0
State:          blocked
CPU time:       0.0s
CPU Affinity:   yy
Configurar la afinidad de la CPU virtual
Para configurar la afinidad de la CPU virtual con las CPU físicas:
# virsh vcpupin domain-id vcpu cpulist
The domain-id parameter is the guest's ID number or name.
El parámetro vcpu denota el número de CPU virtualizadas asignadas al huésped. El parámetro vcpu se debe proporcionar.
El parámetro cpulist es una lista de los números identificadores de CPU físicas separados por comas. El parámetro cpulist determina en cuáles CPU físicas y CPU virtuales se pueden ejecutar.
Configurar la cuenta de CPU virtual
Para modificar el número de CPU asignadas a un huésped con virsh:
# virsh setvcpus {domain-name, domain-id or domain-uuid} count
El nuevo valor count no puede exceder la cuenta de la cantidad que se especificó durante la creación del huésped.
Configurar la asignación de memoria
To modify a guest's memory allocation with virsh :
# virsh setmem {domain-id or domain-name} count
Debe especificar la cuenta en KB. El nuevo valor de cuenta no puede exceder la cantidad especificada durante la creación del huésped. Los valores por debajo de 64 MB probablemente no funcionarán en la mayoría de los sistemas operativos de huésped. Un valor superior de memoria máxima no afectará los huéspedes activos. Si el nuevo valor es inferior a la memoria disponible, la memoria disponible se disminuirá y el huésped puede fallar.
Mostrar información de dispositivo de bloque de huésped
Utilice virsh domblkstat para ver las estadísticas del dispositivo de bloque para un huésped en ejecución.
# virsh domblkstat GuestName block-device
Mostrar información del dispositivo de red de huésped
Use virsh domifstat para ver las estadísticas de interfaz de red para un huésped en ejecución.
# virsh domifstat GuestName interface-device 
Migrar huéspedes con virsh
Un huésped puede ser migrado a otro host con virsh. Para migrar el dominio a otro host, añada --live para migración en vivo. El comando migrate acepta parámetros en el siguiente formato:
# virsh migrate --live GuestName DestinationURL
El parámetro --live es opcional. Añada el parámetro --live para migraciones en vivo.
El GuestName parámetro representa el nombre del huésped que se desea migrar.
El parámetro DestinationURL es la URL o nombre de host del sistema de destino. El sistema de destino requiere:
  • la misma versión de Red Hat Enterprise Linux,
  • el mismo hipervisor (KVM o Xen) y
  • el servicio libvirt debe ser iniciado.
Una vez haya ingresado el comando se le solicitará la contraseña de root del sistema de destino.
Administrar redes virtuales
Esta sección cubre el manejo de redes virtuales con el comando virsh. Para listar las redes virtuales:
# virsh net-list
Este comando genera salida similar a:
# virsh net-list
Name                 State      Autostart
-----------------------------------------
default              active     yes      
vnet1	             active     yes      
vnet2	             active     yes
Para ver la información de una red virtual específica utilice:
# virsh net-dumpxml NetworkName
Muestra la información sobre la red virtual especificada en formato XML:
# virsh net-dumpxml vnet1
<network>
  <name>vnet1</name>
  <uuid>98361b46-1581-acb7-1643-85a412626e70</uuid>
  <forward dev='eth0'/>
  <bridge name='vnet0' stp='on' forwardDelay='0' />
  <ip address='192.168.100.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.100.128' end='192.168.100.254' />
    </dhcp>
  </ip>
</network>
Otros comandos de virsh para administrar redes virtuales son:
  • virsh net-autostart network-name — Autoinicia una red especificada como nombre_ de_ red.
  • virsh net-create XMLfile — genera e inicia una nueva red mediante un archivo XML existente.
  • virsh net-define XMLfile — genera un nuevo dispositivo de red desde un archivo XML existente sin iniciarlo.
  • virsh net-destroy [network-name] — destruye la red especificada en [nombre de red]
  • virsh net-name networkUUID — convierte un UUID_de_red determinado a un nombre de red.
  • virsh net-uuid network-name — convierte un nombre_ de_ red determinado a un UUID de red.
  • virsh net-start nameOfInactiveNetwork — inicia una red inactiva.
  • virsh net-undefine nameOfInactiveNetwork — elimina la definición de una red inactiva.

Capítulo 26. Manejo de huéspedes con un Administrador de máquinas virtuales (virt-manager)

Esta sección describe las ventanas del Administrador de máquinas virtuales (virt-manager), cuadros de diálogos y varios controles de GUI.
El virt-manager proporciona una vista gráfica de hipervisores y huéspedes en su sistema y máquinas remotas. El virt-manager sirve para definir tanto los huéspedes para-virtualizados como los completamente virtualizados. El virt-manager puede realizar tareas de administración de virtualización, incluyendo:
  • asignación de memoria,
  • asignación de CPU virtuales,
  • monitorización de rendimiento operacional,
  • ahorro y restauración, pausa y reanudación y apagado e inicialización de huéspedes virtualizados,
  • enlaces a consolas de gráficas y textuales, y
  • migraciones en vivo y desconectadas.

26.1. The Add Connection window

Esta ventana aparece primero y le pide al usuario escoger una sesión de hipervisor. Los usuarios sin privilegios pueden iniciar una sesión de sólo escritura. Los usuarios de root pueden iniciar una sesión con un estado completo de lectura-escritura. Para uso normal, seleccione la opción host local Xen o QEMU (para KVM).
Ventana de conexión del Administrador de máquinas virtuales
Figura 26.1. Ventana de conexión del Administrador de máquinas virtuales

26.2. La ventana principal del Administrador de máquinas virtuales

This main window displays all the running guests and resources used by guests. Select a virtualized guest by double clicking the guest's name.
Ventana principal del Administrador de máquinas virtuales
Figura 26.2. Ventana principal del Administrador de máquinas virtuales

26.3. The guest Overview tab

The Overview tab displays graphs and statistics of a guest's live resource utilization data available from virt-manager. The UUID field displays the globally unique identifier for the virtual machines.
The Overview tab
Figura 26.3. The Overview tab

26.4. Consola gráfica de la Máquina virtual

This window displays a virtual machine's graphical console. Para-virtualized and fully virtualized guests use different techniques to export their local virtual framebuffers, but both technologies use VNC to make them available to the Virtual Machine Manager's console window. If your virtual machine is set to require authentication, the Virtual Machine Graphical console prompts you for a password before the display appears.
Ventana de la consola gráfica
Figura 26.4. Ventana de la consola gráfica

Una observación sobre seguridad y VNC

VNC is considered insecure by many security experts, however, several changes have been made to enable the secure usage of VNC for virtualization on Red Hat enterprise Linux. The guest machines only listen to the local host (dom0)'s loopback address (127.0.0.1). This ensures only those with shell privileges on the host can access virt-manager and the virtual machine through VNC.
Remote administration can be performed following the instructions in Capítulo 22, Administración remota de huéspedes virtualizados. TLS can provide enterprise level security for managing guest and host systems.
Your local desktop can intercept key combinations (for example, Ctrl+Alt+F11) to prevent them from being sent to the guest machine. You can use the virt-manager sticky key capability to send these sequences. To use this capability, you must press any modifier key (Ctrl or Alt) 3 times and the key you specify gets treated as active until the next non-modifier key is pressed. You can then send Ctrl-Alt-F11 to the guest by entering the key sequence 'Ctrl Ctrl Ctrl Alt+F1'.

Nota

Due to a limitation of virt-manager, it is not possible to use this sticky key feature to send a Sysrq key combination to a guest.

26.5. Inicio de virt-manager

Para iniciar una sesión del virt-manager abra el menú de Aplicaciones; luego Herramientas del sistema y seleccione Administrador de máquina virtual (virt-manager).
La ventana principal de virt-manager aparece.
Inicio de virt-manager
Figura 26.5. Inicio de virt-manager

Alternatively, virt-manager can be started remotely using ssh as demonstrated in the following command:
ssh -X host's address[remotehost]# virt-manager
Using ssh to manage virtual machines and hosts is discussed further in Sección 22.1, “Administración remota con SSH”.

26.6. Restaurar una máquina guardada

Una vez iniciado el Administrador de máquinas virtuales, todas las máquinas virtuales en su sistema aparecerán en la ventana principal. Domain0 es su sistema de host. Si no hay máquinas presentes, significa que actualmente no hay máquinas ejecutándose en el sistema.
Para restaurar una sesión guardada anteriormente:
  1. Desde el menú Archivo, seleccione Restaurar máquina guardada.
    Restauración de una máquina virtual
    Figura 26.6. Restauración de una máquina virtual

  2. La ventana principal de Restaurar máquina virtual aparece.
  3. Vaya al directorio correcto y seleccione el archivo de sesión guardado.
  4. Haga clic en Abrir.
El sistema virtual guardado aparecerá en la ventana principal del administrador de máquinas virtuales.
La sesión restaurada del administrador de máquinas virtuales
Figura 26.7. La sesión restaurada del administrador de máquinas virtuales

26.7. Mostrar información de huéspedes

Puede usar el Monitor de máquinas virtuales para ver información de la actividad de cualquier máquina virtual en su sistema.
To view a virtual system's details:
  1. En la ventana principal del Administrador de máquinas virtuales, resalte la máquina virtual que desea ver.
    Para seleccionar la máquina virtual
    Figura 26.8. Para seleccionar la máquina virtual

  2. From the Virtual Machine Manager Edit menu, select Machine Details (or click the Details button on the bottom of the Virtual Machine Manager main window).
    Displaying the overview window
    Figura 26.9. Displaying the overview window

    On the Virtual Machine window, click the Overview tab.
    The Overview tab summarizes CPU and memory usage for the virtualized guest you specified.
    Mostrar información general de huésped
    Figura 26.10. Mostrar información general de huésped

  3. On the Virtual Machine window, click the Hardwaretab.
    Muestra de detalles de hardware del huésped
    Figura 26.11. Muestra de detalles de hardware del huésped

  4. En la pestaña Hardware, haga clic en Procesador para ver o cambiar la asignación de memoria del procesador actual.
    Panel de asignación del procesador
    Figura 26.12. Panel de asignación del procesador

  5. En la pestaña Hardware, haga clic en Memoria para ver o modificar la asignación de memoria RAM actual.
    Mostrar asignación de memoria
    Figura 26.13. Mostrar asignación de memoria

  6. En la pestaña Hardware, haga clic en Disco para ver o cambiar la configuración actual del disco duro.
    Mostrar configuración del disco
    Figura 26.14. Mostrar configuración del disco

  7. On the Hardware tab, click on NIC to view or change the current network configuration.
    Mostrar configuración de red
    Figura 26.15. Mostrar configuración de red

26.8. Estado de monitorización

Status status monitoring preferences can be modified with virt-manager's preferences window.
To configure status monitoring:
  1. Desde el menú Editar, seleccione Preferencias.
    Modificar las preferencias del huésped
    Figura 26.16. Modificar las preferencias del huésped

    The Preferences window appears.
  2. From the Stats tab specify the time in seconds or stats polling options.
    Configurar estado de monitorización
    Figura 26.17. Configurar estado de monitorización

26.9. Mostrar los identificadores de huésped

Para ver todos los ID de huésped de todas las máquinas virtuales en su sistema:
  1. Desde el menú Ver, seleccione la casilla de verificación ID del dominio.
    Ver ID de huéspedes
    Figura 26.18. Ver ID de huéspedes

  2. El Administrador de máquinas virtuales lista todos los ID de dominio para todos los dominios en su sistema.
    Mostrar las ID de dominio
    Figura 26.19. Mostrar las ID de dominio

26.10. Displaying a guest's status

Para ver el estado de todas las máquinas virtuales en su sistema:
  1. Desde el menú Ver, seleccione la casilla de verificación Estado.
    Selecting a virtual machine's status
    Figura 26.20. Selecting a virtual machine's status

  2. El administrador de máquinas virtuales lista el estado de todas las máquinas virtuales en su sistema.
    Displaying a virtual machine's status
    Figura 26.21. Displaying a virtual machine's status

26.11. Mostrar las CPU virtuales

Para ver la cantidad de CPU virtuales para todas las máquinas virtuales en su sistema:
  1. Desde el menú Ver, seleccione la casilla de verificación CPU Virtuales.
    Si selecciona la opción de CPU virtuales
    Figura 26.22. Si selecciona la opción de CPU virtuales

  2. El administrador de máquinas virtuales lista las CPU virtuales para todas las máquinas virtuales en su sistema.
    Mostrar CPU virtuales
    Figura 26.23. Mostrar CPU virtuales

26.12. Mostrar uso de la CPU

Para ver el uso de la CPU para todas las máquinas virtuales en su sistema:
  1. Desde el menú Ver seleccione Uso de CPU
    Si selecciona el rango DHCP
    Figura 26.24. Si selecciona el rango DHCP

  2. El Administrador de máquinas virtuales lista el porcentaje de CPU en uso para todas las máquinas virtuales en su sistema.
    Mostrar uso de la CPU
    Figura 26.25. Mostrar uso de la CPU

26.13. Mostrar uso de memoria

Para ver el uso de memoria para todas las máquinas virtuales de su sistema:
  1. Desde la pestaña Ver, seleccione la casilla de verificación Uso de memoria.
    Si selecciona uso de memoria
    Figura 26.26. Si selecciona uso de memoria

  2. El Administrador de máquinas virtuales lista el porcentaje de memoria en uso (en megabytes) para todas las máquinas virtuales en su sistema.
    Mostrar uso de memoria
    Figura 26.27. Mostrar uso de memoria

26.14. Administración de una red virtual

Para configurar una red virtual en su sistema:
  1. Desde el menú Editar, seleccione Detalles del host.
    Selecting a host's details
    Figura 26.28. Selecting a host's details

  2. Se abrirá el menú Detalles del host. Haga clic en la pestaña Redes virtuales.
    Configuración de la red virtual
    Figura 26.29. Configuración de la red virtual

  3. Todas las redes virtuales disponibles se listan en la casilla de la izquierda del menú. Puede editar la configuración de una red virtual seleccionándola en esta casilla y editándola.

26.15. Crear una nueva red virtual

Para crear una red virtual en su sistema:
  1. Open the Host Details menu (refer to Sección 26.14, “Administración de una red virtual ”) and click the Add button.
    Configuración de la red virtual
    Figura 26.30. Configuración de la red virtual

    Se abrirá el menú Crear una nueva red virtual. Haga clic en Adelante para continuar.
    Crear una nueva red virtual
    Figura 26.31. Crear una nueva red virtual

  2. Introduzca un nombre apropiado para su red virtual y haga clic en Adelante.
    Dando un nombre a la red virtual
    Figura 26.32. Dando un nombre a la red virtual

  3. Introduzca un espacio de dirección IPv4 para su red virtual y haga clic en Adelante.
    Selección de un espacio de dirección IPv4
    Figura 26.33. Selección de un espacio de dirección IPv4

  4. Defina el rango DHCP para su red virtual especificando un rango de Comienzo y Fin de direcciones IP. Haga clic en Adelante para continuar.
    Si selecciona el rango DHCP
    Figura 26.34. Si selecciona el rango DHCP

  5. Seleccione cómo la red virtual se debe conectar con la red física.
    Conexión a la red física
    Figura 26.35. Conexión a la red física

    Si selecciona Reenvío a la red física, seleccione si el Destino debe ser NAT a un dispositivo físico o NAT al dispositivo físico eth0.
    Haga clic en Adelante para continuar.
  6. Ahora está listo para crear la red. Revise la configuración de su red y haga clic en Finalizar.
    Listo para crear la red
    Figura 26.36. Listo para crear la red

  7. La nueva red virtual está ya disponible en la pestaña Red Virtual del menú Detalles del host.
    La nueva red virtual ya está disponible
    Figura 26.37. La nueva red virtual ya está disponible

Capítulo 27. El comando xm de referencia rápida

El comando xm puede administrar el hipervisor Xen. La mayoría de las operaciones pueden realizarse con las herramientas libvirt, la aplicación virt-manager o el comando virsh. El comando xm no tiene capacidad de comprobación de errores de las herramientas libvirt y no debe ser utilizado para soporte de tareas de libvirt.
Hay algunas pocas operaciones que no pueden ser realizadas en la actualidad con virt-manager. Algunas opciones para otras implementaciones de Xen del comando xm no funcionan en Red Hat Enterprise Linux 5. La lista a continuación proporciona una visión general de opciones de comandos disponibles y no disponibles.

Advertencia

Se recomienda el uso de virsh o de virt-manager en lugar de xm. El comando xm no maneja comprobación de errores muy bien y puede conducir a inestabilidad del sistema o errores en máquinas virtuales. La edición manual de los archivos de configuración Xen es peligrosa y debe evitarse. Utilice este capítulo a su propio riesgo.
Opciones de administración básicas
Los comandos básicos y más utilizados en xm son los siguientes:
  • xm help [--long]: muestra las opciones disponibles y el texto de ayuda.
  • el comando xm list se utiliza para listar dominios activos:
    $ xm list
    Name                                ID  Mem(MiB)   VCPUs      State      Time(s)
    Domain-0                            0     520       2         r-----     1275.5
    r5b2-mySQL01                       13     500       1         -b----       16.1
    
  • xm create [-c] DomainName/ID: start a virtual machine. If the -c option is used, the start up process will attach to the guest's console.
  • xm console DomainName/ID: attach to a virtual machine's console.
  • xm destroy ID/NombreDominio: termina una máquina virtual, similar a un apagado.
  • xm reboot Nombre_de_dominio/ID: reinicia una máquina virtual, se ejecuta a través del proceso normal de apague e inicio.
  • xm shutdown Nombre_de_dominio/ID: apaga una máquina virtual, ejecuta un procedimiento de apagado normal.
  • xm pause
  • xm unpause
  • xm save
  • xm restore
  • xm migrate
Opciones de administración de recursos
Los siguientes comandos de xm se utilizan para administrar recursos:
  • xm mem-set
  • utilice xm vcpu-list para listar las afinidades de CPU virtualizada:
    $ xm vcpu-list
    Name                          ID  VCPUs   CPU State  Time(s)  CPU Affinity
    Domain-0                       0    0      0    r--   708.9    any cpu
    Domain-0                       0    1      1   -b-    572.1    any cpu
    r5b2-mySQL01                  13    0      1   -b-     16.1    any cpu
    
  • xm vcpu-pin
  • xm vcpu-set
  • Utilice el comando xm sched-credit para mostrar los parametros del programador de un dominio determinado:
    $ xm sched-credit -d 0
    {'cap': 0, 'weight': 256}
    $ xm sched-credit -d 13
    {'cap': 25, 'weight': 256}
    
Opciones de monitorización y solución de problemas
Los siguientes comandos de xm se utilizan para la monitorización y solución de errores:
  • xm top
  • xm dmesg
  • xm info
  • xm log
  • El comando xm uptime se utiliza para mostrar el tiempo de vida de los huéspedes y hosts:
    $ xm uptime
    Name                       ID  Uptime
    Domain-0                    0  3:42:18
    r5b2-mySQL01               13  0:06:27
    
  • xm sysrq
  • xm dump-core
  • xm rename
  • xm domid
  • xm domname
Opciones no soportadas en la actualidad
xm vnet-list no está soportado actualmente.

Capítulo 28. Configuración de parámetros de arranque de Xen

El gestor de arranque unificado GNU, GRUB, es un programa para el arranque de diversos sistemas operativos que están ejecutando sistemas o kernels. GRUB también permite al usuario pasar argumentos al kernel. El archivo de configuración de GRUB (que se encuentra en /boot/grub/grub.conf), crea la lista de sistemas operativos de la interfaz del menú de arranque GRUB. Al instalar un RPM de kernel-xen un script añade la entrada kernel-xen al archivo de configuración de GRUB que arranca el kernel-xen predeterminado. Edite el archivo grub.conf para modificar el kernel predeterminado o agregar parámetros de kernel adicionales.
title Red Hat Enterprise Linux Server (2.6.18-3.el5xen)
root (hd0,0)
	kernel  /xen.gz.-2.6.18-3.el5
	module  /vmlinuz-2.6..18-3.el5xen ro root=/dev/VolGroup00/LogVol00  rhgb quiet
	module  /initrd-2.6.18-3. el5xenxen.img
Si se configuran las entradas de GRUB de Linux para que se asemejen a este ejemplo, el gestor de arranque carga el hipervisor, la imagen initrd y el kernel de Linux. Como la entrada del kernel está sobre las otras entradas, éste se carga en memoria primero. El gestor de arranque envía y recibe argumentos de la línea de comandos al hipervisor y al kernel de Linux. Esta entrada de ejemplo muestra cómo se puede restringir la memoria del kernel de Linux Dom0 a 800 MB.
title Red Hat Enterprise Linux Server (2.6.18-3.el5xen)
root (hd0,0)
	kernel  /xen.gz.-2.6.18-3.el5 dom0_mem=800M
	module  /vmlinuz-2.6..18-3.el5xen ro root=/dev/VolGroup00/LogVol00  rhgb quiet
	module  /initrd-2.6.18-3. el5xenxen.img
Usted puede utilizar estos parámetros de GRUB para configurar el hipervisor de virtualización:
mem
De esta manera se limita la cantidad de memoria que está disponible para el kernel del hipervisor.
com1=115200, 8n1
Esto permite que el primer puerto serial en el sistema actúe como una consola serial (com2 es asignada al siguiente puerto y así sucesivamente).
dom0_mem
Esto limita la memoria disponible para el hipervisor.
dom0_max_vcpus
Este parámetro limita la cantidad de CPU visible para el Xen domain0.
acpi
Este parámetro intercambia el hipervisor ACPI al hipervisor y domain0. Las opciones del parámetro ACPI incluyen:
/*   ****  Linux config options: propagated to domain0  ****/
/*   "acpi=off":      Disables both ACPI table parsing and interpreter.   */
/*   "acpi=force":    Overrides the disable blacklist.                    */
/*   "acpi=strict":   Disables out-of-spec workarounds.                   */
/*   "acpi=ht":       Limits ACPI from boot-time to enable HT.            */
/*   "acpi=noirq":    Disables ACPI interrupt routing.                    */
noacpi
Este parámetro desactiva APIC para el envío de interrupciones.

Capítulo 29. Configuración de ELILO

ELILO es un gestor de arranque utilizado en sistemas de EFI, en particular Itanium®. Similar al gestor de arranque de GRUB, el gestor de arranque ELILO en sistemas x86 y x86-64, permite al usuario seleccionar el kernel instalado para cargar en la secuencia de arranque del sistema. ELILO también permite al usuario pasar argumentos al kernel. El archivo de configuración ELILO, el cual está localizado en la partición de arranque de la EFI y conectado simbólicamente a /etc/elilo.conf, contiene una lista de opciones globales y estanzas de imagen. Al instalar el RPM de kernel-xen, un post script de instalación añade la estanza de imagen apropiada a elilo.conf.

ELILO

Esta sección sobre ELILO es para los sistemas que se ejecutan en el kernel Xen en la arquitectura de Intel- Itanium.
El archivo de configuración ELILO consta de dos secciones:
  • Las opciones globales que afectan la conducta de ELILO y todas las entradas. Por lo general, no es necesario cambiar estos valores predeterminados.
  • Estanzas de imagen que definen una selección de arranque junto con las opciones asociadas.
Here is a sample image stanza in elilo.conf:
image=vmlinuz-2.6.18-92.el5xen
        vmm=xen.gz-2.6.18-92.el5
        label=linux
        initrd=initrd-2.6.18-92.el5xen.img
        read-only
        root=/dev/VolGroup00/rhel5_2
        append="-- rhgb quiet"
The image parameter indicates the following lines apply to a single boot selection. This stanza defines a hypervisor (vmm), initrd, and command line arguments (read-only, root and append) to the hypervisor and kernel. When ELILO is loaded during the boot sequence, the image is labeled linux.
ELILO traduce read-only a la opción de línea de comandos del kernel ro la cual hace que el sistema de archivos de root sea montado de sólo lectura hasta que initscripts monte el controlador de root como de lectura-escritura. ELILO copia la línea "root" a la línea de comandos del kernel. Estos se fusionan con la línea append" para crear un línea de comandos completa:
"-- root=/dev/VolGroup00/rhel5_2 ro rhgb quiet"
Los símbolos -- delimitan los argumentos del hipervisor y del kernel. Los argumentos del hipervisor van primero, luego el delimitador --, seguido de los argumentos del kernel. El hipervisor no suele tener argumentos.

Nota técnica

ELILO pasa la línea de comandos entera al hipervisor. El hipervisor divide el contenido y pasa las opciones de kernel al kernel.
Para personalizar el hipervisor, inserte los parámetros antes de --. A continuación, un ejemplo del parámetro de la memoria de hipervisor (mem) y del parámetro quiet para el kernel:
append="dom0_mem=2G -- quiet"
Parámetros de hipervisor ELILO
ParámetroDescripción
mem=El parámetro mem define el uso máximo de RAM del hipervisor. Cualquier RAM adicional en el sistema se omite. El parámetro se puede especificar con el sufijo B, K, M o G; representando bytes, kilobytes, megabytes y gigabytes respectivamente. Si no se especifica ningún sufijo la unidad predeterminada es kilobytes.
dom0_mem=dom0_mem= establece la cantidad de RAM asignada a dom0. Los mismos sufijos se mantienen como los del parámetro anterior. El predeterminado en Red Hat Enterprise Linux 5.2 en Itanium® es 4G.
dom0_max_vcpus=dom0_max_vcpus= establece el número de CPU a asignar para el hipervisor. El predeterminado en Red Hat Enterprise Linux 5.2 en Itanium® es 4.
com1=<baud>,DPS,<io_base>,<irq>El parámetro com1= establece los parámetros para la primera línea serial. Por ejemplo, com1=9600,8n1,0x408,5. Las opciones io_base y irq se pueden omitir para dejarlas como las predeterminadas. El parámetro baud se puede establecer como auto para indicar que la configuración del gestor de arranque se debe preservar. El parámetro com1 puede ser omitido si los parámetros están configurados como opciones globales en ELILO o en la configuración de EFI.
com2=<baud>,DPS,<io_base>,<irq>Establece los parámetros para la segunda línea serial. Consulte la descripción del parámetro com1 arriba.
console=<specifier_list>El parámetro de console es una lista de preferencias delimitada por comas para las opciones de consola. Las opciones incluyen vga, com1 y com2. Esta configuración debe omitirse porque el hipervisor tiende a heredar la configuración de consola de la EFI.

Para mayor información sobre parámetros de ELILO

Una lista completa de parámetros ELILO está disponible desde XenSource.
Un ejemplo modificado de la configuración de arriba, mostrando la sintaxis para añadir memoria y asignar parámetros de CPU al hipervisor:
image=vmlinuz-2.6.18-92.el5xen
        vmm=xen.gz-2.6.18-92.el5
        label=linux
        initrd=initrd-2.6.18-92.el5xen.img
        read-only
        root=/dev/VolGroup00/rhel5_2
        append="dom0_mem=2G dom0_max_vcpus=2 --"
Adicionalmente este ejemplo elimina los parámetros del kernel "rhgb quiet" para que el kernel y la salida de initscript se generen en la consola. Observe que el doble guión permanece para que la línea que se añade se interprete correctamente como argumentos de hipervisor.

Capítulo 30. libvirt configuration reference

This chapter provides is a references for various parameters of libvirt XML configuration files
Tabla 30.1. libvirt configuration files
Item Description
pae
Specifies the physical address extension configuration data.
apic
Specifies the advanced programmable interrupt controller configuration data.
memory
Specifies the memory size in megabytes.
vcpus
Specifies the numbers of virtual CPUs.
console
Specifies the port numbers to export the domain consoles to.
nic
Specifies the number of virtual network interfaces.
vif
Lists the randomly-assigned MAC addresses and bridges assigned to use for the domain's network addresses.
disk
Lists the block devices to export to the domain and exports physical devices to domain with read only access.
dhcp
Enables networking using DHCP.
netmask
Specifies the configured IP netmasks.
gateway
Specifies the configured IP gateways.
acpi
Specifies the advanced configuration power interface configuration data.

Capítulo 31. Archivos de configuración Xen

Red Hat Enterprise Linux uses libvirt configuration files for most tasks. Some users may need Xen configuration files which contain the following standard variables. Configuration items within these files must be enclosed in single quotes('). These configuration files reside in the /etc/xen directory.
The table below, Tabla 31.1, “Archivos de configuración de referencia Xen”, is formatted output from xm create --help_config.
Tabla 31.1. Archivos de configuración de referencia Xen
Parameter
Description
vncpasswd=NOMBRE Contraseña para consola de VNC en dominio HVM
vncviewer=no | yes Genera una escucha de vncviewer para un servidor VNC en el dominio. La dirección de vncviewer se pasa a la línea de comandos de kernel mediante VNC_SERVER=<host>:<port>. El puerto utilizado por VNC es 5500 + DISPLAY. Si es posible, se elige un valor de pantalla con un puerto libre. Sólo cuando VNC=1.
vncconsole=no | yes Spawn a vncviewer process for the domain's graphical console. Only valid when vnc=1.
name=NOMBRE Nombre de dominio. Debe ser único.
bootloader=ARCHIVO Ruta para el gestor de arranque.
bootargs=NOMBRE Argumentos para pasar al gestor de arranque.
bootentry=NOMBRE DEPRECIADO. Entrada para arrancar a través del gestor de arranque. Utilice bootargs.
kernel=ARCHIVO Ruta de imagen de kernel.
ramdisk=ARCHIVO Ruta para ramdisk.
features=FUNCIONES Funciones para habilitar en el kernel de huésped
builder=FUNCIÓN Función para utilizar en la creación del dominio
memory=MEMORIA Memoria de dominio en MB.
maxmem=MEMORIA Memoria de dominio máximo en MB.
shadow_memory=MEMORIA Dominio de memoria oculta en MB
cpu=CPU CPU de hosts VCPU0.
cpus=CPU Las CPU a ejecutar en dominio.
pae=PAE Activar o desactivar PAE del dominio HVM.
acpi=ACPI Activar o desactivar ACPI del dominio HVM.
apic=APIC Activar o desactivar APIC del dominio HVM.
vcpus=VCPU El número de CPU virtuales en dominio.
cpu_weight=PESO Set the new domain's cpu weight. WEIGHT is a float that controls the domain's share of the cpu.
restart=en_reinicio | siempre | nunca Depreciado. Utiliza on_poweroff, on_reboot, y on_crash en su lugar. Si el dominio debe ser reiniciado al salir. - onreboot: reinicia en la salida con reinicio del código de apagado - siempre: siempre reinicie a la salida, ignore el código de salida - nunca: nunca reinicie a la salida, ignore el código de salida
on_poweroff=destruir |reiniciar| preservar |destruir Behavior when a domain exits with reason 'poweroff'. - destroy: the domain is cleaned up as normal; - restart: a new domain is started in place of the old one; - preserve: no clean-up is done until the domain is manually destroyed (using xm destroy, for example); - rename-restart: the old domain is not cleaned up, but is renamed and a new domain started in its place.
on_reboot=destruir |reiniciar|preservar|destruir Behavior when a domain exits with reason 'reboot'. - destroy: the domain is cleaned up as normal; - restart: a new domain is started in place of the old one; - preserve: no clean-up is done until the domain is manually destroyed (using xm destroy, for example); - rename-restart: the old domain is not cleaned up, but is renamed and a new domain started in its place.
on_crash=destroy | reiniciar | preservar | destruir Behavior when a domain exits with reason 'crash'. - destroy: the domain is cleaned up as normal; - restart: a new domain is started in place of the old one; - preserve: no clean-up is done until the domain is manually destroyed (using xm destroy, for example); - rename-restart: the old domain is not cleaned up, but is renamed and a new domain started in its place.
blkif=no | yes Crea el dominio de un backend de dispositivo de bloque.
netif=no | yes Crea el dominio de un backend de interfaz de red.
tpmif=no | yes Crea el dominio de un backend de interfaz TPM.
disk=phy:DEV,VDEV,MODE[,DOM] Añade un dispositivo de disco a un dominio. El dispositivo físico es DEV, el cual es exportado al dominio como VDEV. El disco es de sólo-lectura si MODE es r, lectura-escritura si MODE es w. Si DOM es especificado, éste define el dominio de controlador de backend para el disco. La opción puede repetirse para agregar más de un disco.
pci=BUS:DEV.FUNC Añade un dispositivo de PCI a un dominio utilizando los parámetros dados (en hex). Por ejemplo pci=c0:02.1a. La opción puede repetirse para añadir más de un dispositivo PCI.
ioports=FROM[-TO] Añade un rango de E/S a un dominio, mediante los parametros dados (en hex). Por ejemplo, ioports=02f8-02ff. La opción puede repetirse para agregar más de un rango de E/S.
irq=IRQ Añadir una IRQ (solicitud de interrupción) a un dominio. Por ejemplo irq=7. Esta opción puede repetirse para añadir más de una IRQ.
usbport=RUTA Añadir un puerto USB físico a un dominio, como es especificado por la ruta a un puerto. Esta opción puede repetirse para añadir más de un puerto.
vfb=type={vnc,sdl}, vncunused=1, vncdisplay=N,
vnclisten=ADDR, display=DISPLAY,
xauthority=XAUTHORITY, vncpasswd=PASSWORD,
keymap=MAPA_DE_TECLADO
Make the domain a framebuffer backend. The backend type should be either sdl or vnc. For type=vnc, connect an external vncviewer. The server will listen on ADDR (default 127.0.0.1) on port N+5900. N defaults to the domain id. If vncunused=1, the server will try to find an arbitrary unused port above 5900. For type=sdl, a viewer will be started automatically using the given DISPLAY and XAUTHORITY, which default to the current user's ones.
vif=type=TYPE, mac=MAC, bridge=BRIDGE, ip=IPADDR,
script=SCRIPT, backend=DOM, vifname=NAME
Añada una interfaz de red con la dirección y puente de MAC determinados. El vif se configura llamando al script de configuración determinado. Si no se especifica el tipo, el predeterminado será netfront y no el dispositivo ioemu. Si MAC no se especifica en forma aleatoria, se utiliza entonces la dirección MAC. Si no está especificada, entonces el backend de red elige su propia dirección MAC. Si el puente no está especificado, se utiliza entonces el primer puente que se encuentre. Si el script no está especificado, se utiliza entonces el script predeterminado. Si el backend no se especifica, se utiliza el dominio de controlador de backend predeterminado. Si vifname no está especificado, la interfaz virtual de backend tendrá el nombre vifD. N donde D es el dominio, ID y N es la ID de interfaz. Esta opción puede repetirse para añadir más de un vif. La especificación de vif aumentará el número de interfaces requeridas.
vtpm=instance=INSTANCIA,backend=DOM Añada una interfaz TPM. Al lado del backend utilice la instancia dada como instancia TPM virtual. El número determinado es sólo el número de instancia preferido. El script de hotplug determinará el número de la instancia asignada al dominio. La asociación entre máquina virtual y el número de instancia de TPM puede hallarse en /etc/xen/vtpm.db. Utilice el backend en el dominio dado.
access_control=policy=POLÍTICA,etiqueta=ETIQUETA Añada una etiqueta de seguridad y una referencia de política de seguridad que lo defina. La referencia de ssid local se calcula en el inicio o reanudación del dominio. En este momento, la política se verifica con la política activa también. Así, la migración a través de las funciones de guardado o restablecimiento se cubren y las etiquetas se crean de forma automática y correcta en el sistema en el que se inicie o reanude un dominio.
nics=NÚM DEPRECIADO. Utilice las entradas vif vacías en su lugar. Establezca el número de interfaces de red. Utilice la opción vif para definir los parámetros de interfaz, de lo contrario se utilizan los predeterminados. La especificación de vifs aumentará el número de interfaces cuando se requiera.
root=DISPOSITIVO Establece root= parameter en la línea de comandos del kernel. Utilice un dispositivo, e.g. /dev/sda1, o /dev/nfs para root de NFS.
extra=ARGUMENTOS Establece argumentos adicionales para añadir a la línea de comandos del kernel.
ip=DIRECCIÓN_IP Establece una dirección IP de interfaz de kernel.
gateway=DIRECCIÓN_IP Establece la puerta de enlace IP del kernel.
netmask=MÁSCARA Establece la máscara de red IP del kernel.
hostname=NOMBRE Establece el nombre de host IP del kernel
interface=INTF Establece el nombre de interfaz IP del kernel
dhcp=off|dhcp Establece la opción dhcp de kernel.
nfs_server=DIRECCIÓN_IP Establece la dirección del servidor NFS para root de NFS.
nfs_root=RUTA Establece la ruta del directorio NFS de root.
device_model=ARCHIVO Ruta al programa de modelo de dispositivo.
fda=ARCHIVO Ruta a fda
fdb=ARCHIVO Ruta a fdb
serial=ARCHIVO Ruta a serial, pty o vc
localtime=no | yes RTC establece el tiempo local
keymap=ARCHIVO Establece el tipo de teclado utilizado
usb=no | yes Emula dispositivos USB
usbdevice=NOMBRE Nombre de un dispositivo USB a añadir
stdvga=no | yes Use std vga or Cirrus Logic graphics
isa=no | yes Simula un único sistema ISA
boot=a|b|c|d Dispositivo de arranque predeterminado
nographic=no | yes ¿Deben los modelos de dispositivos utilizar gráficas?
soundhw=audiodev ¿Los modelos de dispositivo permiten dispositivo de audio?
vnc ¿El modelo de dispositivo usa VNC?
vncdisplay Pantalla VNC a utilizar
vnclisten Dirección para escuchar en servidor de VNC
vncunused Trata de encontrar un puerto sin utilizar para el servidor VNC. Sólo válido cuando vnc=1.
sdl ¿El modelo de dispositivo usa SDL?
display=PANTALLA pantalla X11 a utilizar
xauthority=XAUTHORITY Autoridad X11 a utilizar
uuid xenstore UUID (identificador único universal) a utilizar. Uno será generado de forma aleatoria si esta opción no está estableciad, justo como las direcciones de MAC para interfaces de redes virtuales. Éste debe ser un valor único en todo el grupo.

Tabla 31.3, “Valores predeterminados de configuración de parámetro” lists all configuration parameters available, the Python parser function which sets the value and default values. The setter function gives an idea of what the parser does with the values you specify. It reads these as Python values, then feeds them to a setter function to store them. If the value is not valid Python, you get an obscure error message. If the setter rejects your value, you should get a reasonable error message, except it appears to get lost somehow, along with your bogus setting. If the setter accepts, but the value is incorrect the application may fail.
Tabla 31.2. Funciones de Python que establecen los valores de parámetro
Función de análisis Argumentos válidos
set_bool
Valores aceptados:
  • yes
  • y
  • no
  • yes
set_float
Accepts a floating point number with Python's float(). For example:
  • 3.14
  • 10.
  • .001
  • 1e100
  • 3.14e-10
set_int
Accepts an integer with Python's int().
set_value
acepta cualquier valor de Python.
append_value
acepta cualquier valor de Python y lo añade a el valor anterior almacenado en una matriz.

Tabla 31.3. Valores predeterminados de configuración de parámetro
Parameter Función de análisis Valor predeterminado
name setter default value
vncpasswd set_value None
vncviewer set_bool None
vncconsole set_bool None
name set_value None
bootloader set_value None
bootargs set_value None
bootentry set_value None
kernel set_value None
ramdisk set_value ''
features set_value ''
builder set_value 'linux'
memory set_int 128
maxmem set_int None
shadow_memory set_int 0
cpu set_int None
cpus set_value None
pae set_int 0
acpi set_int 0
apic set_int 0
vcpus set_int 1
cpu_weight set_float None
restart set_value None
on_poweroff set_value None
on_reboot set_value None
on_crash set_value None
blkif set_bool 0
netif set_bool 0
tpmif append_value 0
disk append_value []
pci append_value []
ioports append_value []
irq append_value []
usbport append_value []
vfb append_value []
vif append_value []
vtpm append_value []
access_control append_value []
nics set_int -1
root set_value ''
extra set_value ''
ip set_value ''
gateway set_value ''
netmask set_value ''
hostname set_value ''
interface set_value "eth0"
dhcp set_value 'off'
nfs_server set_value None
nfs_root set_value None
device_model set_value ''
fda set_value ''
fdb set_value ''
serial set_value ''
localtime set_bool 0
keymap set_value ''
usb set_bool 0
usbdevice set_value ''
stdvga set_bool 0
isa set_bool 0
boot set_value 'c'
nographic set_bool 0
soundhw set_value ''
vnc set_value None
vncdisplay set_value None
vnclisten set_value None
vncunused set_bool 1
sdl set_value None
display set_value None
xauthority set_value None
uuid set_value None

Parte VII. Consejos y trucos

Capítulo 32. Consejos y trucos

Este capítulo contiene consejos y trucos útiles para mejorar el rendimiento de virtualización, escala y estabilidad.

32.1. Inicio automático de huéspedes

This section covers how to make virtualized guests start automatically during the host system's boot phase.
Este ejemplo utiliza virsh para configurar el huésped, TestServer, para que inicie automáticamente cuando el host arranque.
# virsh autostart TestServer
Domain TestServer marked as autostarted
El huésped se inicia ahora automáticamente con el host.
Si desea detener al huésped para que no se inicie automáticamente, use el parámetro --disable
# virsh autostart --disable TestServer
Domain TestServer unmarked as autostarted
El huésped ya no se inicia automáticamente con el host.

32.2. Cambio entre los hipervisores KVM y Xen

Esta sección cubre el cambio entre los hipervisores KVM y Xen.
Red Hat sólo admite un hipervisor activo a la vez.

Migración de huéspedes virtualizados entre hipervisores

Actualmente, no hay aplicación para cambiar de huéspedes basados en Xen a huéspedes basados en KVM o viceversa. Los huéspedes sólo pueden utilizarse en el tipo de hipervisor en el que fueron creados.

Advertencia

Este procedimiento sólo está disponible para la versión Intel 64 o AMD64 de Red Hat Enterprise Linux 5.4 o más recientes. Ninguna otra configuración o versiones de Red Hat Enterprise Linux están soportadas. KVM no está disponible en versiones anteriores a Red Hat Enterprise Linux 5.4.

32.2.1. De Xen a KVM

El siguiente procedimiento cubre el cambio de un hipervisor Xen a un hipervisor KVM. Este procedimiento supone que el paquete kernel-xen está instalado y habilitado.
  1. Instale el paquete KVM

    Instale el paquete kvm si aún no lo ha hecho.
    # yum install kvm
    
  2. Verifique cuál kernel está en uso

    El paquete kernel-xen puede ser instalado. Use el comando uname para determinar cuál kernel se está ejecutando:
    $ uname -r
    2.6.18-159.el5xen
    
    El kernel actual, "2.6.18-159.el5xen", está ejecutándose en el sistema. Si el kernel predeterminado, "2.6.18-159.el5" está ejecutándose, puede omitir este paso.
    1. Cambiando del kernel Xen al kernel predeterminado

      El archivo grub.conf determina el kernel de arranque. Para cambiar al kernel predeterminado, edite el archivo /boot/grub/grub.conf como se muestra a continuación.
      								default=1
      timeout=5
      splashimage=(hd0,0)/grub/splash.xpm.gz
      hiddenmenu
      title Red Hat Enterprise Linux Server (2.6.18-159.el5)
              root (hd0,0)
              kernel /vmlinuz-2.6.18-159.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
              initrd /initrd-2.6.18-159.el5.img
      title Red Hat Enterprise Linux Server (2.6.18-159.el5xen)
              root (hd0,0)
              kernel /xen.gz-2.6.18-159.el5
              module /vmlinuz-2.6.18-159.el5xen ro root=/dev/VolGroup00/LogVol00 rhgb quiet
              module /initrd-2.6.18-159.el5xen.img
      
      Observe el parámetro default=1. Éste le indica al gestor de arranque GRUB que inicie la segunda entrada, el kernel Xen. Cambie el valor predeterminado a 0 (o al número para el kernel predeterminado):
      								default=0
      timeout=5
      splashimage=(hd0,0)/grub/splash.xpm.gz
      hiddenmenu
      title Red Hat Enterprise Linux Server (2.6.18-159.el5)
              root (hd0,0)
              kernel /vmlinuz-2.6.18-159.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
              initrd /initrd-2.6.18-159.el5.img
      title Red Hat Enterprise Linux Server (2.6.18-159.el5xen)
              root (hd0,0)
              kernel /xen.gz-2.6.18-159.el5
              module /vmlinuz-2.6.18-159.el5xen ro root=/dev/VolGroup00/LogVol00 rhgb quiet
              module /initrd-2.6.18-159.el5xen.img
      
  3. Reinicie para cargar el nuevo kernel

    Reinicie el sistema. El computador reiniciará con el kernel predeterminado. El módulo de KVM se debe cargar automáticamente con el kernel. Verifique si el KVM está ejecutándose:
    $ lsmod | grep kvm
    kvm_intel              85992  1 
    kvm                   222368  2 ksm,kvm_intel
    
    El módulo kvm y el módulo kvm_intel o kvm_amd están presentes si todo está correcto.

32.2.2. De KVM a Xen

El siguiente procedimiento cubre el cambio desde un hipervisor KVM a un hipervisor Xen. Este procedimiento supone que el paquete kvm está instalado y habilitado.
  1. Instale los paquetes de Xen

    Instale los paquetes kernel-xen y xen si aún no lo ha hecho.
    # yum install kernel-xen xen
    
    El paquete kernel-xen puede estar instalado pero desactivado.
  2. Verifique cuál kernel está en uso

    Use el comando uname para determinar cuál comando está ejecutándose.
    $ uname -r
    2.6.18-159.el5
    
    El kernel actual, "2.6.18-159.el5", está ejecutándose en el sistema. Es el kernel predeterminado. Si el kernel termina en xen (por ejemplo, 2.6.18-159.el5xen), significa que el kernel de Xen está ejecutándose y puede pasar por alto este paso.
    1. Cambio del kernel predeterminado al kernel Xen

      El archivo grub.conf determina el kernel de arranque. Para cambiar al kernel predeterminado, edite el archivo /boot/grub/grub.conf como se muestra a continuación.
      								default=0
      timeout=5
      splashimage=(hd0,0)/grub/splash.xpm.gz
      hiddenmenu
      title Red Hat Enterprise Linux Server (2.6.18-159.el5)
              root (hd0,0)
              kernel /vmlinuz-2.6.18-159.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
              initrd /initrd-2.6.18-159.el5.img
      title Red Hat Enterprise Linux Server (2.6.18-159.el5xen)
              root (hd0,0)
              kernel /xen.gz-2.6.18-159.el5
              module /vmlinuz-2.6.18-159.el5xen ro root=/dev/VolGroup00/LogVol00 rhgb quiet
              module /initrd-2.6.18-159.el5xen.img
      
      Observe el parámetro default=0. Este parámetro le está indicando al gestor de arranque GRUB que arranque la primera entrada, el kernel predeterminado. Cambie el valor predeterminado a 1 (o al número para el kernel Xen):
      								default=1
      timeout=5
      splashimage=(hd0,0)/grub/splash.xpm.gz
      hiddenmenu
      title Red Hat Enterprise Linux Server (2.6.18-159.el5)
              root (hd0,0)
              kernel /vmlinuz-2.6.18-159.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
              initrd /initrd-2.6.18-159.el5.img
      title Red Hat Enterprise Linux Server (2.6.18-159.el5xen)
              root (hd0,0)
              kernel /xen.gz-2.6.18-159.el5
              module /vmlinuz-2.6.18-159.el5xen ro root=/dev/VolGroup00/LogVol00 rhgb quiet
              module /initrd-2.6.18-159.el5xen.img
      
  3. Reinicie para cargar el nuevo kernel

    Reinicie el sistema. El computador reiniciará con el kernel Xen. Verifique con el comando uname:
    $ uname -r
    2.6.18-159.el5xen
    
    Si la salida tiene xen al final, significa que el kernel Xen se está ejecutando.

32.3. Uso de qemu-img

La herramienta de línea de comandos qemu-img sirve para dar formato a varios sistemas de archivo utilizados por Xen y KVM. qemu-img se debe utilizar para dar formato a imágenes de huéspedes virtualizadas, dispositivos de almacenaje adicional y almacenamiento de redes. Las opciones de qemu-img y los usos se listan a continuación.
Dar formato y crear nuevas imágenes o dispositivos
Crear el nombre de archivo de la nueva imagen de disco de tamaño size y formato format.
# qemu-img create [-6] [-e] [-b base_image] [-f format] filename [size]
Si la imagen de base es especificada, entonces la imagen registrará únicamente las diferencias de la imagen de base. No se necesita especificar el tamaño en este caso. La imagen de base nunca será modificada a menos que utilice el comando del monitor "commit".
Convertir una imagen existente a otro formato
La opción convert sirve para convertir un formato reconocido a otra imagen de formato.
Formato de comando:
# qemu-img convert [-c] [-e] [-f format] filename [-O output_format] output_filename
Convierte la imagen de disco filename a imagen de disco output_filename mediante el formato output_format. La imagen de disco puede ser encriptada con la opción -e o comprimida con la opción -c.
Sólo el formato "qcow" admite encriptación o compresión. La compresión es de sólo lectura, es decir, si un sector comprimido es rescrito, entonces se rescribe como datos descomprimidos.
La encriptación utiliza el formato AES con claves muy seguras de 128 bits. Use una contraseña larga (de más de 16 caracteres) para obtener máxima protección.
La conversión de imagen también es útil para obtener una imagen más pequeña cuando se utilicen formatos que puede crecer, tales como qcow o cow. Los sectores vacíos son detectados y suprimidos de la imagen de destino.
Obtener información de imagen
El parámetro info muestra información acerca de una imagen de disco. El formato para la opción info debe ser así:
# qemu-img info [-f format] filename
Informa sobre el nombre de archivo de imagen de disco. Utilícelo, en particular, para saber el tamaño reservado en disco, el cual puede ser diferente al tamaño mostrado. Si las instantáneas de VM están almacenadas en la imagen de disco, también se mostrarán.
Formatos compatibles
El formato de una imagen suele reconocerse automáticamente. Los siguientes formatos son compatibles:
raw
El formato de imagen del disco crudo (predeterminado). Este formato tiene la ventaja de ser sencillo y de fácil exportación a los demás emuladores. Si su sistema de archivos admite huecos (por ejemplo en ext2 o ext3 en Linux o NTFS en Windows), entonces sólo los sectores escritos reservarán espacio. Use qemu-img info para concocer el tamaño real utilizado por la imagen o ls -ls en Unix/Linux.
qcow2
El formato de imagen QEMU, el formato más versátil. Utilícelo para imágenes más pequeñas (útil si su sistema de archivos no admite huecos, por ejemplo: en Windows), encriptación opcional AES, compresión basada en zlib y soporte de múltiples instantáneas de VM.
qcow
Formato anterior de imagen QEMU. Sólo se incluye para compatibilidad con versiones anteriores.
cow
El formato de imagen User Mode Linux Copy On Write. El formato cow se incluye sólo para compatibilidad con versiones anteriores. No funciona con Windows.
vmdk
Formato de imagen compatible de VMware 3 y 4.
cloop
Imagen Linux Compressed Loop, útil únicamente para reutilizar directamente imágenes comprimidas de CD-ROM, presentes por ejemplo, en los Knoppix CD-ROM.

32.4. Overcommitting Resources

The KVM hypervisor supports overcommitting CPUs and memory. Overcommitting is the process of allocating more virtualized CPUs or memory than there are physical resources on the system. CPU overcommit allows under-utilized virtualized servers or desktops to run on fewer servers which saves power and money.

Soporte de Xen

Memory overcommitting is not supported for the Xen hypervisor, however CPU overcommitting is supported.
Sobrecompromiso de memoria
La mayoría de los sistemas y aplicaciones no utilizan el 100 por ciento de la RAM disponible todo el tiempo. Esta conducta se puede aprovechar con KVM para usar más huéspedes virtualizados que los que están disponibles físicamente.
When using KVM, virtual machines operate as Linux processes. Guests on the KVM hypervisor do not have blocks of physical RAM assigned to them, instead they function as processes. Each process in a Linux system is allocated memory when it requests more memory. In a similar way, KVM allocates memory for guests when the guest requests more or less memory. The guest only uses slightly more physical memory than the virtualized operating system appears to use.
When physical memory is nearly completely used or a process is inactive for some time, Linux moves the process's memory to swap. Swap is usually a partition on a hard disk drive or solid state drive which Linux uses to extend virtual memory. Swap is significantly slower than RAM.
As KVM virtual machines are Linux processes, memory used by virtualized guests can be put into swap if the guest is idle or not in heavy use. Memory can be committed over the total size of the swap and physical RAM. This can cause issues if virtualized guests use their total RAM. Without sufficient memory and swap space for the virtual machine processes, the system can run completely out of memory, leading to the failure of one or more virtual machine processes.

Advertencia

Si no hay suficiente swap disponible, el sistema operativo se cerrará a la fuerza. Esto puede dejar huéspedes inoperables. Evite sobrecomprometer más memoria de la que está disponible en swap.
La partición swap sirve para intercambiar memoria subutilizada al disco duro con el fin de agilizar el rendimiento de memoria. El tamaño de la partición swap se calcula de la cantidad de RAM y de la relación de sobrecompromiso. Se recomienda crear una partición más grande si va a sobrecomprometer memoria con KVM. La relación de sobrecompromiso recomendada es de 50 por ciento (0.5). La fórmula utilizada es:
(0.5 * RAM) + (overcommit ratio * RAM) = Recommended swap size
La Base de datos de Red Hat tiene un artículo sobre cómo determinar, de modo seguro y eficaz, el tamaño de una partición swap.
Overcommitting guests by swapping out temporarily unused guest memory can be very slow, due to the IO latency introduced by disk seek times. However, Red Hat Enterprise Linux virtualization with KVM can often avoid this disk IO penalty by merging multiple pages with identical content into the same physical pages. This is done by the KSM (Kernel Samepage Merging) kernel process, which scans memory to find identical pages. The KSM kernel process uses CPU time to avoid disk IO. This tradeoff is often beneficial in workloads with many smaller, similar guests.
Es posible ejecutar una relación de sobrecompromiso de 10 veces el número de huéspedes virtualizados sobre la cantidad de RAM física. Esto sólo funciona con algunas cargas de aplicaciones (por ejemplo, el escritorio de virtualización con un uso por debajo del 100 por ciento). Establecer las relaciones de sobrecompromiso no es una fórmula difícil, debe probar y personalizar la relación para su entorno.
Sobrecompromiso de CPU virtualizadas
El hipervisor KVM admite sobrecompromiso de CPU virtualizadas. Las CPU virtualizadas pueden ser sobrecomprometidas en cuanto a los límites de carga de los huéspedes virtualizados lo permitan. Tenga cuidado al sobrecomprometer las CPU virtuales (o VCPU), ya que las cargas cercanas al 100 por ciento pueden producir solicitudes o tiempos de respuesta inutilizables.
Las CPU virtualizadas se sobrecomprometen mejor cuando cada huésped virtualizado sólo tiene una VCPU. El programador de Linux es muy eficiente con el tipo de carga. KVM debe soportar huéspedes con cargas bajo el 100 por ciento en una relación de 5 VCPU. El sobrecompromiso de sólo huéspedes virtualizados de VCPU no es un problema.
No se pueden sobrecomprometer huéspedes de multiprocesamiento simétrico en un número superior al de los núcleos de procesamiento físicos. Por ejemplo, un huésped con cuatro VCPU, no debe ejecutarse en un huésped con un procesador de doble núcleo. El sobrecompromiso de huéspedes de multiprocesamiento simétrico en el número de núcleos de procesamiento físico, producirá una degradación importante del rendimiento.
La asignación de VCPU de huéspedes hasta el número de núcleos físicos es apropiada y funciona como se esperaba. Por ejemplo, ejecutar huéspedes virtualizados con cuatro VCPU en un host de núcleo cuádruple. Los huéspedes con menos de 100 por ciento de cargas deben funcionar correctamente en esta configuración.

Siempre haga una prueba primero

No sobrecomprometa memoria o CPU en un entorno de producción sin pruebas exhaustivas. Las aplicaciones que utilizan el 100 por ciento de recursos de memoria o de procesamiento, pueden tornarse inestables en entornos sobrecomprometidos. Haga la prueba antes de implementar.

32.5. Modificar /etc/grub.conf

This section describes how to safely and correctly change your /etc/grub.conf file to use the virtualization kernel. You must use the xen kernel to use the Xen hypervisor. Copy your existing xen kernel entry make sure you copy all of the important lines or your system will panic upon boot (initrd will have a length of '0'). If you require xen hypervisor specific values you must append them to the xen line of your grub entry.
La salida a continuación es un ejemplo de una entrada grub.conf desde un sistema ejecutando el paquete de kernel-xen. El archivo grub.conf en su sistema puede variar. La parte importante en el ejemplo a continuación es la sección desde la línea de title hasta la nueva línea siguiente.
#boot=/dev/sda
default=0
timeout=15
#splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu
serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1
terminal --timeout=10 serial console

title Red Hat Enterprise Linux Server (2.6.17-1.2519.4.21.el5xen)
	root (hd0,0)
	kernel /xen.gz-2.6.17-1.2519.4.21.el5 com1=115200,8n1
	module /vmlinuz-2.6.17-1.2519.4.21.el5xen ro root=/dev/VolGroup00/LogVol00
	module /initrd-2.6.17-1.2519.4.21.el5xen.img

Un punto importante sobre la edición de grub.conf...

Your grub.conf could look very different if it has been manually edited before or copied from an example. Read Capítulo 28, Configuración de parámetros de arranque de Xen for more information on using virtualization and grub.
Para establecer la cantidad de memoria asignada para su sistema de host en el tiempo de arranque a 256MB, añada dom0_mem=256M a la línea xen en su archivo grub.conf. La siguiente es una versión modificada de un archivo de configuración de GRUB del ejemplo anterior:
#boot=/dev/sda
default=0
timeout=15
#splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1
terminal --timeout=10 serial console

title Red Hat Enterprise Linux Server (2.6.17-1.2519.4.21.el5xen)
	root (hd0,0)
	kernel /xen.gz-2.6.17-1.2519.4.21.el5 com1=115200,8n1 dom0_mem=256MB
	module /vmlinuz-2.6.17-1.2519.4.21.el5xen ro
	root=/dev/VolGroup00/LogVol00
	module /initrd-2.6.17-1.2519.4.21.el5xen.img

32.6. Verificar extensiones de virtualización

Utilice esta sección para determinar si su sistema tiene las extensiones de virtualización de hardware. Las extensiones de virtualización (Intel VT o AMD-V) se requieren para virtualización completa.

¿Puedo utilizar virtualización sin las extensiones de virtualización?

Si las extensiones de virtualización no están presentes, puede usar para-virtualización Xen con el paquete kernel-xen de Red Hat.
  1. Ejecute el siguiente comando para verificar si las extensiones de virtualización de CPU están disponibles:
    $ grep -E 'svm|vmx' /proc/cpuinfo
    
  2. Analyze the output.
    • La siguiente salida contiene una entrada vmx que indica un procesador Intel con las extensiones de Intel VT:
      flags   : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 clflush 
      	dts acpi mmx fxsr sse sse2 ss ht  tm syscall lm constant_tsc pni monitor ds_cpl
      	vmx est tm2 cx16 xtpr lahf_lm
      
    • La siguiente salida contiene una entrada svm que indica un procesador AMD con extensiones de AMD-V.
      flags   :  fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 clflush
      	mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni cx16
      	lahf_lm cmp_legacy svm cr8legacy ts fid vid ttp tm stc
      
    If any output is received, the processor has the hardware virtualization extensions. However in some circumstances manufacturers disable the virtualization extensions in BIOS.
    El contenido de "flags:" puede aparecer varias veces para cada hiperproceso, núcleo o CPU activos en el sistema.
    The virtualization extensions may be disabled in the BIOS. If the extensions do not appear or full virtualization does not work refer to Procedimiento 35.1, “Habilitar extensiones de virtualización en BIOS”.
  3. For users of the KVM hypervisor

    If the kvm package is installed. I As an additional check, verify that the kvm modules are loaded in the kernel:
    # lsmod | grep kvm
    
    If the output includes kvm_intel or kvm_amd then the kvm hardware virtualization modules are loaded and your system meets requirements. sudo

Additional output

If the libvirt package is installed, the virsh command can output a full list of virtualization system capabilities. Run virsh capabilities as root to receive the complete list.

32.7. Accessing data from a guest disk image

There are various methods for accessing the data from guest image files. One common method is to use the kpartx tool, covered by this section, to mount the guest file system as a loop device which can then be accessed.
The kpartx command creates device maps from partition tables. Each guest storage image has a partition table embedded in the file.
The libguestfs and guestfish packages, available from the EPEL repository, allow advanced modification and access to guest file systems. The libguestfs and guestfish packages are not covered in this section at this time.

Advertencia

Guests must be offline before their files can be read. Editing or reading files of an active guest is not possible and may cause data loss or damage.
Procedimiento 32.1. Accessing guest image data
  1. Install the kpartx package.
    # yum install kpartx
    
  2. Use kpartx to list partition device mappings attached to a file-based storage image. This example uses a image file named guest1.img.
    # kpartx -l /var/lib/libvirt/images/guest1.img
    loop0p1 : 0 409600 /dev/loop0 63
    loop0p2 : 0 10064717 /dev/loop0 409663
    guest1 is a Linux guest. The first partition is the boot partition and the second partition is an EXT3 containing the root partition.
  3. Add the partition mappings to the recognized devices in /dev/mapper/.
    # kpartx -a /var/lib/libvirt/images/guest1.img
    
    1. Test that the partition mapping worked. There should be new devices in the /dev/mapper/ directory
      # ls /dev/mapper/
      loop0p1
      loop0p2
      
      The mappings for the image are named in the format loopXpY.
  4. Mount the loop device which to a directory. If required, create the directory. This example uses /mnt/guest1 for mounting the partition.
    # mkdir /mnt/guest1
    # mount /dev/mapper/loop0p1 /mnt/guest1 -o loop,ro
  5. The files are now available for reading in the /mnt/guest1 directory. Read or copy the files.
  6. Unmount the device so the guest image can be reused by the guest. If the device is mounted the guest cannot access the image and therefore cannot start.
    # umount /mnt/tmp
  7. Disconnect the image file from the partition mappings.
    # kpartx -d /var/lib/libvirt/images/guest1.img
    
The guest can now be started again.
Accessing data from guest LVM volumes
Many Linux guests use Logical Volume Management (LVM) volumes. Additional steps are required to read data on LVM volumes on virtual storage images.
  1. Add the partition mappings for the guest1.img to the recognized devices in the /dev/mapper/ directory.
    # kpartx -a /var/lib/libvirt/images/guest1.img
    
  2. In this example the LVM volumes are on a second partition. The volumes require a rescan with the vgscan command to find the new volume groups.
    # vgscan
    Reading all physical volumes . This may take a while...
    Found volume group "VolGroup00" using metadata type lvm2
  3. Activate the volume group on the partition (called VolGroup00 by default) with the vgchange -ay command.
    # vgchange -ay VolGroup00
    2 logical volumes in volume group VolGroup00 now active.
  4. Use the lvs command to display information about the new volumes. The volume names (the LV column) are required to mount the volumes.
    # lvs
    LV VG Attr Lsize Origin Snap% Move Log Copy%
    LogVol00 VolGroup00 -wi-a- 5.06G
    LogVol01 VolGroup00 -wi-a- 800.00M
  5. Mount /dev/VolGroup00/LogVol00 in the /mnt/guestboot/ directory.
    # mount /dev/VolGroup00/LogVol00 /mnt/guestboot
  6. The files are now available for reading in the /mnt/guestboot directory. Read or copy the files.
  7. Unmount the device so the guest image can be reused by the guest. If the device is mounted the guest cannot access the image and therefore cannot start.
    # umount /mnt/
  8. Disconnect the volume group VolGroup00
    # vgchange -an VolGroup00
    
  9. Disconnect the image file from the partition mappings.
    # kpartx -d /var/lib/libvirt/images/guest1.img
    
The guest can now be restarted.

32.8. Setting KVM processor affinities

This section covers setting processor and processing core affinities with libvirt for KVM guests.
By default, libvirt provisions guests using the hypervisor's default policy. For most hypervisors, the policy is to run guests on any available processing core or CPU. There are times when an explicit policy may be better, in particular for systems with a NUMA (Non-Uniform Memory Access) architecture. A guest on a NUMA system should be pinned to a processing core so that its memory allocations are always local to the node it is running on. This avoids cross-node memory transports which have less bandwidth and can significantly degrade performance.
On a non-NUMA systems some form of explicit placement across the hosts’ sockets, cores and hyperthreads may be more efficient.
Identifying CPU and NUMA topology
The first step in deciding what policy to apply is to determine the host’s memory and CPU topology. The virsh nodeinfo command provides information about how many sockets, cores and hyperthreads there are attached a host.
# virsh nodeinfo
CPU model:           x86_64
CPU(s):              8
CPU frequency:       1000 MHz
CPU socket(s):       2
Core(s) per socket:  4
Thread(s) per core:  1
NUMA cell(s):        1
Memory size:         8179176 kB
This system has eight CPUs, in two sockets, each processor has four cores.
The output shows that that the system has a NUMA architecture. NUMA is more complex and requires more data to accurately interpret. Use the virsh capabilities to get additional output data on the CPU configuration.
# virsh capabilities
<capabilities>
  <host>
    <cpu>
      <arch>x86_64</arch>
    </cpu>
    <migration_features>
      <live/>
      <uri_transports>
        <uri_transport>tcp</uri_transport>
      </uri_transports>
    </migration_features>
    <topology>
      <cells num='2'>
        <cell id='0'>
          <cpus num='4'>
            <cpu id='0'/>
            <cpu id='1'/>
            <cpu id='2'/>
            <cpu id='3'/>
          </cpus>
        </cell>
        <cell id='1'>
          <cpus num='4'>
            <cpu id='4'/>
            <cpu id='5'/>
            <cpu id='6'/>
            <cpu id='7'/>
          </cpus>
        </cell>
      </cells>
    </topology>
    <secmodel>
      <model>selinux</model>
      <doi>0</doi>
    </secmodel>
  </host>

 [ Additional XML removed ]

</capabilities>
The output shows two NUMA nodes (also know as NUMA cells), each containing four logical CPUs (four processing cores). This system has two sockets, therefore we can infer that each socket is a separate NUMA node. For a guest with four virtual CPUs, it would be optimal to lock the guest to physical CPUs 0 to 3, or 4 to 7 to avoid accessing non-local memory, which are significantly slower than accessing local memory.
If a guest requires eight virtual CPUs, as each NUMA node only has four physical CPUs, a better utilization may be obtained by running a pair of four virtual CPU guests and splitting the work between them, rather than using a single 8 CPU guest. Running across multiple NUMA nodes significantly degrades performance for physical and virtualized tasks.
Decide which NUMA node can run the guest
Locking a guest to a particular NUMA node offers no benefit if that node does not have sufficient free memory for that guest. libvirt stores information on the free memory available on each node. Use the virsh freecell command to display the free memory on all NUMA nodes.
# virsh freecell
0: 2203620 kB
1: 3354784 kB
If a guest requires 3 GB of RAM allocated, then the guest should be run on NUMA node (cell) 1. Node 0 only has 2.2GB free which is probably not sufficient for certain guests.
Lock a guest to a NUMA node or physical CPU set
Once you have determined which node to run the guest on, refer to the capabilities data (the output of the virsh capabilities command) about NUMA topology.
  1. Extract from the virsh capabilities output.
    <topology>
      <cells num='2'>
        <cell id='0'>
        <cpus num='4'>
          <cpu id='0'/>
          <cpu id='1'/>
          <cpu id='2'/>
          <cpu id='3'/>
        </cpus>
      </cell>
      <cell id='1'>
        <cpus num='4'>
          <cpu id='4'/>
          <cpu id='5'/>
          <cpu id='6'/>
          <cpu id='7'/>
        </cpus>
      </cell>
      </cells>
    </topology>
  2. Observe that the node 1, <cell id='1'>, has physical CPUs 4 to 7.
  3. The guest can be locked to a set of CPUs by appending the cpuset attribute to the configuration file.
    1. While the guest is offline, open the configuration file with virsh edit.
    2. Locate where the guest's virtual CPU count is specified. Find the vcpus element.
      <vcpus>4</vcpus>
      The guest in this example has four CPUs.
    3. Add a cpuset attribute with the CPU numbers for the relevant NUMA cell.
      <vcpus cpuset='4-7'>4</vcpus>
  4. Save the configuration file and restart the guest.
The guest has been locked to CPUs 4 to 7.
Automatically locking guests to CPUs with virt-install
The virt-install provisioning tool provides a simple way to automatically apply a 'best fit' NUMA policy when guests are created.
The cpuset option for virt-install can use a CPU set of processors or the parameter auto. The auto parameter automatically determines the optimal CPU locking using the available NUMA data.
For a NUMA system, use the --cpuset=auto with the virt-install command when creating new guests.
Tuning CPU affinity on running guests
There may be times where modifying CPU affinities on running guests is preferable to rebooting the guest. The virsh vcpuinfo and virsh vcpupin commands can perform CPU affinity changes on running guests.
The virsh vcpuinfo command gives up to date information about where each virtual CPU is running.
In this example, guest1 is a guest with four virtual CPUs is running on a KVM host.
# virsh vcpuinfo guest1
VCPU:           0
CPU:            3
State:          running
CPU time:       0.5s
CPU Affinity:   yyyyyyyy
VCPU:           1
CPU:            1
State:          running
CPU Affinity:   yyyyyyyy
VCPU:           2
CPU:            1
State:          running
CPU Affinity:   yyyyyyyy
VCPU:           3
CPU:            2
State:          running
CPU Affinity:   yyyyyyyy
The virsh vcpuinfo output (the yyyyyyyy value of CPU Affinity) shows that the guest can presently run on any CPU.
To lock the virtual CPUs to the second NUMA node (CPUs four to seven), run the following commands.
# virsh vcpupin guest1 0 4
# virsh vcpupin guest1 1 5
# virsh vcpupin guest1 2 6
# virsh vcpupin guest1 3 7
The virsh vcpuinfo command confirms the change in affinity.
# virsh vcpuinfo guest1
VCPU:           0
CPU:            4
State:          running
CPU time:       32.2s
CPU Affinity:   ----y---
VCPU:           1
CPU:            5
State:          running
CPU time:       16.9s
CPU Affinity:   -----y--
VCPU:           2
CPU:            6
State:          running
CPU time:       11.9s
CPU Affinity:   ------y-
VCPU:           3
CPU:            7
State:          running
CPU time:       14.6s
CPU Affinity:   -------y

32.9. Generar una nueva dirección MAC única

In some case you will need to generate a new and unique MAC address for a guest. There is no command line tool available to generate a new MAC address at the time of writing. The script provided below can generate a new MAC address for your guests. Save the script to your guest as macgen.py. Now from that directory you can run the script using ./macgen.py and it will generate a new MAC address. A sample output would look like the following:
$ ./macgen.py 
00:16:3e:20:b0:11
	
#!/usr/bin/python
# macgen.py script to generate a MAC address for virtualized guests on Xen
#
import random
#
def randomMAC():
	mac = [ 0x00, 0x16, 0x3e,
		random.randint(0x00, 0x7f),
		random.randint(0x00, 0xff),
		random.randint(0x00, 0xff) ]
	return ':'.join(map(lambda x: "%02x" % x, mac))
#
print randomMAC()
Otro método para generar un nuevo MAC para su huésped
También puede utilizar módulos incorporados de python-virtinst para generar una nueva dirección MAC y UUID para usar en un archivo de configuración de huésped:
# echo  'import virtinst.util ; print\
 virtinst.util.uuidToString(virtinst.util.randomUUID())' | python
# echo  'import virtinst.util ; print virtinst.util.randomMAC()' | python
El script anterior también se puede implementar como un script de archivos, así como se muestra a continuación.
#!/usr/bin/env python
#  -*- mode: python; -*-
print ""
print "New UUID:"
import virtinst.util ; print virtinst.util.uuidToString(virtinst.util.randomUUID())
print "New MAC:"
import virtinst.util ; print virtinst.util.randomMAC()
print ""

32.10. Limitar el ancho de banda de redes para un huésped de Xen

In some environments it may be required to limit the network bandwidth available to certain guests. This can be used to implement basic Quality of Service on a host running multiple virtual machines. By default, the guest can use any bandwidth setting available which your physical network card supports. The physical network card must be mapped to one of virtual machine's virtual network interfaces. In Xen the “rate” parameter part of the VIF entries can throttle virtualized guests.
La siguiente lista describe las variables:
rate
The rate= option can be added to the VIF= entry in a virtual machine configuration file to limit a virtual machine's network bandwidth or specify a specific time interval for a time window.
Ventana de tiempo
La ventana de tiempo es opcional para la opción rate=:
La ventana de tiempo predeterminada es de 50 ms.
Una ventana menor proporcionará menos transmisión de ráfaga, sin embargo, la tasa de reposición y latencia aumentará.
La ventana de tiempo de 50ms es un balance entre latencia y rendimiento y en la mayoría de los casos no requerirá cambio.
Ejemplos de valores del parámetro rate y usos.
rate=10Mb/s
Limita el tráfico de salida de redes del huésped a 10MB/s.
rate=250KB/s
Limita el tráfico de redes de salida del huésped a 250KB/s.
rate=10MB/s@50ms
Limita el ancho de banda a 10MB/s y proporciona el huésped con un pedazo de 50KB cada 50ms.
En la configuración de la máquina virtual una muestra de una entrada VIF, se vería de la siguiente manera:
vif = [ 'rate=10MB/s , mac=00:16:3e:7a:55:1c, bridge=xenbr1']
This rate entry would limit the virtual machine's interface to 10MB/s for outgoing traffic

32.11. Configurar afinidades de procesador Xen

Xen puede asignar CPU virtuales para asociar a una o más CPU de hosts. De esta manera, se asignan recursos de procesamiento real a huéspedes virtualizados. Este enfoque le permite a Red Hat Enterprise Linux optimizar los recursos de procesador cuando se emplean tecnologías de doble núcleo (dual-core), hiper-hilos u otras de la concurrencia de CPU. El programador de crédito Xen equilibra automáticamente las CPU virtuales entre las físicas, para maximizar el uso del sistema. Red Hat Enterprise Linux permite que el programador de crédito, desplace las CPU tan cerca como sea necesario, siempre y cuando la CPU virtual esté conectada a una CPU física.
Si va a ejecutar las tareas exhaustivas de E/S, se recomienda dedicar un procesador hiperhilos o un núcleo de procesador completo para ejecutar domain0.
Tenga en cuenta que esto no es necesario para KVM porque KVM utiliza el programador predeterminado de kernel de Linux.
Las afinidades de CPU se pueden establecer con virsh o virt-manager:
To set CPU affinities using virsh refer to Configurar la afinidad de la CPU virtual for more information.
To configure and view CPU information with virt-manager refer to Sección 26.11, “Mostrar las CPU virtuales” for more information.

32.12. Modificar el hipervisor Xen

Managing host systems often involves changing the boot configuration file /boot/grub/grub.conf. Managing several or more hosts configuration files quickly becomes difficult. System administrators often prefer to use the 'cut and paste' method for editing multiple grub.conf files. If you do this, ensure you include all five lines in the Virtualization entry (or this will create system errors). Hypervisor specific values are all found on the 'xen' line. This example represents a correct grub.conf virtualization entry:
# boot=/dev/sda/
default=0
timeout=15
#splashimage=(hd0, 0)/grub/splash.xpm.gz

hiddenmenu
serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1
terminal --timeout=10 serial console
title Red Hat Enterprise Linux Server (2.6.17-1.2519.4.21. el5xen)
root (hd0, 0)
kernel /xen.gz-2.6.17-1.2519.4.21.el5 com1=115200,8n1
    module /vmlinuz-2.6.17-1.2519.4.21el5xen ro root=/dev/VolGroup00/LogVol00
    module /initrd-2.6.17-1.2519.4.21.el5xen.img
For example, to change the memory entry on your hypervisor (dom0) to 256MB at boot time, edit the 'xen' line and append it with this entry: 'dom0_mem=256M'. This example is the grub.conf with the hypervisor's memory entry modified.
# boot=/dev/sda
default=0
timeout=15
#splashimage=(hd0,0)/grubs/splash.xpm.gz
hiddenmenu
serial --unit=0 --speed =115200 --word=8 --parity=no --stop=1
terminal --timeout=10 serial console
title Red Hat Enterprise Linux Server (2.6.17-1.2519.4.21. el5xen)
root (hd0,0)
kernel /xen.gz-2.6.17-1.2519.4.21.el5 com1=115200,8n1 dom0_mem=256MB
    module /vmlinuz-2.6.17-1.2519.4.21.el5xen ro root=/dev/VolGroup00/LogVol00
    module /initrd-2.6.17-1.2519.4.21.el5xen.img

32.13. Very Secure ftpd

El vsftpd puede proporcionar acceso a árboles de instalación para huéspedes para-virtualizados (por ejemplo, los repositorios de Enterprise Linux 5) u otros datos. SI no ha instalado vsftpd durante la instalación del servidor, puede tomar el paquete RPM desde el directorio Server de sus medios de instalación e instalarlo mediante rpm -ivh vsftpd*.rpm (observe que el paquete RPM debe estar en su directorio actual).
  1. To configure vsftpd, edit /etc/passwd using vipw and change the ftp user's home directory to the directory where you are going to keep the installation trees for your para-virtualized guests. An example entry for the FTP user would look like the following:
    ftp:x:14:50:FTP User:/xen/pub:/sbin/nologin
    
  2. Compruebe si vsftpd no está habilitado, usando chkconfig --list vsftpd:
    $ chkconfig --list vsftpd
    vsftpd          0:off   1:off   2:off   3:off   4:off   5:off   6:off
    
  3. Ejecute chkconfig --levels 345 vsftpd on para iniciar vsftpd automáticamente para ejecutar los niveles 3, 4 y 5.
  4. Use el comando chkconfig --list vsftpd para comprobar si el demonio vsftpd ha sido habilitado para iniciar durante el arranque del sistema:
    $ chkconfig --list vsftpd
    vsftpd          0:off   1:off   2:off   3:on    4:on    5:on    6:off
    
  5. Use service vsftpd start vsftpd para iniciar el servicio vsftpd:
    $service vsftpd start vsftpd
    Starting vsftpd for vsftpd:                  [  OK  ]
    

32.14. Configurar persistencia de LUN

This section covers how to implement LUN persistence in guests and on the host machine with and without multipath.
Implementación de persistencia de LUN sin multirutas
Si su sistema no está utilizando multirutas, puede utilizar udev para implementar persistencia de LUN. Antes de implementar persistencia de Lun en su sistema, asegúrese de adquirir los UUID apropiados. Una vez adquiridos, puede configurar la persistencia de LUN editando el archivo scsi_id, ubicado en el directorio /etc . Una vez tenga este archivo abierto en un editor de texto, quítele el comentario a esta línea:
# options=-b
Luego, remplácelo por este parámetro:
# options=-g
Este parámetro le indica a udev que debe monitorizar todos los dispositivos SCSI del sistema para los UUID que retornen. Para determinar los UUID del sistema, utilice el comando scsi_id:
# scsi_id -g -s /block/sdc
*3600a0b80001327510000015427b625e*
Esta cadena larga de caracteres en la salida es el UUID. El UUID, no cambia cuando se añade un nuevo dispositivo al sistema. Adquiera el UUID para cada dispositivo con el fin de crear reglas para los dispositivos. Para crear nuevas reglas de dispositivo, edite el archivo 20-names.rules en el directorio /etc/udev/rules.d . Las nuevas reglas para nombrar dispositivos siguen este formato:
# KERNEL="sd*",  BUS="scsi",  PROGRAM="sbin/scsi_id", RESULT="UUID", NAME="devicename"
Remplace su UUID y devicename por la entrada anterior recuperada de UUID. La regla debe parecerse a la siguiente:
KERNEL="sd*",  BUS="scsi",  PROGRAM="sbin/scsi_id", RESULT="3600a0b80001327510000015427b625e", NAME="mydevicename"
Esto permite a los dispositivos coincidentes con el patrón de /dev/sd* inspeccionar el UUID determinado. Cuando encuentra un dispositivo coincidente, crea un nodo de dispositivo llamado /dev/devicename. Para este ejemplo, el nodo de dispositivo es /dev/mydevice . Por último, añada el archivo /etc/rc.local con la siguiente línea:
/sbin/start_udev
Implementar la persistencia de Lun con multirutas
Para implementar la persistencia de LUN en un entorno de multirutas, debe definir los alias para los dispositivos multirutas. En este ejemplo, debe definir cuatro alias de dispositivo editando el archivo multipath.conf ubicado en el directorio /etc/:
multipath  {  
             wwid       3600a0b80001327510000015427b625e
             alias      oramp1
}
multipath  {  
             wwid       3600a0b80001327510000015427b6
             alias      oramp2
}
multipath  {  
             wwid       3600a0b80001327510000015427b625e
             alias      oramp3
}
multipath  {  
             wwid       3600a0b80001327510000015427b625e
             alias      oramp4
}
Se definen cuatro LUN: /dev/mpath/oramp1, /dev/mpath/oramp2, /dev/mpath/oramp3 y dev/mpath/oramp4. Los dispositivos residirán en el directorio /dev/mpath . Estos nombres de LUN son persistentes a través de los reinicios, ya que éste crea los nombres de alias en los wwid para cada LUN.

32.15. Inhabilitar la monitorización de disco SMART para huéspedes

La monitorización de disco SMART se puede desactivar mientras se esté ejecutando en discos virtuales y el almacenaje físico sea manejado por el host.
/sbin/service smartd stop
/sbin/chkconfig --del smartd

32.16. Limpiar archivos de configuración Xen anteriores

Over time you will see a number of files accumulate in /var/lib/xen, the usually named vmlinuz.****** and initrd.******. These files are the initrd and vmlinuz files from virtual machines which either failed to boot or failed for some other reason. These files are temporary files extracted from virtual machine's boot disk during the start up sequence. These files should be automatically removed after the virtual machine is shut down cleanly. Then you can safely delete old and stale copies from this directory.

32.17. Configurar un servidor VNC

Para configurar un servidor VNC use la aplicación Escritorio remoto en Sistema > Preferencias. Alternativamente, puede ejecutar el comando vino-preferences.
Los siguientes pasos configuran una sesión de servidor VNC dedicado:
  1. Edite el archivo ~/.vnc/xstartup para iniciar la sesión de GNOME cada vez que vncserver sea iniciado. La primera vez que usted ejecute el script vncserver se le pedirá la contraseña que desee utilizar para su sesión de VNC.
  2. Una muestra del archivo xstartup:
    #!/bin/sh
    # Uncomment the following two lines for normal desktop:
    # unset SESSION_MANAGER
    # exec /etc/X11/xinit/xinitrc
    [ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
    [ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
    #xsetroot -solid grey
    #vncconfig -iconic &
    #xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
    #twm &
    if test -z "$DBUS_SESSION_BUS_ADDRESS" ; then
    	eval `dbus-launch --sh-syntax –exit-with-session`
    	echo "D-BUS per-session daemon address is: \
    	$DBUS_SESSION_BUS_ADDRESS"
    fi
    exec  gnome-session
    

32.18. Clonar los archivos de configuración de huésped

You can copy an existing configuration file to create an all new guest. You must modify the name parameter of the guests' configuration file. The new, unique name then appears in the hypervisor and is viewable by the management utilities. You must generate an all new UUID as well by using the uuidgen command. Then for the vif entries you must define a unique MAC address for each guest (if you are copying a guest configuration from an existing guest, you can create a script to handle it). For the xen bridge information, if you move an existing guest configuration file to a new host, you must update the xenbr entry to match your local networking configuration. For the Device entries, you must modify the entries in the 'disk=' section to point to the correct guest image.
You must also modify these system configuration settings on your guest. You must modify the HOSTNAME entry of the /etc/sysconfig/network file to match the new guest's hostname.
Debe modificar la dirección de HWADDR del archivo /etc/sysconfig/network-scripts/ifcfg-eth0 para que coincida con la salida del archivo ifconfig eth0 y si está utilizando direcciones IP estáticas, debe modificar la entrada IPADDR.

32.19. Duplicar un huésped existente y su archivo de configuración

This section outlines copying an existing configuration file to create a new guest. There are key parameters in your guest's configuration file you must be aware of, and modify, to successfully duplicate a guest.
name
El nombre de su huésped como es conocido por el hipervisor y mostrado en utilidades de administración. Esta entrada debe ser única en su sistema.
uuid
Un identificador único para el huésped, un nuevo UUID se puede generar mediante el comando uuidgen. La siguiente es una muestra de salida UUID:
$ uuidgen 
a984a14f-4191-4d14-868e-329906b211e5
vif
  • The MAC address must define a unique MAC address for each guest. This is automatically done if the standard tools are used. If you are copying a guest configuration from an existing guest you can use the script Sección 32.9, “Generar una nueva dirección MAC única”.
  • Si está desplazando o duplicando un archivo de configuración de huésped existente a un nuevo host, tiene que asegurarse de ajustar la entrada xenbr para que corresponda con su configuración de red local (puede obtener la información de puente mediante el comando brctl show).
  • Entradas de dispositivo, asegúrese de ajustar las entradas en la sección de disk= para apuntar a la imagen de huésped correcta.
Ahora, ajuste la configuración del sistema en su huésped:
/etc/sysconfig/network
Modify the HOSTNAME entry to the guest's new hostname.
/etc/sysconfig/network-scripts/ifcfg-eth0
  • Modifique la dirección de HWADDR para la salida desde ifconfig eth0.
  • Modifique la entrada de IPADDR si la dirección IP estática es utilizada.

Capítulo 33. Creación de scripts libvirt personales

Esta sección ofrece información que puede ser útil para programadores y administradores de sistemas que tengan intención de escribir scripts personalizados, que les faciliten la vida, mediante libvirt.
Capítulo 32, Consejos y trucos is recommended reading for programmers thinking of writing new applications which use libvirt.

33.1. Uso de los archivos de configuración XML con virsh

virsh can handle XML configuration files. You may want to use this to your advantage for scripting large deployments with special options. You can add devices defined in an XML file to a running para-virtualized guest. For example, to add a ISO file as hdc to a running guest create an XML file:
# cat satelliteiso.xml
<disk type="file" device="disk">
	<driver name="file"/>
	<source file="/var/lib/libvirt/images/rhn-satellite-5.0.1-11-redhat-linux-as-i386-4-embedded-oracle.iso"/>
	<target dev="hdc"/>
	<readonly/>
</disk>
Run virsh attach-device to attach the ISO as hdc to a guest called "satellite" :
# virsh attach-device satellite satelliteiso.xml

Parte VIII. Solución de problemas

Introducción a la identificación y solución de problemas

Los siguientes capítulos proporcionan información para ayudarle a identificar y solucionar problemas que pueden surgir al utilizar virtualización.

Nota importante sobre problemas de virtualización

Puede que su problema específico no aparezca en este libro debido a un desarrollo en curso, el cual crea y corrige errores. Para obtener la lista actualizada de los errores conocidos, problemas y corrección de errores, consulte las Notas de Lanzamiento de Red Hat Enterprise Linux para su versión y arquitectura de hardware. Las Notas de Lanzamiento pueden encontrarse en la sección de documentación del sitio Web de Red Hat, www.redhat.com/docs/manuals/enterprise/.

Si todo lo demás falla..

Contacte Red Hat Global Support Services (https://www.redhat.com/apps/support/). Nuestro personal lo ayudará con gusto a resolver sus problemas.

Tabla de contenidos

34. Solución de problemas Xen
34.1. Depuración e identificación y resolución de problemas de Xen
34.2. Visión general de archivos de registro
34.3. Descripción del archivo de registro
34.4. Ubicación de directorios importantes
34.5. Detección y solución de problemas con registros
34.6. Detección y solución de problemas con la consola serial
34.7. Acceso de consola del huésped para-virtualizado
34.8. Acceso a la consola de huésped completamente virtualizado
34.9. Problemas comunes de Xen
34.10. Errores durante la creación de huéspedes
34.11. Detección y solución de problemas con consolas seriales
34.11.1. Salida de consola serial para Xen
34.11.2. Salida de consola serial de Xen de los huéspedes para-virtualizados
34.11.3. Salida de consola serial desde huéspedes completamente virtualizados
34.12. Archivos de configuración Xen
34.13. Interpretación de mensajes de error Xen
34.14. Presentación de los directorios de registro
35. Solución de problemas
35.1. Identificar almacenamiento disponible y particiones
35.2. Después de reiniciar los huéspedes basados en Xen la consola se congela
35.3. Los dispositivos Ethernet virtualizados no se encuentran mediante herramientas de red
35.4. Errores del dispositivo en bucle
35.5. Falló la creación de dominio por escasez de memoria
35.6. Wrong kernel image error
35.7. Wrong kernel image error - non-PAE kernel on a PAE platform
35.8. El huésped completamente virtualizado falla en el arranque
35.9. Una entrada de host local faltante hace que el virt-manager falle
35.10. Error de microcódigo durante el arranque de huésped.
35.11. Mensajes de advertencia de depreciación de Python al inicio de una máquina virtual
35.12. Habilitando las extensiones de virtualización de hardware Intel VT y AMD-V en BIOS
35.13. Rendimiento de redes KVM
36. Detección y solución de errores de los controladores de para-virtualización.
36.1. Directorios y archivo de registro de virtualización de Red Hat Enterprise Linux 5
36.2. Huésped para-virtualizado falla al cargar en un sistema operativo de huésped Red Hat Enterprise Linux 3
36.3. Se muestra un mensaje de advertencia durante la instalación de los controladores para-virtualizados en Red Hat Enterprise Linux 3
36.4. Cargar manualmente los controladores para- virtualizados
36.5. Verificación de los controladores para-virtualizados cargados correctamente
36.6. El sistema tiene rendimiento limitado con controladores para-virtualizados

Capítulo 34. Solución de problemas Xen

Este capítulo cubre conceptos esenciales para ayudarle en la identificación y solución de problemas en Xen. Los temas sobre solución de problemas cubiertos en este capítulo incluyen:
  • Las herramientas de solución de problemas para Linux y virtualización.
  • Las técnicas para identificar y solucionar problemas.
  • La ubicación de los archivos de registro y explicaciones de la información en registros.
Este capítulo intenta ofrecerle al lector, una base para identificar dónde están los problemas de las tecnologías de virtualización. La identificación y resolución de problemas requiere práctica y experiencia, lo cual no se puede aprender en este libro. Se recomienda experimentar y probar la virtualización en Red Hat Enterprise Linux para desarrollar sus destrezas en la identificación y resolución de problemas.
If you cannot find the answer in this document there may be an answer online from the virtualization community. Refer to Sección A.1, “Recursos en línea” for a list of Linux virtualization websites.

34.1. Depuración e identificación y resolución de problemas de Xen

Esta sección resume las aplicaciones para el administrador del sistema, las utilidades de red y las herramientas de depuración. Puede emplear estas herramientas de administración de sistemas estándares como ayuda durante el proceso de detección y corrección de errores.
Comandos y aplicaciones útiles para detectar y solucionar problemas
xentop
xentop muestra la información en tiempo real sobre un sistema de host y dominios de huéspedes.
xm
Uso de dmesg y log
  • vmstat
  • iostat
  • lsof
Los comandos iostat, mpstat y sar vienen en el paquete sysstat.
Puede emplear estas herramientas de depuración avanzadas y registros durante el proceso de detección y solución de errores:
  • XenOprofile
  • systemtap
  • crash
  • sysrq
  • sysrq t
  • sysrq w
Estas herramientas de red pueden ayudar en la identificación y solución de problemas de virtualización de redes:
  • ifconfig
  • tcpdump
    The tcpdump command 'sniffs' network packets. tcpdump is useful for finding network abnormalities and problems with network authentication. There is a graphical version of tcpdump named wireshark.
  • brctl
    brctl es una herramienta de red que inspecciona y establece la configuración del puente Ethernet en el Kernel de Virtualización de Linux. Debe tener acceso de root antes de ejecutar estos comandos de ejemplo:
    # brctl show 
    
    bridge-name    bridge-id          STP  enabled  interfaces  
    -----------------------------------------------------------------------------
    xenbr0             8000.feffffff       no        vif13.0
    xenbr1             8000.ffffefff       yes       pddummy0
    xenbr2             8000.ffffffef       no        vif0.0
    
    # brctl showmacs xenbr0
    
    port-no           mac-addr                  local?       aging timer
    
    1                 fe:ff:ff:ff:ff:           yes            0.00
    2                 fe:ff:ff:fe:ff:           yes            0.00
    
    
    # brctl showstp xenbr0
    xenbr0 
    bridge-id              8000.fefffffffff
    designated-root        8000.fefffffffff
    root-port              0                   path-cost             0
    max-age                20.00               bridge-max-age        20.00
    hello-time             2.00                bridge-hello-time     2.00
    forward-delay          0.00                bridge-forward-delay  0.00
    aging-time            300.01
    hello-timer            1.43                tcn-timer             0.00
    topology-change-timer  0.00                gc-timer              0.02
    
A continuación aparece la lista de los comandos útiles para identificar y resolver problemas de virtualización en Red Hat Enterprise Linux 5. Todas las utilidades mencionadas se pueden encontrar en los repositorios del Server de Red Hat Enterprise Linux 5.
  • strace es un comando que rastrea las llamadas de sistema y eventos recibidos y utilizados por otro proceso.
  • vncviewer: connect to a VNC server running on your server or a virtual machine. Install vncviewer using the yum install vnc command.
  • vncserver: inicia un escritorio remoto en su servidor. Le brinda la habilidad de ejecutar interfaces de usuario gráficas tales como una sesión remota a través de virt-manager. Instale vncserver mediante el comando yum install vnc-server.

34.2. Visión general de archivos de registro

When deploying Red Hat Enterprise Linux 5 with Virtualization into your network infrastructure, the host's Virtualization software uses many specific directories for important configuration, log files, and other utilities. All the Xen logs files are standard ASCII files, and accessible with a text editor:
  • El directorio de configuración Xen es /etc/xen/. Este directorio contiene el demonio xend y otros archivos de configuración de máquinas virtuales. Los archivos de script de red se encuentran en el directorio scripts.
  • Todos los archivos de registro de Xen están almacenados en el directorio /var/log/xen.
  • El directorio /var/lib/libvirt/images es el directorio predeterminado para todas las imágenes basadas en archivo.
  • La información de kernel de Xen está almacenada en el directorio /proc/xen/.

34.3. Descripción del archivo de registro

Las funciones del demonio xend y del proceso qemu-dm, contienen dos utilidades que escriben varios archivos de registro en el directorio /var/log/xen:
  • xend.log es el archivo de registro que contiene todos los datos recogidos por el demonio xend, ya sean éstos eventos normales del sistema o acciones iniciadas por el operador. Todas las operaciones de máquina virtual (crear, apagar, destruir, etc.) aparecen en este registro. xend.log suele ser el primer lugar donde se debe mirar cuando se detecta un evento o problemas de rendimiento. Este archivo contiene entradas detalladas sobre los mensajes de error.
  • xend-debug.log es el archivo de registro que contiene entradas sobre los errores de eventos de xend y los subsistemas de virtualización (tales como, framebuffer, scripts de Python, etc).
  • xen-hotplug-log es el archivo de registro que contiene datos sobre los eventos de conexión en caliente. Si un dispositivo o script de red no aparece en línea, el evento será registrado en este archivo.
  • qemu-dm.[PID].log es el archivo de registro creado por el proceso qemu-dm para cada huésped completamente virtualizado. Cuando utilice este archivo de registro, debe recuperar el PID del proceso qemu-dm con el comando ps para examinar los argumentos del proceso para aislar el proceso qemu-dm en la máquina virtual. Tenga en cuenta que debe remplazar el símbolo [PID] por el PID del proceso de qemu-dm.
Si encuentra algún error con el Administrador de máquinas virtuales, puede revisar los datos generados en el archivo virt-manager.log ubicado en el directorio /.virt-manager . Tenga en cuenta que cada vez que inicia el Administrador de máquinas virtuales, el contenido del archivo de registro será sobreescrito. Asegúrese de crear una copia de seguridad de virt-manager.log, antes de reiniciar el Administrador de máquinas virtuales después de un error del sistema.

34.4. Ubicación de directorios importantes

Hay otras utilidades y archivos de registro que se deben tener en cuenta a la hora de detectar y solucionar errores con Xen:
  • Las imágenes de huésped virtualizado se ubican en /var/lib/libvirt/images.
  • Cuando se reinicia el demonio xend, éste actualiza xend-database, ubicada en el directorio /var/lib/xen/xend-db.
  • El volcado de máquina virtuales (ejecutado con el comando xm dump-core) está en el directorio /var/lib/xen/dumps.
  • El directorio /etc/xen contiene los archivos de configuración que sirven para administrar recursos del sistema. El archivo de configuración del demonio xend es /etc/xen/xend-config.sxp. Este archivo puede ser modificado para implementar cambios en el sistema y configurar la red. No obstante, la edición manual de archivos en la carpeta /etc/xen/ no es recomendable.
  • Las carpetas proc son otro recurso para obtener información del sistema. Estas entradas proc están ubicadas en el directorio /proc/xen:
/proc/xen/capabilities
/proc/xen/balloon
/proc/xen/xenbus/

34.5. Detección y solución de problemas con registros

When encountering installation issues with Xen, refer to the host system's two logs to assist with troubleshooting. The xend.log file contains the same basic information as when you run the xm log command. This log is found in the /var/log/ directory. Here is an example log entry for when you create a domain running a kernel:
[2006-12-27 02:23:02 xend] ERROR (SrvBase: 163) op=create: Error creating domain: (0, 'Error')
Traceback (most recent call list)
File "/usr/lib/python2.4/site-packages/xen/xend/server/SrvBase.py" line 107 in_perform val = op_method (op,req)
File
"/usr/lib/python2.4/site-packages/xen/xend/server/SrvDomainDir.py line 71 in op_create
raise XendError ("Error creating domain: " + str(ex))
XendError: Error creating domain: (0, 'Error')
El otro archivo de registro, xend-debug.log, es bastante útil para los administradores de sistemas ya que contiene una información aún más detallada que la proporcionada en xend.log . A continuación están los mismos datos de error para el mismo problema de creación del dominio de kernel:
ERROR: Will only load images built for Xen v3.0
ERROR: Actually saw: GUEST_OS=netbsd, GUEST_VER=2.0, XEN_VER=2.0; LOADER=generic, BSD_SYMTAB'
ERROR: Error constructing guest OS
Incluya siempre una copia de estos dos archivos de registro cuando contacte al equipo de asistencia técnica.

34.6. Detección y solución de problemas con la consola serial

The serial console is helpful in troubleshooting difficult problems. If the Virtualization kernel crashes and the hypervisor generates an error, there is no way to track the error on a local host. However, the serial console allows you to capture it on a remote host. You must configure the host to output data to the serial console. Then you must configure the remote host to capture the data. To do this, you must modify these options in the grub.conf file to enable a 38400-bps serial console on com1 /dev/ttyS0:
title Red Hat Enterprise Linux (2.6.18-8.2080_xen0)
	root (hd0,2)
	kernel /xen.gz-2.6.18-8.el5 com1=38400,8n1 
	module /vmlinuz-2.618-8.el5xen ro root=LABEL=/rhgb quiet console=xvc console=tty xencons=xvc 	
	module /initrd-2.6.18-8.el5xen.img
sync_console puede ayudar a determinar el problema que hace que la salida de consola del hipervisor asíncrono se cuelgue y "pnpacpi=off" trate de solucionar el problema que corrompe la entrada en la consola serial. Los parámetros "console=ttyS0" y "console=tty" indican que los errores del kernel se registran tanto en la consola VGA como en la consola serial. Luego puede instalar y configurar ttywatch para capturar los datos en el host remoto conectado a través de un cable null-modem estándar. Por ejemplo, puede escribir en el host remoto:

Detección y solución de problemas de la consola serial Itanium

To access the hypervisor via a serial console on the Itanium® architecture you must enable the console in ELILO. For more information on configuring ELILO, refer to Capítulo 29, Configuración de ELILO.
ttywatch --name myhost --port /dev/ttyS0
Este crea una tubería desde /dev/ttyS0 hasta /var/log/ttywatch/mihost.log .

34.7. Acceso de consola del huésped para-virtualizado

Para-virtualized guest operating systems automatically has a virtual text console configured to transmit data to the host operating system. Connect to a guest's virtual console with the following command:
# virsh console [guest name, ID or UUID]
You can also use virt-manager to display the virtual text console. In the guest console window, select Serial Console from the View menu.

34.8. Acceso a la consola de huésped completamente virtualizado

Fully virtualized guest operating systems automatically has a text console configured for use, but the difference is the kernel guest is not configured. To enable the guest virtual serial console to work with the Full Virtualized guest, you must modify the guest's grub.conf file, and include the 'console =ttyS0 console=tty0' parameter. This ensures that the kernel messages are sent to the virtual serial console (and the normal graphical console). To use the guest's serial console, you must edit the libvirt configuration file configuration file. On the host, access the serial console with the following command:
# virsh console
You can also use virt-manager to display the virtual text console. In the guest console window, select Serial Console from the View menu.

34.9. Problemas comunes de Xen

Al intentar iniciar el servicio xend, no sucede nada. Escribe virsh list y recibe lo siguiente:
Error: Error connecting to xend: Connection refused. Is xend running?
Al intentar ejecutar xend start manualmente, recibe más errores:
Error: Could not obtain handle on privileged command interfaces (2 = No such file or directory)
Traceback (most recent call last:)
File "/usr/sbin/xend/", line 33 in ?
from xen.xend.server. import SrvDaemon
File "/usr/lib/python2.4/site-packages/xen/xend/server/SrvDaemon.py" , line 26 in ?
from xen.xend import XendDomain
File "/usr//lib/python2.4/site-packages/xen/xend/XendDomain.py" , line 33, in ?
		
from xen.xend import XendDomainInfo
File "/usr/lib/python2.4/site-packages/xen/xend/image.py" , line37, in ?
import images
File "/usr/lib/python2.4/site-packages/xen/xend/image.py" , line30, in ?
xc = xen.lowlevel.xc.xc ()
RuntimeError: (2, 'No such file or directory' )
Lo más probable es que reinició el host en un kernel diferente al kernel llamado kernel-xen. Para corregir este problema, debe seleccionar el kernel kernel-xen durante el arranque del sistema (o establecer el kernel kernel-xen como el kernel predeterminado en el archivo grub.conf ).

34.10. Errores durante la creación de huéspedes

Al intentar crear un huésped, recibe un mensaje de error "Invalid argument". Este mensaje generalmente indica que la imagen de kernel que está intentando arrancar, no es compatible con el hipervisor. Por ejemplo, este error podría producirse si está tratando de ejecutar un kernel FC5 no PAE en un hipervisor FC6 PAE.
Al recibir un nuevo kernel en una actualización con yum, grub.conf, utiliza el nuevo kernel de forma predeterminada y no el kernel virtualizado.
To correct this problem you must modify the default kernel RPM that resides in the /etc/sysconfig/kernel/ directory. You must ensure that kernel-xen parameter is set as the default option in your grub.conf file.

34.11. Detección y solución de problemas con consolas seriales

Los kernels de Linux pueden entregar información a puertos seriales. Esto sirve para depurar emergencias de hardware y problemas de hardware con dispositivos de vídeo o servidores sin cabeza. Las subpartes en esta sección cubren la configuración de la consola serial para máquinas que ejecutan kernels de virtualización de Red Hat Enterprise Linux y sus huéspedes virtualizados.

34.11.1. Salida de consola serial para Xen

By default, the serial console for the Xen hypervisor is disabled and no data is output from serial ports.
Para recibir información de kernel en un puerto serial, modifique el archivo /boot/grub/grub.conf estableciendo los parámetros apropiados de dispositivo serial.
Si su consola serial está en el puerto com1, modifique /boot/grub/grub.conf insertando las líneas com1=115200,8n1, console=tty0 y console=ttyS0,115200 donde se muestra.
title Red Hat Enterprise Linux 5 i386 Xen (2.6.18-92.el5xen)
	root (hd0, 8)
	kernel /boot/xen.gz-2.6.18-92.el5 com1=115200,8n1
	module /boot/vmlinuz-2.6.18-92.el5xen ro root=LABEL=VG_i386 console=tty0
				console=ttyS0,115200
	module /boot/initrd-2.6.18-92.el5xen.img
Si su consola serial está en com2, modifique /boot/grub/grub.conf insertando las líneas com2=115200,8n1 console=com2L, console=tty0 y console=ttyS0,115200 donde se muestra.
title Red Hat Enterprise Linux 5 i386 Xen (2.6.18-92.el5xen)
	root (hd0, 8)
	kernel /boot/xen.gz-2.6.18-92.el5 com2=115200,8n1 console=com2L
	module /boot/vmlinuz-2.6.18-92.el5xen ro root=LABEL=VG_i386 console=tty0
	console=ttyS0,115200
	module /boot/initrd-2.6.18-92.el5xen.img
Guarde los cambios y reinicie el host. Las salidas del hipervisor en la serial (com1, com2 y así sucesivamente) que seleccionó en el paso anterior.
Observe el ejemplo que utiliza el puerto com2, el parámetro console=ttyS0 en la línea vmlinuz es utilizado. La conducta de cada puerto utilizado comoconsole=ttyS0 no es una conducta estándar de Linux, sino específica del entorno Xen.

34.11.2. Salida de consola serial de Xen de los huéspedes para-virtualizados

Esta sección describe cómo configurar una consola serial virtualizada para huéspedes para-virtualizados de Red Hat Enterprise Linux.
La salida de la consola serial de los huéspedes para-virtualizados puede obtenerse mediante "virsh console" o en la ventana "Consola serial" de virt-manager. Configure la consola serial virtual con este procedimiento:
  1. Ingrese a su huésped para-virtualizado.
  2. Edite /boot/grub/grub.conf así:
    Red Hat Enterprise Linux 5 i386 Xen (2.6.18-92.el5xen)
    	root (hd0, 0) kernel /boot/vmlinuz-2.6.18-92.el5xen ro root=LABEL=VG_i386 console=xvc0 
    	initrd /boot/initrd-2.6.18-92.el5xen.img
    
  3. Reinicie el huésped para-virtualizado.
Debe obtener mensajes de kernel en "Serial Console" y "virsh console" de virt-manager.
Registro de la salida de la consola serial de dominio para-virtualizado
El demonio Xen (xend) puede ser configurado para registrar salida de las consolas seriales de huéspedes para-virtualizados.
Para configurar xend edite /etc/sysconfig/xend. Cambie la entrada:
# Log all guest console output (cf xm console)
#XENCONSOLED_LOG_GUESTS=no
to:
# Log all guest console output (cf xm console)
XENCONSOLED_LOG_GUESTS=yes
Reinicie el host para activar el registro de la salida de la consola serial del huésped.
Los registros de las consolas seriales del huésped se almacenan en el archivo /var/log/xen/console.

34.11.3. Salida de consola serial desde huéspedes completamente virtualizados

Esta sección describe la forma de habilitar la consola serial para huéspedes completamente virtualizados.
La consola serial de huéspedes completamente virtualizados puede ser vista con el comando"virsh console".
Tenga en cuenta que las consolas seriales de huéspedes completamente virtualizados tienen sus limitaciones. Las limitaciones actuales incluyen:
  • el registro de salida con xend no está disponible.
  • los datos de salida pueden ser omitidos o codificados
El puerto serial se denomina ttyS0 en Linux o COM1 en Windows.
Debe configurar el sistema operativo virtualizado para entregar información al puerto serial virtual.
Para entregar información de kernel desde un huésped de Linux completamente virtualizado dentro del dominio, modifique el archivo /boot/grub/grub.conf insertando la línea "console=tty0 console=ttys0,115200".
title Red Hat Enterprise Linux Server (2.6.18-92.el5)
	root (hd0,0)
	kernel /vmlinuz-2.6.18-92.el5 ro root=/dev/volgroup00/logvol00
	console=tty0 console=ttys0,115200
	initrd /initrd-2.6.18-92.el5.img
Reinicie el huésped.
Vea los mensajes de consola serial con el comando "virsh console".

Nota

Los mensajes de consola serial desde dominios completamente virtualizados, no se registran en /var/log/xen/console porque son huéspedes para-virtualizados.

34.12. Archivos de configuración Xen

When you create guests with the virt-manager or virt-install tools on Red Hat Enterprise Linux 5, the guests configuration files are created automatically in the /etc/xen directory.

Warning

Red Hat advises users not to manually edit Xen configuration files. Xen configuration files have limited error checking and many unsupported variables. Editing Xen configuration files may damage your guests, make guests unbootable or cause data loss.
The example below is a typical a para-virtualized guest configuration file:
name = "rhel5vm01"
memory = "2048"
disk = ['tap:aio:/var/lib/libvirt/images/rhel5vm01.dsk,xvda,w',]
vif = ["type=ieomu, mac=00:16:3e:09:f0:12 bridge=xenbr0', 
"type=ieomu, mac=00:16:3e:09:f0:13 ]
vnc = 1
vncunused = 1
uuid = "302bd9ce-4f60-fc67-9e40-7a77d9b4e1ed"
bootloader = "/usr/bin/pygrub"
vcpus=2
on_reboot = "restart"
on_crash = "restart"
Observe que serial="pty" es el valor predeterminado para el archivo de configuración. El siguiente ejemplo es un archivo de configuración de un huésped completamente virtualizado:
name = "rhel5u5-86_64"
builder = "hvm"
memory = 500
disk = ['/var/lib/libvirt/images/rhel5u5-x86_64.dsk.hda,w']
vif = [ 'type=ioemu, mac=00:16:3e:09:f0:12, bridge=xenbr0', 'type=ieomu, mac=00:16:3e:09:f0:13, bridge=xenbr1']
uuid = "b10372f9-91d7-ao5f-12ff-372100c99af5'
device_model = "/usr/lib64/xen/bin/qemu-dm"
kernel = "/usr/lib/xen/boot/hvmloader/"
vnc = 1
vncunused = 1
apic = 1
acpi = 1
pae = 1
vcpus =1
serial ="pty" # enable serial console
on_boot = 'restart'

Archivos de configuración Xen

La edición de archivos de configuración Xen no es soportada. Utilice virsh dumpxml y virsh create (o virsh edit) para editar los archivos de configuración libvirt (basados en XML), los cuales tienen comprobación de errores y controles de seguridad.

34.13. Interpretación de mensajes de error Xen

Si recibe el siguiente error:
failed domain creation due to memory shortage, unable to balloon domain0
Un dominio puede fallar si no hay suficiente RAM disponible. Domain0 no se contrae lo suficiente para proporcionar espacio al nuevo huésped. Puede revisar el archivo xend.log para este error:
[2006-12-21] 20:33:31 xend 3198] DEBUG (balloon:133) Balloon: 558432 Kib free; 0 to scrub; need 1048576; retries: 20
[2006-12-21] 20:33:31 xend. XendDomainInfo 3198] ERROR (XendDomainInfo: 202
Domain construction failed
Puede revisar la cantidad de memoria usada por domain0 mediante el comando xm list domain0.Si dom0 no se contrae lo suficiente, puede utilizar el comando virsh setmem dom0 NewMemSize para comprobar la memoria.
Si recibe el siguiente error:
wrong kernel image: non-PAE kernel on a PAE
Este mensaje indica que está tratando de ejecutar una imagen de kernel huésped no soportada en el hipervisor. Esto sucede cuando intenta arrancar un kernel huésped para-virtualizado no PAE en un host de Red Hat Enterprise Linux 5. El paquete de Red Hat kernel-xen, sólo soporta kernel de huéspedes con PAE y con arquitecturas de 64 bits.
Escriba este comando:
# xm create -c va-base

Using config file "va-base"
Error: (22, 'invalid argument')
[2006-12-14 14:55:46 xend.XendDomainInfo 3874] ERRORs
(XendDomainInfo:202) Domain construction failed

Traceback (most recent call last)
File "/usr/lib/python2.4/site-packages/xen/xend/XendDomainInfo.py", line 195 in create vm.initDomain()
File " /usr/lib/python2.4/site-packages/xen/xend/XendDomainInfo.py", line 1363 in initDomain raise VmError(str(exn))
VmError: (22, 'Invalid argument')
[2006-12-14 14:55:46 xend.XendDomainInfo 3874] DEBUG (XenDomainInfo: 1449]
XendDlomainInfo.destroy: domain=1
[2006-12-14 14:55:46 xend.XendDomainInfo 3874] DEBUG (XenDomainInfo: 1457]
XendDlomainInfo.destroy:Domain(1)
Si necesita ejecutar un kernel no PAE de 32 bits, deberá ejecutar su huésped como una máquina virtual completamente virtualizada. Si necesita ejecutar un huésped PAE de 32 bits, para huésped para-virtualizados, deberá tener un hipervisor PAE de 32 bits. Para huéspedes para-virtualizados, que se ejecuten en un huésped PAE de 64 bits, deberá tener un hipervisor PAE de 64-bits. Para huéspedes completamente virtualizados deberá ejecutar un huésped de 64bits con un hipervisor de 64-bits. El hipervisor PAE de 32 bits que viene con Red Hat Enterprise Linux 5 i686, sólo permite la ejecución de huéspedes para-virtualizados de 32 bits para huéspedes de sistemas operativos completamente virtualizados de 32bits. El hipervisor de 64bits sólo permite huéspedes para-virtualizados de 64-bits.
Esto sucede cuando desplaza un huésped HVM completamente virtualizado a un sistema de Red Hat Enterprise Linux 5. Su huésped podría no arrancar y un mensaje de error aparecerá en la pantalla de la consola. Revise la entrada PAE en su archivo de configuración y asegúrese de que PAE tenga un valor de 1 (pae=1). Debe utilizar una distribución de 32bits.
Si recibe el siguiente error:
Unable to open a connection to the Xen hypervisor or daemon
Esto sucede cuando la aplicación virt-manager no puede ser ejecutada. Este error ocurre cuando no hay una entrada de host local en el archivo de configuración /etc/hosts. Revise el archivo y verifique si la entrada del host local está activada. A continuación se da un ejemplo de una entrada de host local incorrecta:
# Do not remove the following line, or various programs
# that require network functionality will fail.
localhost.localdomain localhost
A continuación se muestra un ejemplo de una entrada del host local correcta:
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 localhost.localdomain localhost
localhost.localdomain. localhost
Si recibe el siguiente error (en el archivo xen-xend.logfile):
Bridge xenbr1 does not exist!
This happens when the guest's bridge is incorrectly configured and this forces the Xen hotplug scripts to timeout. If you move configuration files between hosts, you must ensure that you update the guest configuration files to reflect network topology and configuration modifications. When you attempt to start a guest that has an incorrect or non-existent Xen bridge configuration, you will receive the following errors:
# xm create mySQL01

Using config file " mySQL01"
Going to boot Red Hat Enterprise Linux Server (2.6.18.-1.2747 .el5xen)
kernel: /vmlinuz-2.6.18-12747.el5xen
initrd: /initrd-2.6.18-1.2747.el5xen.img
Error: Device 0 (vif) could not be connected. Hotplug scripts not working.
Además, xend.log despliega los siguientes errores:
[2006-11-14 15:07:08 xend 3875] DEBUG (DevController:143) Waiting for devices vif
[2006-11-14 15:07:08 xend 3875] DEBUG (DevController:149) Waiting for 0
[2006-11-14 15:07:08 xend 3875] DEBUG (DevController:464) hotplugStatusCallback

/local/domain/0/backend/vif/2/0/hotplug-status

[2006-11-14 15:08:09 xend.XendDomainInfo 3875] DEBUG (XendDomainInfo:1449) XendDomainInfo.destroy: domid=2
[2006-11-14 15:08:09 xend.XendDomainInfo 3875] DEBUG (XendDomainInfo:1457) XendDomainInfo.destroyDomain(2)
[2006-11-14 15:07:08 xend 3875] DEBUG (DevController:464) hotplugStatusCallback

/local/domain/0/backend/vif/2/0/hotplug-status
To resolve this problem, open the guest's configuration file found in the /etc/xen directory. For example, editing the guest mySQL01
# vim /etc/xen/mySQL01
Locate the vif entry. Assuming you are using xenbr0 as the default bridge, the proper entry should resemble the following:
# vif = ['mac=00:16:3e:49:1d:11, bridge=xenbr0',]
Usted recibe estos errores de depreciación de Python:
# xm shutdown win2k3xen12
# xm create win2k3xen12

Using config file "win2k3xen12".

/usr/lib64/python2.4/site-packages/xenxm/opts.py:520: Deprecation Warning:
Non ASCII character '\xc0' in file win2k3xen12 on line 1, but no encoding
declared; see http://www.python.org/peps/pep-0263.html for details

execfile (defconfig, globs, locs,)
Error: invalid syntax 9win2k3xen12, line1)
Python genera estos mensajes cuando hay un archivo de configuración in+++válido o incorrecto. Para resolver este problema debe modificar el archivo de configuración incorrecto o generar uno nuevo.

34.14. Presentación de los directorios de registro

La estructura de directorio básico en un entorno de virtualización de Red Hat Enterprise Linux 5 es la siguiente:
El directorio /etc/xen/ contiene
  • Los archivos de configuración utilizados por el demonio xend.
  • El directorio scripts que contiene los scripts para redes de virtualización.
/var/log/xen/
  • Directorio que guarda todos los archivos de registro relacionados con Xen
/var/lib/libvirt/images/
  • El directorio predeterminado para archivos de imagen de máquinas virtuales.
  • Si está utilizando un directorio diferente para sus imágenes de máquina virtual, asegúrese de adicionar el directorio a su política de SELinux y de etiquetarla antes de iniciar la instalación.
/proc/xen/
  • La información relacionada de Xen en el sistema de archivos /proc.

Capítulo 35. Solución de problemas

Este capítulo cubre problemas y soluciones comunes con virtualización de Red Hat Enterprise Linux.

35.1. Identificar almacenamiento disponible y particiones

Verificar que el dispositivo de bloque esté cargado y que los dispositivos y particiones estén disponibles para el huésped. Esto se puede realizar al ejecutar "cat /proc/partitions" como se muestra a continuación.
# cat /proc/partitions
major minor  #blocks   name 
 202    16  104857600  xvdb
   3     0    8175688  hda

35.2. Después de reiniciar los huéspedes basados en Xen la consola se congela

Occasionally, a Xen guest's console freezes when the guest boots. The console still displays messages but the user cannot log in.
Para corregir este problema añada la siguiente línea al archivo /etc/inittab:
1:12345:respawn:/sbin/mingetty xvc0
Después de guardar el archivo, reinicie. La sesión de consola ahora es interactiva como se esperaba.

35.3. Los dispositivos Ethernet virtualizados no se encuentran mediante herramientas de red

Las herramientas de redes no pueden identificar la tarjeta de red Xen Virtual Ethernet dentro del sistema operativo. Verifíquelo ejecutando lo siguiente (para Red Hat Enterprise Linux 4 y Red Hat Enterprise Linux 5):
cat /etc/modprobe.conf
O (para Red Hat Enterprise Linux 3):
cat /etc/modules.conf
La salida debe contener la línea y una línea similar para cada interfaz adicional.
alias eth0 xen-vnif
Para corregir este problema necesitará añadir las líneas (por ejemplo, alias eth0 xen-vnif) para cada interfaz para-virtualizada para el huésped.

35.4. Errores del dispositivo en bucle

Si se utilizan las imágenes de huéspedes basadas en archivos, se deberá aumentar el número de dispositivos de bucle configurados. La configuración predeterminada permite hasta 8 dispositivos de bucle activos. Si se necesitan más de 8 huéspedes basados en archivos o dispositivos de bucle, se puede ajustar el número de dispositivos de bucle configurados en /etc/modprobe.conf. Edite el archivo /etc/modprobe.conf y añádale la siguiente línea:
                options loop max_loop=64
Este ejemplo utiliza 64 pero se puede especificar otro número como el máximo valor de bucle. También tendrá que implementar huéspedes respaldados por dispositivos de bucle en su sistema. Para emplear huéspedes de dispositivo de bucle para un huésped para-virtualizado, utilice los comandos phy: block device o tap:aio. Para emplear huéspedes respaldados de dispositivo de bucle para un sistema completamente virtualizado, utilice los comandos phy: device o file: file.

35.5. Falló la creación de dominio por escasez de memoria

This may cause a domain to fail to start. The reason for this is there is not enough memory available or dom0 has not ballooned down enough to provide space for a recently created or started guest. In your /var/log/xen/xend.log, an example error message indicating this has occurred:
[2006-11-21 20:33:31 xend 3198] DEBUG (balloon:133) Balloon: 558432 KiB free;
	0 to scrub; need 1048576; retries: 20.
[2006-11-21 20:33:52 xend.XendDomainInfo 3198] ERROR (XendDomainInfo:202) Domain construction failed
You can verify the amount of memory currently used by dom0 with the command “xm list Domain-0”. If dom0 is not ballooned down you can use the command “xm mem-set Domain-0 NewMemSize” where NewMemSize should be a smaller value.

35.6. Wrong kernel image error

Los huéspedes para-virtualizados no pueden usar el kernel-Xen de kernel. Use sólo el kernel estándar para huéspedes para-virtualizados.
Attempting to boot any kernel other than the Xen kernel as a para-virtualized guest results in the following error message:
# xm create testVM
Using config file "./testVM".
Going to boot Red Hat Enterprise Linux Server (2.6.18-1.2839.el5)
kernel: /vmlinuz-2.6.18-1.2839.el5
initrd: /initrd-2.6.18-1.2839.el5.img
Error: (22, 'Invalid argument')
In the above error you can see that the kernel line shows that the system is trying to boot a non kernel-xen kernel. The correct entry in the example is ”kernel: /vmlinuz-2.6.18-1.2839.el5xen”.
La solución es verificar si ha instalado de verdad un kernel-xen en su huésped y si es el kernel predeterminado para arrancar en su archivo de configuración /etc/grub.conf.
Si tiene instalado kernel-xen en su huésped, puede iniciar su huésped:
xm create -c GuestName
Where GuestName is the name of the guest. The previous command will present you with the GRUB boot loader screen and allow you to select the kernel to boot. You will have to choose the kernel-xen kernel to boot. Once the guest has completed the boot process you can log into the guest and edit /etc/grub.conf to change the default boot kernel to your kernel-xen. Simply change the line “default=X” (where X is a number starting at '0') to correspond to the entry with your kernel-xen line. The numbering starts at '0' so if your kernel-xen entry is the second entry you would enter '1' as the default,for example “default=1”.

35.7. Wrong kernel image error - non-PAE kernel on a PAE platform

If you to boot a non-PAE kernel, para-virtualized guest the error message below will display. It indicates you are trying to run a guest kernel on your Hypervisor which at this time is not supported. The Xen hypervisor presently only supports PAE and 64 bit para-virtualized guest kernels.
# xm create -c va-base 
Using config file "va-base".
Error: (22, 'Invalid argument')
[2006-12-14 14:55:46 xend.XendDomainInfo 3874] ERROR (XendDomainInfo:202) Domain construction failed
Traceback (most recent call last):
File "/usr/lib/python2.4/site-packages/xen/xend/XendDomainInfo.py", 
	line 195, in  create vm.initDomain()
File "/usr/lib/python2.4/site-packages/xen/xend/XendDomainInfo.py", 
	line 1363, in initDomain raise VmError(str(exn))
VmError: (22, 'Invalid argument')
[2006-12-14 14:55:46 xend.XendDomainInfo 3874] DEBUG (XendDomainInfo:1449) XendDomainInfo.destroy: domid=1
[2006-12-14 14:55:46 xend.XendDomainInfo 3874] DEBUG (XendDomainInfo:1457) XendDomainInfo.destroyDomain(1)
If you need to run a 32 bit or non-PAE kernel you will need to run your guest as a fully-virtualized virtual machine. The rules for hypervisor compatibility are:
  • Los huéspedes para-virtualizados deben coincidir con el tipo de arquitectura de su hipervisor. Para ejecutar un huésped PAE de 32 bits, debe tener un hipervisor PAE de 32 bits.
  • Para ejecutar un huésped para-virtualizado de 64 bits, también debe tener una versión de hipervisor de 64 bits.
  • Para los huéspedes completamente virtualizados su hipervisor debe tener 32 bits o 64 bits para huéspedes de 32 bits. Se puede ejecutar un huésped (PAE y non-PAE) de 32 bits en un hipervisor de 32 o 64 bits.
  • Para ejecutar un huésped completamente virtualizado de 64 bits, su hipervisor debe ser también de 64 bits.

35.8. El huésped completamente virtualizado falla en el arranque

If you have moved the configuration file to a Red Hat Enterprise Linux 5 causing your fully-virtualized guest to fail to boot and present the error, Your CPU does not support long mode. Use a 32 bit distribution. This problem is caused by a missing or incorrect pae setting. Ensure you have an entry “pae=1” in your guest's configuration file.

35.9. Una entrada de host local faltante hace que el virt-manager falle

La aplicación virt-manager puede fallar en el lanzamiento y desplegar un error tal como: “Unable to open a connection to the Xen hypervisor/daemon”. Esto suele deberse a la falta de una entrada localhost en el archivo /etc/hosts. Verifique si en realidad se tiene una entrada localhost o si falta en /etc/hosts e inserte una nueva entrada para localhost si no está presente. Un archivo incorrecto de /etc/hosts puede parecerse a lo siguiente:
# Do not remove the following line, or various programs
# that require network functionality will fail.
localhost.localdomain localhost
La entrada correcta debe ser similar a la siguiente:
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1               localhost.localdomain localhost
localhost.localdomain localhost

35.10. Error de microcódigo durante el arranque de huésped.

During the boot phase of your virtual machine you may see an error message similar to:
Applying Intel CPU microcode update: FATAL: Module microcode not found.
ERROR: Module microcode does not exist in /proc/modules
As the virtual machine is running on virtual CPUs there is no point updating the microcode. Disabling the microcode update for your virtual machines will stop this error:
/sbin/service microcode_ctl stop
/sbin/chkconfig --del microcode_ctl

35.11. Mensajes de advertencia de depreciación de Python al inicio de una máquina virtual

Algunas veces, Python generará mensajes como el que aparece abajo, estos mensajes se presentan cuando hay un archivo de configuración inválido o incorrecto. Un archivo de configuración con caracteres no-ascii causará estos errores. Para resolver este problema se debe corregir el archivo de configuración o generar uno nuevo.
Otra causa es un archivo de configuración incorrecto en su directorio de trabajo actual. El comando “xm create” buscará un archivo de configuración en el directorio actual y luego en /etc/xen
# xm shutdown win2k3xen12
# xm create win2k3xen12
Using config file "win2k3xen12".
/usr/lib64/python2.4/site-packages/xen/xm/opts.py:520: DeprecationWarning:
Non-ASCII character '\xc0' in file win2k3xen12 on line 1, but no encoding
declared; see http://www.python.org/peps/pep-0263.html for details
execfile(defconfig, globs, locs)
Error: invalid syntax (win2k3xen12, line 1)

35.12. Habilitando las extensiones de virtualización de hardware Intel VT y AMD-V en BIOS

Esta sección describe cómo identificar extensiones de virtualización de hardware y cómo habilitarlas en su BIOS si están desactivadas.
Las extensiones Intel VT pueden ser inhabilitadas en el BIOS. Algunos proveedores de portátiles han inhabilitado de forma predeterminada extensiones de Intel VT en sus CPU.
Las extensiones de virtualización no pueden desactivarse en el BIOS para AMD-V.
The virtualization extensions are sometimes disabled in BIOS, usually by laptop manufacturers. Refer to Sección 35.12, “Habilitando las extensiones de virtualización de hardware Intel VT y AMD-V en BIOS” for instructions on enabling disabled virtualization extensions.
Verifique las extensiones de virtualización que están habilitadas en BIOS. Las configuraciones de BIOS para Intel® VT o AMD-V suelen estar en los menús Chipset o Procesador. Los nombres de menú pueden variar en esta guía, las configuraciones de extensión de virtualización se pueden encontrar en Configuración de seguridad u otros nombres usuales de menú.
Procedimiento 35.1. Habilitar extensiones de virtualización en BIOS
  1. Reboot the computer and open the system's BIOS menu. This can usually be done by pressing the delete key, the F1 key or Alt and F4 keys depending on the system.
  2. Select Restore Defaults or Restore Optimized Defaults, and then select Save & Exit.
  3. Apague la máquina y desconecte la fuente de energía.
  4. Enabling the virtualization extensions in BIOS

    Note: BIOS steps

    Many of the steps below may vary depending on your motherboard, processor type, chipset and OEM. Refer to your system's accompanying documentation for the correct information on configuring your system.
    1. Power on the machine and open the BIOS (as per Step 1).
    2. Open the Processor submenu The processor settings menu may be hidden in the Chipset, Advanced CPU Configuration or Northbridge.
    3. Enable Intel Virtualization Technology (also known as Intel VT) or AMD-V depending on the brand of the processor. The virtualization extensions may be labeled Virtualization Extensions, Vanderpool or various other names depending on the OEM and system BIOS.
    4. Enable Intel VTd or AMD IOMMU, if the options are available. Intel VTd and AMD IOMMU are used for PCI passthrough.
    5. Select Save & Exit.
  5. Apague la máquina y desconecte la fuente de energía.
  6. Ejecute cat /proc/cpuinfo | grep vmx svm. Si el comando entrega salida, las extensiones de virtualización ahora están habilitadas. Si no hay salida, puede que su sistema no tenga extensiones de virtualización o la correcta configuración de BIOS habilitada.

35.13. Rendimiento de redes KVM

Por defecto, las máquinas virtuales de KVM son asignadas a virtual Realtek 8139 (rtl8139) NIC (controlador de interfaz de red).
El NIC virtualizado rtl8139 funciona bien en la mayoría de los entornos. Sin embargo, este dispositivo puede sufrir problemas de degradación de rendimiento en algunas redes, por ejemplo, una red Ethernet de 10 GB. for example, a 10 Gigabit Ethernet network.
Una solución es cambiar a un tipo diferente de NIC virtualizado. Por ejemplo, Intel PRO/1000 (e1000) o virtio (el controlador de red para-virtualizado).
Para cambiar al controlador e1000:
  1. Apague el sistema operativo de huésped.
  2. Edit the guest's configuration file with the virsh command (where GUEST is the guest's name):
    # virsh edit GUEST
    El comando virsh edit utiliza la variable de shell $EDITOR para determinar el editor a utilizar.
  3. Busque la sección de interfaz de redes de la configuración. Esta sección es una pequeña muestra:
    <interface type='network'>
      [output truncated]
      <model type='rtl8139' />
    </interface>
    
  4. Change the type attribute of the model element from 'rtl8139' to 'e1000'. This will change the driver from the rtl8139 driver to the e1000 driver.
    <interface type='network'>
      [output truncated]
      <model type='e1000' />
    </interface>
    
  5. Guarde los cambios y salga del editor de texto
  6. Reinicie el sistema operativo de huésped.
Asimismo, puede instalar nuevos huéspedes virtualizados con un controlador de redes diferente. Esto se puede requerir si se está teniendo dificultades en la instalación de huéspedes en una conexión de red. Este método requiere que usted tenga por lo menos una máquina virtual ya creada (posiblemente instalada desde un CD o DVD) para usar como plantilla.
  1. Cree una plantilla XML desde una máquina virtual existente:
    # virsh dumpxml GUEST > /tmp/guest.xml
    
  2. Copie y edite el archivo XML y actualice los campos únicos: nombre de la máquina virtual, UUID, imagen de disco, dirección MAC, y cualquier otro parámetro único. Observe que usted puede borrar las líneas del UUID y la dirección MAC y virsh generará una dirección UUID y MAC .
    # cp /tmp/guest.xml /tmp/new-guest.xml
    # vi /tmp/new-guest.xml
    
    Añada la línea modelo en la sección de interfaz de red:
     <interface type='network'>
      [output truncated]
      <model type='e1000' />
    </interface>
    
  3. Cree la nueva máquina virtual:
    # virsh define /tmp/new-guest.xml
    # virsh start new-guest
    
El rendimiento de red debe ser mejor que con el controlador e1000 o virtio. (BZ#517181)

Capítulo 36. Detección y solución de errores de los controladores de para-virtualización.

Este capítulo se ocupa de problemas que pueden surgir con hosts de Xen y huéspedes de Red Hat Enterprise Linux completamente virtualizadas utilizando los controladores para-virtualizados.

36.1. Directorios y archivo de registro de virtualización de Red Hat Enterprise Linux 5

/var/log/xen/
El directorio con y todo el archivo generado por el demonio xend y el proceso qemu-dm.
xend.log
  • Este archivo de registro es utilizado por Xen para registrar los eventos generados por el sistema o los generados por el operador.
  • la máquina virtual de operaciones tales como crear, apagado, destruir etc, son todos los que están en este archivo de registro.
  • Normalmente este archivo de registro será el primer lugar en donde mirar en caso de algún problema. En muchos casos se podrá identificar el origen del problema haciendo un análisis y revisando las entradas registradas justo antes del mensaje de error.
xend-debug.log
  • Eventos de registros de error de Xend y sus subsistemas (desde el marco de buffer y los scripts de Python)
xen-hotplug.log
  • Eventos de registros de error desde eventos hotplug.
  • Las notificaciones de eventos de dispositivos que no entran en línea o en puentes de red desconectados se registran en este archivo.
qemu-dm.PID.log
  • Este archivo fue creado por el proceso qemu-dm el cual se inició para cada huésped completamente virtualizado.
  • El PID es remplazado por el PID del proceso de un proceso relacionado con qemu-dm
  • Se puede recuperar el PID para un proceso determinado qemu-dm mediante el comando ps y al buscar en los argumentos del proceso se puede identificar la máquina virtual a la que pertenece el proceso qemu-dm.
If you are troubleshooting a problem with the virt-manager application you can also review the logfile generated by it. The logfile for virt-manager will be in a directory called .virt-manager in the user's home directory whom ran virt-manager. This directory will usually be ~/.virt-manager/virt-manager.

Nota

El registro de archivo es sobrescrito cada vez que se inicia virt-manager. Si está detectando un problema con virt-manager, asegúrese de guardar el archivo de registro antes de iniciar virt-manager después de que haya ocurrido un error.
/var/lib/libvirt/images/
El directorio estándar para imágenes de huésped basadas en archivos.
/var/lib/xen/xend-db/
El directorio que guarda la base de datos de Xend, la cual es generada cada vez que se inicia el demonio.
/etc/xen/
Almacena un número de archivos de configuración para el hipervisor de Xen.
  • /etc/xen/xend-config.sxp es la configuración principal para el demonio Xend. El archivo xend-config.sxp habilita o inhabilita la migración y otras funciones no configuradas por libvirt. Utilice las herramientas libvirt para todas las demás funciones.
/var/lib/xen/dump/
Guarda descargas generadas por máquinas virtuales o cuando se utiliza el comando xm dump-core.
/proc/xen/
Almacena la información de xen-kernel en los siguientes archivos:
  • /proc/xen/capabilities
  • /proc/xen/privcmd
  • /proc/xen/balloon
  • /proc/xen/xenbus
  • /proc/xen/xsd_port
  • /proc/xen/xsd_kva

36.2. Huésped para-virtualizado falla al cargar en un sistema operativo de huésped Red Hat Enterprise Linux 3

Red Hat Enterprise Linux 3 utiliza RPM de kernel específico de arquitectura de procesador y por este motivo los controladores para-virtualizados pueden fallar al cargar si el RPM del controlador para-virtualizado no coincide con la arquitectura del kernel.
When the para-virtualized driver modules are inserted, a long list of unresolved modules will be displayed. A shortened excerpt of the error can be seen below.
# insmod xen-platform-pci.o 
Warning: kernel-module version mismatch
xen-platform-pci.o was compiled for kernel version 2.4.21-52.EL
while this kernel is version 2.4.21-50.EL
xen-platform-pci.o: unresolved symbol __ioremap_R9eac042a
xen-platform-pci.o: unresolved symbol flush_signals_R50973be2
xen-platform-pci.o: unresolved symbol pci_read_config_byte_R0e425a9e
xen-platform-pci.o: unresolved symbol __get_free_pages_R9016dd82
[...]
The solution is to use the correct RPM package for your hardware architecture for the para-virtualized drivers.

36.3. Se muestra un mensaje de advertencia durante la instalación de los controladores para-virtualizados en Red Hat Enterprise Linux 3

La instalación de los controladores para-virtualizados en un kernel de Red Hat Enterprise Linux 3 anteriores a 2.4.21-52, puede resultar en un mensaje de advertencia indicando los módulos se han recopilado con una versión más reciente que la del kernel en ejecución.
Este mensaje, como se muestra a continuación, puede ignorarse.
Warning: kernel-module version mismatch
xen-platform-pci.o was compiled for kernel version 2.4.21-52.EL
while this kernel is version 2.4.21-50.EL
Warning: loading xen-platform-pci.o will taint the kernel: forced load
See http://www.tux.org/lkml/#export-tainted for information about tainted modules
Module xen-platform-pci loaded, with warnings
La parte importante del mensaje anterior es la última línea que debería declarar que el módulo se ha cargado con advertencias.

36.4. Cargar manualmente los controladores para- virtualizados

Si por alguna razón los controladores para-virtualizados no se pueden cargar automáticamente durante el proceso de arranque, puede intentar cargarlos de manualmente.
Esto le permitirá reconfigurar las entidades de red o almacenamiento de información o identificar la razón por la cual no se pudo cargar en primer lugar. Los siguientes pasos deben cargar los módulos del controlador para-virtualizado.
En primer lugar, ubique los módulos del controlador para-virtualizado en su sistema.
# cd /lib/modules/`uname -r`/
# find . -name 'xen_*.ko' -print
Tome nota de la ubicación y cargue el módulo manualmente. Sustituya {LocationofPV-drivers} por la ubicación correcta que anotó de la salida de los comandos anteriores.
# insmod \
/lib/modules/'uname -r'/{LocationofPV-drivers}/xen_platform_pci.ko
# insmod /lib/modules/'uname -r'/{LocationofPV-drivers}/xen_balloon.ko
# insmod /lib/modules/'uname -r'/{LocationofPV-drivers}/xen_vnif.ko
# insmod /lib/modules/'uname -r'/{LocationofPV-drivers}/xen_vbd.ko

36.5. Verificación de los controladores para-virtualizados cargados correctamente

Una de las primeras tareas que tendrá que hacer es comprobar que los controladores realmente se hayan cargado en su sistema.
After the para-virtualized drivers have been installed and the guest has been rebooted you can verify that the drivers have loaded. First you should confirm the drivers have logged their loading into /var/log/messages
# grep -E "vif|vbd|xen" /var/log/messages
                    xen_mem: Initialising balloon driver
                    vif vif-0: 2 parsing device/vif/0/mac
                    vbd vbd-768: 19 xlvbd_add at /local/domain/0/backend/vbd/21/76
                    vbd vbd-768: 19 xlvbd_add at /local/domain/0/backend/vbd/21/76
                    xen-vbd: registered block device major 202
You can also use the lsmod command to list the loaded para-virtualized drivers. It should output a list containing the xen_vnif, xen_vbd, xen_platform_pci and xen_balloon modules.
# lsmod|grep xen
xen_vbd                19168  1 
xen_vnif               28416  0 
xen_balloon            15256  1 xen_vnif
xen_platform_pci       98520  3 xen_vbd,xen_vnif,xen_balloon,[permanent]

36.6. El sistema tiene rendimiento limitado con controladores para-virtualizados

If network throughput is still limited even after installing the para-virtualized drivers and you have confirmed they are loaded correctly (refer to Sección 36.5, “Verificación de los controladores para-virtualizados cargados correctamente”). To fix this problem, remove the 'type=ioemu' part of 'vif=' line in your guest's configuration file.

Glossary

Este glosario tiene como objeto definir los términos que se utilizan en este Manual de instalación.
Bare-metal
The term bare-metal refers to the underlying physical architecture of a computer. Running an operating system on bare-metal is another way of referring to running an unmodified version of the operating system on the physical hardware. Examples of operating systems running on bare metal are dom0 or a normally installed operating system.
Completamente virtualizado
See Full virtualization.
Controladores para-virtualizados
Los controladores para-virtualizados son controladores de dispositivo que operan en huéspedes de Linux completamente virtualizados. Estos controladores aumentan ampliamente el rendimiento de red y la E/S de dispositivo de bloque para huéspedes completamente virtualizados.
Direcciones MAC
La dirección de Control de acceso de medios es la dirección de hardware para el controlador de interfaz de red. En el contexto de virtualización las direcciones se deben generar para interfaces de red virtuales con cada MAC en su dominio local único.
dom0
Also known as the host or host operating system.
dom0 refers to the host instance of Red Hat Enterprise Linux running the Xen hypervisor. Domain0 facilitates virtualized devices and virtualization for the guest operating systems. Dom0 runs on and manages the physical hardware and resource allocation for itself and the guest operating systems.
Domains
domU and dom0 are both domains. A domain is a term for a guest or virtual machine on the Xen hypervisor. The term domains has a similar meaning to virtual machines and the two are technically interchangeable.
domU
domU refers to the guest operating systems which run on the host system (the dom0 domain).
Hardware Virtual Machine
See Full virtualization.
Hipervisor
The hypervisor is the software layer that abstracts the hardware from the operating system permitting multiple operating systems to run on the same hardware. The hypervisor runs on a host operating system allowing other virtualized operating systems to run on the host's hardware.
The Kernel-based Virtual Machine (KVM) and Xen) hypervisors are provided with Red Hat Enterprise Linux 5.
Host
The host operating system, also known as dom0.
The host operating system environment runs the virtualization software for Fully Virtualized and Para virtualized guest systems.
I/O
Abreviatura de entrada/salida. El término E/S describe cualquier programa, operación o dispositivo que transfiera datos desde o hacia un computador y desde o hacia un dispositivo periférico. Cada transferencia es una salida desde un dispositivo y una entrada a otra. Los dispositivos tales como los teclados y los ratones son dispositivos de sólo entrada mientras que los dispositivos tales como las impresoras son de sólo salida. Un CD-ROM de escritura es un dispositivo de entrada como de salida.
Itanium®
La arquitectura del procesador Intel Itanium®.
Kernel SamePage Merging
El módulo Kernel SamePage Merging (KSM) es utilizado por el hipervisor de KVM para permitir a los huéspedes de KVM compartir las páginas de memoria idénticas. Las páginas compartidas suelen ser las bibliotecas comunes u otras idénticas y los datos de alto uso. KSM puede aumentar el rendimiento de algunos huéspedes, manteniendo las bibliotecas en memoria cache para varios huéspedes como también, aumentando la densidad de huéspedes.
Kernel-based Virtual Machine
KVM (Kernel-based Virtual Machine) is a Full virtualization solution for Linux on AMD64 and Intel 64 hardware. VM is a Linux kernel module built for the standard Red Hat Enterprise Linux kernel. KVM can run multiple, unmodified virtualized guest Windows and Linux operating systems. KVM is a hypervisor which uses the libvirt virtualization tools (virt-manager and virsh).
KVM es una serie de módulos de kernel de Linux que administran dispositivos, memoria y el manejo de las API para el módulo mismo del hipervisor. Los huéspedes virtualizados se ejecutan como procesos e hilos de Linux que son controlados por dichos módulos.
LUN
Un número de unidad lógica (LUN) del inglés Logical Unit Number es un número asignado a una unidad lógica (una entidad de protocolo SCSI).
Máquinas virtuales
Una máquina virtual es una implementación de software de una máquina física o un lenguaje de programación (por ejemplo, el Entorno en tiempo de ejecución Java o LISP). Las máquinas virtuales en el contexto de virtualización son sistemas operativos en hardware virtualizado.
Migración
Migración es el nombre que recibe el proceso de desplazar un huésped virtualizado de un host a otro. La migración puede realizarse desconectado (cuando el huésped está se interrumpe y luego se traslada) o conectado o en vivo (cuando el huésped es desplazado y trasladado sin interrupción). Los huéspedes Xen totalmente virtualizados, los huéspedes para-virtualizados y los huéspedes KVM totalmente virtualizados, todos pueden ser migrados.
La migración es una función clave de la virtualización ya que el software es totalmente independiente del hardware. La migración es útil para:
  • Equilibrio de carga - los huéspedes pueden desplazarse a hosts de menor uso cuando un host se sobrecarga.
  • Recuperación de fallos de Hardware - cuando los dispositivos de hardware en el host comienzan a fallar, los huéspedes se pueden reubicar para que el host pueda ser apagado y reparado.
  • Ahorro de energía - los huéspedes pueden redistribuirse a otros hosts y sistemas de host apagados para ahorrar energía y cortar gastos en periodos de poco uso.
  • Migración geográfica - los huéspedes pueden ser desplazados a otro sitio para una latencia menor o en circunstancias graves.
Almacenamiento compartido o en redes se utiliza para almacenar imágenes de huésped. Sin migración de almacenamiento compartido esto no es posible.
Una migración interrumpe el huésped luego desplaza una imagen de la memoria de huéspedes al host de destino. El huésped se retoma en el host de destino y la memoria que el huésped utilizó en el host de origen es liberada.
El tiempo de una migración depende del ancho de banda de la red y de la latencia. Un huésped con 2GB de memoria tarda varios segundos en un enlace Ethernet de 1 Gbit.
A live migration keeps the guest running on the source host and begins moving the memory without stopping the guest. All modified memory pages are monitored for changes and sent to the destination while the image is sent. The memory is updated with the changed pages. The process continues until the amount of pause time allowed for the guest equals the predicted time for the final few pages to be transfer. KVM estimates the time remaining and attempts to transfer the maximum amount of page files from the source to the destination until KVM predicts the amount of remaining pages can be transferred during a very brief time while the virtualized guest is paused. The registers are loaded on the new host and the guest is then resumed on the destination host. If the guest cannot be merged (which happens when guests are under extreme loads) the guest is paused and then an offline migration is started instead.
El tiempo que una migración desconectada tarda depende del ancho de banda de red y de la latencia como también de la actividad en el huésped. Si el huésped está utilizando E/S importante o CPU la migración utilizará más tiempo.
Para-virtualización
Para-virtualization uses a special kernel, sometimes referred to as the Xen kernel or the kernel-xen package. Para-virtualized guest kernels are run concurrently on the host while using the host's libraries and devices. A para-virtualized installation can have complete access to all devices on the system which can be limited with security settings (SELinux and file controls). Para-virtualization is faster than full virtualization. Para-virtualization can effectively be used for load balancing, provisioning, security and consolidation advantages.
A partir de Fedora 9 ya no se necesitará un kernel especial. Una vez se haya aceptado este parche dentro del árbol principal de Linux todos los kernel de Linux después de esta versión tendrán para-virtualización habilitada o disponible.
Para-virtualizado
See Para-virtualization.
PCI passthrough
KVM and Xen hypervisors support attaching PCI devices on the host system to virtualized guests. PCI passthrough allows guests to have exclusive access to PCI devices for a range of tasks. PCI passthrough allows PCI devices to appear and behave as if they were physically attached to the guest operating system.
phy device
The phy device parameter allows guest's to access physical disks. Physical disks includes:
  • LVM volumes (for example, /dev/VolGroup00/LogVol02),
  • disk partitions (for example, /dev/sda5), and
  • whole block devices (for example, /dev/sda).
Physical mode provides the best performance as the hypervisor bypasses extra layers of software on the host at the price of slightly less flexibility in managing the device.
Security Enhanced Linux
Abreviatura para Security Enhanced Linux o Seguridad mejorada de Linux, SELinux utiliza módulos de seguridad mejorada de Linux (LSM) en el kernel de Linux para proporcionar un rango de políticas de seguridad de mínimo privilegio requerido.
Sistema huésped
Also known as guests, virtual machines, virtual servers or domU.
tap:aio
The tap:aio parameter sets the Xen hypervisor to use an advanced access mode designed for safety and performance. File-based, are accessed using a kernel thread and a user-space process. The tap:aio method respects guest flush requests which makes it safer than the file driver. The virtualization tools use tap:aio by default for accessing file-based guest disks on the Xen Hypervisor.
Universally Unique Identifier
Un Identificador universal único (UUID) es un método estándar de nomenclatura para dispositivos, sistemas y algunos objetos de software en entornos de informática distribuidos. Los tipos de UUID en virtualización incluyen: identificadores de sistema de archivo ext2 y ext3, identificadores de dispositivos RAID, iSCSI e identificadores de dispositivo LUN, direcciones MAC e identificadores de máquinas virtuales.
Virtualización
Virtualization is a broad computing term for running software, usually operating systems, concurrently and isolated from other programs on one system. Most existing implementations of virtualization use a hypervisor, a software layer on top of an operating system, to abstract hardware. The hypervisor allows multiple operating systems to run on the same physical system by giving the guest operating system virtualized hardware. There are various methods for virtualizing operating systems:
  • Hardware-assisted virtualization is the technique used for full virtualization with Xen and KVM.
  • Para-virtualization is a technique used by Xen to run Linux guests.
  • La virtualización de software o emulación. La virtualización de software utiliza traducción binaria y otras técnicas de emulación para ejecutar sistemas operativos no modificados. La virtualización de software es mucho más lenta que la virtualización de hardware asistida o la para-virtualización, en la forma de QEMU, no está soportada por Red Hat Enterprise Linux.
Red Hat Enterprise Linux 5 supports hardware-assisted, full virtualization with the Xen and KVM hypervisors and software para-virtualization with the Xen hypervisor for hosting Red Hat Enterprise Linux guests.
Virtualización completa
Xen and KVM can use full virtualization. Full virtualization uses hardware features of the processor to provide total abstraction of the underlying physical system (bare metal) and create a new virtual machine in which the guest operating systems can run. No modifications are needed in the guest operating system. The guest operating system and any applications on the guest are not aware of the virtualized environment and run normally. Para-virtualization requires a modified version of the Linux operating system.
Virtualized CPU
Un sistema tiene una cantidad de CPU virtuales (VCPU) relativas al número de núcleos de procesador físico. El número de VCPU es finito y representa el número total de VCPU que se pueden asignar a máquinas virtuales huéspedes.
Xen
Red Hat Enterprise Linux supports the Xen hypervisor and the KVM hypervisor. Both hypervisors have different architectures and development approaches. The Xen hypervisor runs underneath a Red Hat Enterprise Linux operating system which acts as a host managing system resources and virtualization APIs. The host is sometimes referred to as dom0, or Domain0.

Recursos adicionales

Para saber más sobre la virtualización y de Red Hat Enterprise Linux, consulte los siguientes recursos:

A.1. Recursos en línea

  • http://www.cl.cam.ac.uk/research/srg/netos/xen/ El sitio Web del proyecto Xen™ para administración de máquina desde la cual se deriva el paquete kernel-xen. El sitio mantiene los proyectos binarios de la línea de desarrollo principal de Xen y el código fuente. Asímismo, la información sobre generalidades de arquitectura, documentación y enlaces relacionado con Xen y sus tecnologías asociadas.
  • Sitio Web de la comunidad Xen
  • http://www.libvirt.org/ es el sitio Web oficial para API de virtualización de libvirt.
  • http://virt-manager.et.redhat.com/ es el proyecto de sitio Web para el Administrador de máquina virtual (virt-manager), la aplicación gráfica para máquinas virtuales.

A.2. Documentación instalada

  • /usr/share/doc/xen-<número-de-versión>/ — Este directorio contiene bastante información sobre el hipervisor de virtualización de Xen y las herramientas de administración asociadas. Incluye ejemplos de configuración, información específica de hardware y la actual documentación de usuario de la línea de desarrollo principal de Xen.
  • man virsh y /usr/share/doc/libvirt-<número-de-versión> — Contiene comandos y opciones para la utilidad de administración de máquinas virtuales virsh e información sobre la API de la biblioteca de virtualización libvirt.
  • /usr/share/doc/gnome-applet-vm-<número-de-versión> — Documentación del applet del panel gráfico de GNOME que monitoriza y administra máquinas virtuales locales.
  • /usr/share/doc/libvirt-python-<número-de-versión> — proporciona información sobre las extensiones de Python de la biblioteca libvirt. El paquete libvirt-python le permite a los programadores de Python crear programas que utilicen la biblioteca de administración de virtualización libvirt.
  • /usr/share/doc/python-virtinst-<número-de-versión> — proporciona la documentación del comando virt-install que ayuda en el inicio de instalaciones de Fedora y Red Hat Enterprise Linux en máquinas virtuales.
  • /usr/share/doc/virt-manager-<número-de-versión> — Proporciona documentación sobre el administrador de máquinas virtuales. Éste proporciona una herramienta gráfica para la administración de máquinas virtuales.

Colofón

Este manual está escrito en el formato de DocBook XML v4.
This book is based on the work of Jan Mark Holzer, Chris Curran and Scott Radvan.
Otros reconocimientos van para:
  • Don Dutile, contribuyó con la edición técnica para la sección de controladores de paravirtualización.
  • Barry Donahue, contribuyó con la edición técnica para la sección de controladores de paravirtualización.
  • Rick Ring, contribuyó con la edición técnica para la sección sobre el programa de administración de máquinas virtuales.
  • Michael Kearey, contribuyó con la edición técnica para las secciones sobre el uso de archivos de configuración en XML con virsh y controladores virtualizados de disquetes.
  • Marco Grigull, contribuyó con la edición técnica para las sección de rendimiento y compatibilidad de software.
  • Eugene Teo, contribuyó con la edición técnica para la sección de administración de huéspedes con virsh.
Jeffrey Fearn, desarrollador de Publican, la herramienta de publicación que produjo este libro.
El equipo de localización de Red Hat consta de las siguientes personas:
  • Chino simplificado
    • Leah Wei Liu
  • Chino tradicional
    • Chester Cheng
    • Terry Chuang
  • Japonés
    • Kiyoto Hashida
  • Coreano
    • Eun-ju Kim
  • Francés
    • Sam Friedmann
  • Alemán
    • Hedda Peters
  • Italiano
    • Francesco Valente
  • Portugués (Brasil)
    • Glaucia de Freitas
    • Leticia de Lima
  • Español
    • Angela Garcia
    • Gladys Guerrero
  • Ruso
    • Yuliya Poyarkova