XenServer

Administrar redes

Los procedimientos de configuración de red en esta sección difieren según si está configurando un host independiente o un host que forma parte de un grupo de recursos.

Crear redes en un host independiente

Dado que las redes externas se crean para cada PIF durante la instalación del host, la creación de redes adicionales normalmente solo es necesaria para:

  • Usar una red privada

  • Admitir operaciones avanzadas como VLAN o enlace de NIC

Para obtener información sobre cómo agregar o eliminar redes usando XenCenter, consulte Agregar una nueva red en la documentación de XenCenter.

Abra la consola de texto del host XenServer®.

Cree la red usando el comando network-create, que devuelve el UUID de la red recién creada:

xe network-create name-label=mynetwork
<!--NeedCopy-->

En este punto, la red no está conectada a un PIF y, por lo tanto, es interna.

Crear redes en grupos de recursos

Todos los hosts de XenServer en un grupo de recursos deben tener el mismo número de NIC físicas. Este requisito no se aplica estrictamente cuando un host se une a un grupo. Una de las NIC siempre se designa como la interfaz de administración, utilizada para el tráfico de administración de XenServer.

Dado que todos los hosts de un grupo comparten un conjunto común de redes, es importante tener la misma configuración de red física para los hosts de XenServer en un grupo. Los PIF de los hosts individuales están conectados a redes de todo el grupo según el nombre del dispositivo. La red X corresponde a la interfaz de red en la posición X bajo el modelo de nomenclatura de red de Dom0.

Si un host de XenServer tiene un número diferente de NIC que otros hosts en el grupo, pueden surgir complicaciones. Las complicaciones pueden surgir porque no todas las redes del grupo son válidas para todos los hosts del grupo. Por ejemplo, si los hosts host1 y host2 están en el mismo grupo y host1 tiene cuatro NIC y host2 solo tiene dos, solo las redes conectadas a los PIF correspondientes a las dos primeras interfaces de red de host1 son válidas en host2. Las VM en host1 con VIF conectadas a redes correspondientes a las interfaces de red restantes no pueden migrar al host host2.

Crear VLAN

Para los hosts en un grupo de recursos, puede usar el comando pool-vlan-create. Este comando crea la VLAN y automáticamente crea y conecta los PIF necesarios en los hosts del grupo. Para obtener más información, consulte pool-vlan-create.

Abra la consola del host XenServer.

Cree una red para usar con la VLAN. Se devuelve el UUID de la nueva red:

xe network-create name-label=network5
<!--NeedCopy-->

Use el comando pif-list para encontrar el UUID del PIF correspondiente a la NIC física que admite la etiqueta VLAN deseada. Se devuelven los UUID y los nombres de dispositivo de todos los PIF, incluidas las VLAN existentes:

xe pif-list
<!--NeedCopy-->

Cree un objeto VLAN especificando el PIF físico deseado y la etiqueta VLAN en todas las máquinas virtuales que se conectarán a la nueva VLAN. Se crea un nuevo PIF y se conecta a la red especificada. Se devuelve el UUID del nuevo objeto PIF.

xe vlan-create network-uuid=network_uuid pif-uuid=pif_uuid vlan=5
<!--NeedCopy-->

Conecte los VIF de las máquinas virtuales a la nueva red. Para obtener más información, consulte Creación de redes en un host independiente.

Crear enlaces de NIC en un host independiente

Recomendamos usar XenCenter para crear enlaces de NIC. Para obtener más información, consulte Configuración de NIC.

Esta sección describe cómo usar la CLI de xe para enlazar interfaces NIC en hosts XenServer que no están en un grupo. Para obtener información sobre cómo usar la CLI de xe para crear enlaces de NIC en hosts XenServer que forman un grupo de recursos, consulte Creación de enlaces de NIC en grupos de recursos.

Crear un enlace de NIC

Cuando se enlaza una NIC, el enlace absorbe el PIF/NIC en uso como interfaz de administración. La interfaz de administración se mueve automáticamente al PIF del enlace.

  1. Use el comando network-create para crear una red para usar con la NIC enlazada. Se devuelve el UUID de la nueva red:

    xe network-create name-label=bond0
    <!--NeedCopy-->
    
  2. Use el comando pif-list para determinar los UUID de los PIF que se usarán en el enlace:

    xe pif-list
    <!--NeedCopy-->
    
  3. Realice una de las siguientes acciones:

    • Para configurar el enlace en modo activo-activo (predeterminado), use el comando bond-create para crear el enlace. Usando comas para separar los parámetros, especifique el UUID de la red recién creada y los UUID de los PIF que se enlazarán:

       xe bond-create network-uuid=network_uuid /
            pif-uuids=pif_uuid_1,pif_uuid_2,pif_uuid_3,pif_uuid_4
       <!--NeedCopy-->
      

      Escriba dos UUID cuando esté uniendo dos NIC y cuatro UUID cuando esté uniendo cuatro NIC. El UUID del enlace se devuelve después de ejecutar el comando.

    • Para configurar el enlace en modo activo-pasivo o LACP, use la misma sintaxis, añada el parámetro opcional mode y especifique lacp o active-backup:

       xe bond-create network-uuid=network_uuid pif-uuids=pif_uuid_1, /
            pif_uuid_2,pif_uuid_3,pif_uuid_4 /
            mode=balance-slb | active-backup | lacp
       <!--NeedCopy-->
      

Controlar la dirección MAC del enlace

Cuando se enlaza la interfaz de administración, esta subsume la PIF/NIC en uso como interfaz de administración. Si el host utiliza DHCP, la dirección MAC del enlace es la misma que la de la PIF/NIC en uso. La dirección IP de la interfaz de administración puede permanecer sin cambios.

Puede cambiar la dirección MAC del enlace para que sea diferente de la dirección MAC de la NIC de la interfaz de administración (actual). Sin embargo, a medida que el enlace se habilita y la dirección MAC/IP en uso cambia, las sesiones de red existentes al host se interrumpen.

Puede controlar la dirección MAC de un enlace de dos maneras:

  • Se puede especificar un parámetro opcional mac en el comando bond-create. Puede usar este parámetro para establecer la dirección MAC del enlace en cualquier dirección arbitraria.

  • Si no se especifica el parámetro mac, XenServer utiliza la dirección MAC de la interfaz de administración si es una de las interfaces del enlace. Si la interfaz de administración no forma parte del enlace, pero otra interfaz de administración sí lo es, el enlace utiliza la dirección MAC (y también la dirección IP) de esa interfaz de administración. Si ninguna de las NIC del enlace es una interfaz de administración, el enlace utiliza la MAC de la primera NIC nombrada.

Revertir enlaces de NIC

Al revertir el host de XenServer a una configuración sin enlace, el comando bond-destroy configura automáticamente la NIC principal como interfaz para la interfaz de administración. Por lo tanto, todas las VIF se mueven a la interfaz de administración. Si la interfaz de administración de un host está en una interfaz enlazada de VLAN etiquetada, al realizar bond-destroy, la VLAN de administración se mueve a la NIC principal.

El término NIC principal se refiere a la PIF de la que se copió la configuración de MAC e IP al crear el enlace. Al enlazar dos NIC, la NIC principal es:

  1. La NIC de la interfaz de administración (si la interfaz de administración es una de las NIC enlazadas).

  2. Cualquier otra NIC con una dirección IP (si la interfaz de administración no formaba parte del enlace).

  3. La primera NIC nombrada. Puede averiguar cuál es ejecutando lo siguiente:

    xe bond-list params=all
    <!--NeedCopy-->
    

Crear enlaces de NIC en grupos de recursos

Siempre que sea posible, cree enlaces de NIC como parte de la creación inicial del grupo de recursos, antes de unir más hosts al grupo o crear máquinas virtuales. Esto permite que la configuración del enlace se replique automáticamente en los hosts a medida que se unen al grupo y reduce el número de pasos necesarios.

Añadir un enlace de NIC a un grupo existente requiere una de las siguientes opciones:

  • Usar la CLI para configurar los enlaces en el coordinador del grupo y luego en cada miembro del grupo.

  • Usar la CLI para configurar los enlaces en el coordinador del grupo y luego reiniciar cada miembro del grupo para que herede su configuración del coordinador del grupo.

  • Usar XenCenter® para configurar los enlaces en el coordinador del grupo. XenCenter sincroniza automáticamente la configuración de red en los hosts miembros con el coordinador del grupo, por lo que no es necesario reiniciar los hosts miembros.

Para simplificar y evitar configuraciones erróneas, recomendamos usar XenCenter para crear enlaces de NIC. Para obtener más información, consulte Configuración de NIC.

Esta sección describe cómo usar la CLI de xe para crear interfaces NIC enlazadas en hosts XenServer que componen un grupo de recursos. Para obtener información sobre cómo usar la CLI de xe para crear enlaces de NIC en un host independiente, consulte Creación de enlaces de NIC en un host independiente.

Advertencia:

No intente crear enlaces de red cuando la alta disponibilidad esté habilitada. El proceso de creación de enlaces interrumpe el latido de alta disponibilidad en curso y hace que los hosts se auto-cercen (se apaguen). Los hosts pueden fallar al reiniciarse correctamente y pueden necesitar el comando host-emergency-ha-disable para recuperarse.

Seleccione el host que desea que sea el coordinador del grupo. El coordinador del grupo pertenece a un grupo sin nombre por defecto. Para crear un grupo de recursos con la CLI, cambie el nombre del grupo sin nombre existente:

xe pool-param-set name-label="New Pool" uuid=pool_uuid
<!--NeedCopy-->

Cree el enlace de NIC como se describe en Crear un enlace de NIC.

Abra una consola en un host que desee unir al grupo y ejecute el comando:

xe pool-join master-address=host1 master-username=root master-password=password
<!--NeedCopy-->

La información de red y de enlace se replica automáticamente en el nuevo host. La interfaz de administración se mueve automáticamente de la NIC del host donde se configuró originalmente al PIF enlazado. Es decir, la interfaz de administración ahora se absorbe en el enlace para que todo el enlace funcione como interfaz de administración.

Utilice el comando host-list para encontrar el UUID del host que se está configurando:

xe host-list
<!--NeedCopy-->

Advertencia:

No intente crear enlaces de red mientras la alta disponibilidad esté habilitada. El proceso de creación de enlaces interrumpe el latido de alta disponibilidad en curso y hace que los hosts se auto-cercen (se apaguen). Los hosts pueden fallar al reiniciarse correctamente y es posible que deba ejecutar el comando host-emergency-ha-disable para recuperarse.

Configurar una NIC de almacenamiento dedicada

Puede usar XenCenter o la CLI de xe para asignar una dirección IP a una NIC y dedicarla a una función específica, como el tráfico de almacenamiento. Cuando configura una NIC con una dirección IP, lo hace creando una interfaz secundaria. (La NIC habilitada para IP que XenServer usa para la administración se conoce como interfaz de administración).

Cuando desee dedicar una interfaz secundaria para un propósito específico, asegúrese de que la configuración de red adecuada esté implementada. Esto es para garantizar que la NIC se use solo para el tráfico deseado. Para dedicar una NIC al tráfico de almacenamiento, configure la NIC, el destino de almacenamiento, el conmutador y la VLAN de tal manera que el destino solo sea accesible a través de la NIC asignada. Si su configuración física y de IP no limita el tráfico enviado a través de la NIC de almacenamiento, puede enviar tráfico, como el tráfico de administración, a través de la interfaz secundaria.

Cuando cree una nueva interfaz secundaria para el tráfico de almacenamiento, debe asignarle una dirección IP que sea:

  • En la misma subred que el controlador de almacenamiento, si corresponde, y

  • No en la misma subred que cualquier otra interfaz secundaria o la interfaz de administración.

Cuando configure interfaces secundarias, cada interfaz secundaria debe estar en una subred separada. Por ejemplo, si desea configurar dos interfaces secundarias más para almacenamiento, necesitará direcciones IP en tres subredes diferentes: una subred para la interfaz de administración, una subred para la Interfaz Secundaria 1 y una subred para la Interfaz Secundaria 2.

Nota:

Al seleccionar una NIC para configurar como interfaz secundaria para usar con SR iSCSI o NFS, asegúrese de que la NIC dedicada utilice una subred IP separada que no sea enrutable desde la interfaz de administración. Si esto no se aplica, el tráfico de almacenamiento puede dirigirse a través de la interfaz de administración principal después de un reinicio del host, debido al orden en que se inicializan las interfaces de red.

Asegúrese de que la PIF esté en una subred separada, o que el enrutamiento esté configurado para adaptarse a su topología de red y forzar el tráfico deseado a través de la PIF seleccionada.

Configure una configuración IP para la PIF, agregando los valores apropiados para el parámetro de modo. Si usa direccionamiento IP estático, agregue los parámetros IP, máscara de red, puerta de enlace y DNS:

xe pif-reconfigure-ip mode=DHCP | Static uuid=pif-uuid
<!--NeedCopy-->

Establezca el parámetro disallow-unplug de la PIF en true:

xe pif-param-set disallow-unplug=true uuid=pif-uuid
<!--NeedCopy-->
xe pif-param-set other-config:management_purpose="Storage" uuid=pif-uuid
<!--NeedCopy-->

Si desea utilizar una interfaz secundaria para el almacenamiento que también pueda enrutarse desde la interfaz de administración (teniendo en cuenta que esta configuración no es la mejor práctica), tiene dos opciones:

  • Después de un reinicio del host, asegúrese de que la interfaz secundaria esté configurada correctamente. Use los comandos xe pbd-unplug y xe pbd-plug para reinicializar las conexiones de almacenamiento en el host. Este comando reinicia la conexión de almacenamiento y la enruta a través de la interfaz correcta.

  • Alternativamente, puede usar xe pif-forget para eliminar la interfaz de la base de datos de XenServer y configurarla manualmente en el dominio de control. xe pif-forget es una opción avanzada y requiere que esté familiarizado con la configuración manual de redes de Linux.

Usar NICs habilitadas para SR-IOV

Single Root I/O Virtualization (SR-IOV) es una tecnología de virtualización que permite que un único dispositivo PCI aparezca como múltiples dispositivos PCI en el sistema físico. El dispositivo físico real se conoce como Función Física (PF), mientras que los otros se conocen como Funciones Virtuales (VF). El hipervisor puede asignar una o más VF a una Máquina Virtual (VM): el invitado puede entonces usar el dispositivo como si estuviera asignado directamente.

Asignar una o más VF de NIC a una VM permite que su tráfico de red omita el conmutador virtual. Cuando se configura, cada VM se comporta como si estuviera usando la NIC directamente, reduciendo la sobrecarga de procesamiento y mejorando el rendimiento.

Beneficios de SR-IOV

Una VF de SR-IOV tiene un mejor rendimiento que una VIF. Puede garantizar la segregación basada en hardware entre el tráfico de diferentes VM a través de la misma NIC (evitando la pila de red de XenServer).

Usando esta característica, puede:

  • Habilitar SR-IOV en NICs compatibles con SR-IOV.

  • Deshabilitar SR-IOV en NICs compatibles con SR-IOV.

  • Administrar las VF de SR-IOV como un grupo de recursos de VF.

  • Asignar VF de SR-IOV a una VM.

  • Configurar VF de SR-IOV (por ejemplo, dirección MAC, VLAN, velocidad).

  • Ejecutar pruebas para confirmar si SR-IOV es compatible como parte del Kit de Certificación Automatizado.

Configuración del sistema

Configure la plataforma de hardware correctamente para admitir SR-IOV. Se requieren las siguientes tecnologías:

  • Virtualización de E/S de MMU (AMD-Vi e Intel VT-d)

  • Interpretación alternativa de ID de enrutamiento (ARI)

  • Servicios de traducción de direcciones (ATS)

  • Servicios de control de acceso (ACS)

Consulte la documentación que acompaña a su sistema para obtener información sobre cómo configurar el firmware del sistema para habilitar las tecnologías mencionadas.

Habilitar una red SR-IOV en una NIC

En XenCenter, utilice el asistente Nueva red en la pestaña Redes para crear y habilitar una red SR-IOV en una NIC.

Asignar una red SR-IOV a la interfaz virtual (nivel de VM)

En XenCenter, a nivel de VM, utilice el asistente Agregar interfaz virtual en la pestaña Redes para agregar una red habilitada para SR-IOV como interfaz virtual para esa VM. Para obtener más información, consulte Agregar una nueva red.

NIC y huéspedes compatibles

Para obtener una lista de plataformas de hardware y NIC compatibles, consulte Lista de compatibilidad de hardware. Consulte la documentación proporcionada por el proveedor para un huésped en particular para determinar si es compatible con SR-IOV.

Limitaciones

  • Para ciertas NIC que utilizan controladores heredados (por ejemplo, la familia Intel I350), el host debe reiniciarse para habilitar o deshabilitar SR-IOV en estos dispositivos.

  • No se admiten redes SR-IOV a nivel de pool que tengan diferentes tipos de NIC.

  • Una VF SR-IOV y una VIF normal de la misma NIC pueden no ser capaces de comunicarse entre sí debido a las limitaciones de hardware de la NIC. Para permitir que estas VM se comuniquen, asegúrese de que la comunicación utilice el patrón VF a VF o VIF a VIF, y no VF a VIF.

  • La configuración de Calidad de Servicio para algunas VF de SR-IOV no surte efecto porque no admiten la limitación de velocidad de red.

  • La migración en vivo, la suspensión y los puntos de control no son compatibles con las máquinas virtuales que utilizan una VF de SR-IOV.

  • Las VF de SR-IOV no admiten la conexión en caliente (hot-plugging).

  • Las VF de SR-IOV no admiten el arranque por red.

  • Para algunas NIC con controladores de NIC heredados, puede ser necesario reiniciar incluso después de un reinicio del host, lo que indica que la NIC no puede habilitar SR-IOV.

  • Si su máquina virtual tiene una VF de SR-IOV, las funciones que requieren migración en vivo no son posibles. Esto se debe a que la máquina virtual está directamente vinculada a la VF de la NIC física habilitada para SR-IOV.

  • SR-IOV se puede utilizar en un entorno que haga uso de alta disponibilidad. Sin embargo, SR-IOV no se considera en la planificación de capacidad. Las máquinas virtuales que tienen VF de SR-IOV asignadas se reinician con el mejor esfuerzo cuando hay un host en el grupo que tiene los recursos adecuados. Estos recursos incluyen SR-IOV habilitado en la red correcta y una VF libre.

  • Las VF de SR-IOV no son compatibles con PVS-Accelerator.

Configurar VF de SR-IOV para controladores heredados

Normalmente, el número máximo de VF que una NIC puede admitir se puede determinar automáticamente. Para las NIC que utilizan controladores heredados (por ejemplo, la familia Intel I350), el límite se define dentro del archivo de configuración del módulo del controlador. Es posible que el límite deba ajustarse manualmente. Para establecerlo al máximo, abra el archivo con un editor y cambie la línea que comienza por:

## VFs-maxvfs-by-user:
<!--NeedCopy-->

Por ejemplo, para establecer el máximo de VF en 4 para el controlador igb, edite /etc/modprobe.d/igb.conf para que diga:

## VFs-param: max_vfs
## VFs-maxvfs-by-default: 7
## VFs-maxvfs-by-user: 4
options igb max_vfs=0
<!--NeedCopy-->

Notas:

  • El valor debe ser menor o igual que el valor de la línea VFs-maxvfs-by-default.

  • No cambie ninguna otra línea en estos archivos.

  • Realice los cambios antes de habilitar SR-IOV.

CLI

Consulte (/es-es/xenserver/9/command-line-interface.html#sr-iov-commands) para obtener instrucciones de CLI sobre cómo crear, eliminar, mostrar redes SR-IOV y asignar un VF SR-IOV a una VM.

Controlar la velocidad de los datos salientes (QoS)

Para limitar la cantidad de datos salientes que una VM puede enviar por segundo, establezca un valor opcional de Calidad de Servicio (QoS) en las interfaces virtuales de la VM (VIF). La configuración le permite especificar una velocidad de transmisión máxima para los paquetes salientes en kilobytes por segundo.

El valor de Calidad de Servicio limita la velocidad de transmisión desde la VM. La configuración de Calidad de Servicio no limita la cantidad de datos que la VM puede recibir. Si se desea tal límite, recomendamos limitar la velocidad de los paquetes entrantes en un nivel superior de la red (por ejemplo, a nivel del conmutador).

Dependiendo de la pila de red configurada en el pool, puede establecer el valor de Calidad de Servicio en las interfaces virtuales de la VM (VIF) en uno de dos lugares. Puede establecer este valor utilizando la CLI xe o en XenCenter.

  • XenCenter Puede establecer el valor límite de la velocidad de transmisión de Calidad de Servicio en el cuadro de diálogo de propiedades de la interfaz virtual.
  • Comandos xe Puede establecer la velocidad de transmisión de Calidad de Servicio mediante la CLI utilizando los comandos de la sección siguiente.

Ejemplo de comando CLI para QoS

Para limitar una VIF a una velocidad de transmisión máxima de 100 kilobytes por segundo mediante la CLI, utilice el comando vif-param-set:

xe vif-param-set uuid=vif_uuid qos_algorithm_type=ratelimit
xe vif-param-set uuid=vif_uuid qos_algorithm_params:kbps=100
<!--NeedCopy-->

Nota:

El parámetro kbps denota kilobytes por segundo (kBps), no kilobits por segundo (kbps).

Cambiar las opciones de configuración de red

Esta sección describe cómo cambiar la configuración de red de su host XenServer. Incluye:

  • Cambiar el nombre de host (es decir, el nombre del Sistema de Nombres de Dominio (DNS))

  • Adición o eliminación de servidores DNS

  • Cambio de direcciones IP

  • Cambio de la NIC utilizada como interfaz de administración

  • Adición de una nueva NIC física al servidor

  • Adición de un propósito a una red

  • Habilitación del filtrado ARP (bloqueo de puerto de conmutador)

Nombre de host

El nombre de host del sistema, también conocido como nombre de dominio o DNS, se define en la base de datos de todo el grupo y se cambia mediante el comando CLI xe host-set-hostname-live de la siguiente manera:

xe host-set-hostname-live host-uuid=host_uuid host-name=host-name
<!--NeedCopy-->

El nombre de host del dominio de control subyacente cambia dinámicamente para reflejar el nuevo nombre de host.

Servidores DNS

Para agregar o eliminar servidores DNS en la configuración de direccionamiento IP del host XenServer, utilice el comando pif-reconfigure-ip. Por ejemplo, para una PIF con una IP estática:

xe pif-reconfigure-ip uuid=pif_uuid mode=static DNS=new_dns_ip IP=IP netmask=netmask
<!--NeedCopy-->

Cambiar la configuración de la dirección IP para un host independiente

Puede usar la CLI de xe para cambiar la configuración de la interfaz de red. No cambie directamente los scripts de configuración de red subyacentes.

Para cambiar la configuración de la dirección IP de una PIF, utilice el comando CLI pif-reconfigure-ip. Consulte pif-reconfigure-ip para obtener detalles sobre los parámetros del comando pif-reconfigure-ip. Consulte la siguiente sección para obtener información sobre cómo cambiar las direcciones IP del host en los grupos de recursos.

Cambiar la configuración de la dirección IP en los grupos de recursos

Los hosts de XenServer en los grupos de recursos tienen una única dirección IP de administración utilizada para la administración y la comunicación hacia y desde otros hosts del grupo. Los pasos necesarios para cambiar la dirección IP de la interfaz de administración de un host son diferentes para el coordinador del grupo y para otros hosts.

Nota:

Debe tener cuidado al cambiar la dirección IP de un host y otros parámetros de red. Dependiendo de la topología de red y del cambio que se realice, las conexiones al almacenamiento de red pueden perderse. Cuando esto sucede, el almacenamiento debe volver a conectarse utilizando la función Reparar almacenamiento en XenCenter, o utilizando el comando CLI pbd-plug. Por esta razón, le recomendamos que migre las máquinas virtuales fuera del host antes de cambiar su configuración IP.

Utilice el comando CLI pif-reconfigure-ip para establecer la dirección IP según desee. Consulte pif-reconfigure-ip para obtener detalles sobre los parámetros del comando pif-reconfigure-ip. :

xe pif-reconfigure-ip uuid=pif_uuid mode=DHCP
<!--NeedCopy-->

Utilice el comando CLI host-list para confirmar que el host miembro se ha vuelto a conectar correctamente al coordinador del grupo, comprobando que todos los demás hosts de XenServer del grupo son visibles:

xe host-list
<!--NeedCopy-->

Cambiar la dirección IP del host XenServer coordinador del grupo requiere pasos adicionales. Esto se debe a que cada miembro del grupo utiliza la dirección IP anunciada del coordinador del grupo para la comunicación. Los miembros del grupo no saben cómo contactar con el coordinador del grupo cuando su dirección IP cambia.

Siempre que sea posible, utilice una dirección IP dedicada que no sea probable que cambie durante la vida útil del grupo para los coordinadores del grupo.

Utilice el comando CLI pif-reconfigure-ip para establecer la dirección IP según desee:

xe pif-reconfigure-ip uuid=pif_uuid mode=DHCP
<!--NeedCopy-->

Cuando la dirección IP del coordinador del grupo cambia, todos los hosts miembros entran en un modo de emergencia al no poder contactar con el coordinador del grupo.

En el coordinador del grupo, utilice el comando pool-recover-slaves para forzar al coordinador del grupo a contactar con cada miembro del grupo e informarles de la nueva dirección IP del coordinador del grupo:

xe pool-recover-slaves
<!--NeedCopy-->

Interfaz de administración

Cuando instala XenServer en un host, una de sus NIC se designa como la interfaz de administración: la NIC utilizada para el tráfico de administración de XenServer. La interfaz de administración se utiliza para las conexiones de XenCenter al host (por ejemplo, Citrix Virtual Apps and Desktops™) y para la comunicación de host a host.

Utilice el comando pif-list para determinar qué PIF corresponde a la NIC que se utilizará como interfaz de administración. Se devuelve el UUID de cada PIF.

xe pif-list
<!--NeedCopy-->

Utilice el comando pif-param-list para verificar la configuración de direccionamiento IP para el PIF utilizado para la interfaz de administración. Si es necesario, utilice el comando pif-reconfigure-ip para configurar el direccionamiento IP para el PIF que se va a utilizar.

xe pif-param-list uuid=pif_uuid
<!--NeedCopy-->

Utilice el comando CLI host-management-reconfigure para cambiar el PIF utilizado para la interfaz de administración. Si este host forma parte de un grupo de recursos, este comando debe emitirse en la consola del host miembro:

xe host-management-reconfigure pif-uuid=pif_uuid
<!--NeedCopy-->

Utilice el comando network-list para determinar qué PIF corresponde a la NIC que se utilizará como interfaz de administración para todos los hosts del pool. Se devuelve el UUID de la red de todo el pool.

xe network-list
<!--NeedCopy-->

Utilice el comando network-param-list para obtener los UUID de PIF de todos los hosts del pool. Utilice el comando pif-param-list para verificar la configuración de direccionamiento IP para el PIF de la interfaz de administración. Si es necesario, utilice el comando pif-reconfigure-ip para configurar el direccionamiento IP para el PIF que se va a utilizar.

xe pif-param-list uuid=pif_uuid
<!--NeedCopy-->

Utilice el comando CLI pool-management-reconfigure para cambiar el PIF utilizado para la interfaz de administración que aparece en la lista Redes.

xe pool-management-reconfigure network-uuid=network_uuid
<!--NeedCopy-->

Restringir el uso del puerto 80

Puede utilizar HTTPS a través del puerto 443 o HTTP a través del puerto 80 para comunicarse con XenServer. Por razones de seguridad, el puerto 80 está cerrado por defecto para las nuevas instalaciones. Las actualizaciones conservan la configuración de puerto existente.

Para abrir o cerrar el puerto 80, consulte el comando CLI xe https-only o Cambiar propiedades del pool en la documentación de XenCenter.

Deshabilitar el acceso de administración

Para deshabilitar completamente el acceso remoto a la consola de administración, utilice el comando CLI host-management-disable.

Advertencia:

Cuando la interfaz de administración está deshabilitada, debe iniciar sesión en la consola del host físico para realizar tareas de administración. Las interfaces externas, como XenCenter, no funcionan cuando la interfaz de administración está deshabilitada.

Agregar una nueva NIC física

  1. Instale una nueva NIC física en su host XenServer de la manera habitual.
  2. Reinicie su host XenServer.
  3. Enumere todas las NIC físicas para ese host XenServer utilizando el siguiente comando:

    xe pif-list host-uuid=<host_uuid>
    
  4. Si no ve la NIC adicional, busque nuevas interfaces físicas utilizando el siguiente comando:

    xe pif-scan host-uuid=<host_uuid>
    

    Este comando crea un nuevo objeto PIF para la nueva NIC.

  5. Vuelva a listar las NIC físicas en el host de XenServer para verificar que la nueva NIC es visible:

    xe pif-list host-uuid=<host_uuid>
    
  6. La nueva PIF aparece inicialmente como desconectada (currently-attached ( RO): false). Para activarla, utilice el siguiente comando:

    xe pif-plug uuid=<uuid_of_pif>
    

Alternativamente, puede usar XenCenter para volver a buscar nuevas NIC. Para obtener más información, consulte Configuración de NIC en la documentación de XenCenter.

Eliminar una NIC física

Antes de quitar la NIC, asegúrese de conocer el UUID de la PIF correspondiente. Quite la NIC física de su host XenServer de la manera habitual. Después de reiniciar el host, ejecute el comando CLI xe pif-forget uuid=<UUID> para destruir el objeto PIF.

Añadir un propósito a una red

El propósito de la red se puede utilizar para añadir funcionalidades adicionales a una red. Por ejemplo, la capacidad de usar la red para establecer conexiones NBD.

Para añadir un propósito de red, utilice el comando xe network-param-add:

xe network-param-add param-name=purpose param-key=purpose uuid=network-uuid
<!--NeedCopy-->

Para eliminar un propósito de red, utilice el comando xe network-param-remove:

xe network-param-remove param-name=purpose param-key=purpose uuid=network-uuid
<!--NeedCopy-->

Actualmente, los valores disponibles para el propósito de la red son nbd y insecure_nbd. Para obtener más información, consulte la Guía de seguimiento de bloques modificados de XenServer.

Usar el bloqueo de puertos de conmutador

La función de bloqueo de puertos de conmutador de XenServer le permite controlar el tráfico enviado desde máquinas virtuales desconocidas, no confiables o potencialmente hostiles, limitando su capacidad de simular que tienen una dirección MAC o IP que no les fue asignada. Puede usar los comandos de bloqueo de puertos para bloquear todo el tráfico en una red de forma predeterminada o definir direcciones IP específicas desde las cuales una máquina virtual individual puede enviar tráfico.

El uso del bloqueo de puertos de conmutador le permite simplificar la configuración de su red al permitir que todos sus inquilinos o invitados utilicen la misma red de capa 2.

Una de las funciones más importantes de los comandos de bloqueo de puertos es que pueden restringir el tráfico que envía un invitado no confiable. Esto restringe la capacidad del invitado de simular que tiene una dirección MAC o IP que en realidad no posee. Específicamente, puede usar estos comandos para evitar que un invitado:

  • Reclamar una dirección IP o MAC distinta de las que el administrador de XenServer ha especificado que puede usar

  • Interceptar, suplantar o interrumpir el tráfico de otras máquinas virtuales

Requisitos

  • Cuando habilita el Control de acceso basado en roles (RBAC) en su entorno, el usuario que configura el bloqueo de puertos de conmutador debe iniciar sesión con una cuenta que tenga al menos un rol de Operador de grupo o Administrador de grupo. Cuando RBAC no está habilitado en su entorno, el usuario debe iniciar sesión con la cuenta raíz del coordinador del grupo.

  • Cuando ejecuta los comandos de bloqueo de puertos de conmutador, las redes pueden estar en línea o fuera de línea.

  • En los invitados de Windows, el icono de red desconectada solo aparece cuando las herramientas de máquina virtual de XenServer están instaladas en el invitado.

Notas

Sin ninguna configuración de bloqueo de puertos de conmutador, las VIF se establecen en “network_default” y las redes se establecen en “unlocked”.

La configuración del bloqueo de puertos de conmutador no es compatible cuando se utilizan controladores de terceros en el entorno.

El bloqueo de puertos de conmutador no impide que los inquilinos de la nube:

  • Realizar un ataque a nivel de IP a otro inquilino/usuario. Sin embargo, el bloqueo de puertos de conmutador les impide realizar el ataque a nivel de IP si intentan usar los siguientes medios para hacerlo y el bloqueo de puertos de conmutador está configurado: a) suplantar a otro inquilino en la nube o usuario o b) iniciar una intercepción de tráfico destinado a otro usuario.

  • Agotar los recursos de red.

  • Recibir parte del tráfico destinado a otras máquinas virtuales a través de comportamientos normales de inundación del conmutador (para direcciones MAC de difusión o direcciones MAC de destino desconocidas).

Del mismo modo, el bloqueo de puertos de conmutador no restringe dónde puede enviar tráfico una máquina virtual.

Notas de implementación

Puede implementar la funcionalidad de bloqueo de puerto de conmutador utilizando la línea de comandos o la API de XenServer. Sin embargo, en entornos grandes, donde la automatización es una preocupación principal, el método de implementación más típico podría ser el uso de la API.

Ejemplos

Esta sección proporciona ejemplos de cómo el bloqueo de puerto de conmutador puede prevenir ciertos tipos de ataques. En estos ejemplos, VM-c es una máquina virtual que un inquilino hostil (Inquilino C) está alquilando y utilizando para ataques. VM-a y VM-b son máquinas virtuales alquiladas por inquilinos no atacantes.

Ejemplo 1: Cómo el bloqueo de puerto de conmutador puede prevenir la suplantación de ARP:

La suplantación de ARP se utiliza para indicar los intentos de un atacante de asociar su dirección MAC con la dirección IP de otro nodo. La suplantación de ARP puede resultar potencialmente en que el tráfico del nodo se envíe al atacante en su lugar. Para lograr este objetivo, el atacante envía mensajes ARP falsos (suplantados) a una LAN Ethernet.

Escenario:

La Máquina Virtual A (VM-a) quiere enviar tráfico IP desde VM-a a la Máquina Virtual B (VM-b) dirigiéndolo a la dirección IP de VM-b. El propietario de la Máquina Virtual C quiere usar la suplantación de ARP para fingir que su VM, VM-c, es en realidad VM-b.

  1. VM-c envía un flujo especulativo de respuestas ARP a VM-a. Las respuestas ARP afirman que la dirección MAC en la respuesta (c_MAC) está asociada con la dirección IP, b_IP.

    Resultado: Debido a que el administrador habilitó el bloqueo de puerto de conmutador, todos estos paquetes se descartan porque habilitar el bloqueo de puerto de conmutador evita la suplantación de identidad.

  2. VM-b envía una respuesta ARP a VM-a, afirmando que la dirección MAC en la respuesta (b_MAC) está asociada con la dirección IP, b_IP.

    Resultado: VM-a recibe la respuesta ARP de VM-b.

Ejemplo 2: Prevención de suplantación de IP:

La suplantación de dirección IP es un proceso que oculta la identidad de los paquetes creando paquetes de Protocolo de Internet (IP) con una dirección IP de origen falsificada.

Escenario:

El inquilino C está intentando realizar un ataque de denegación de servicio utilizando su host, Host-C, en un sistema remoto para disfrazar su identidad.

Intento 1:

El inquilino C establece la dirección IP y la dirección MAC del Host-C a las direcciones IP y MAC de la VM-a (a_IP y a_MAC). El inquilino C indica al Host-C que envíe tráfico IP a un sistema remoto.

Resultado: Los paquetes del Host-C se descartan. Esto se debe a que el administrador habilitó el bloqueo de puerto de conmutador. Los paquetes del Host-C se descartan porque la habilitación del bloqueo de puerto de conmutador evita la suplantación.

Intento 2:

El inquilino C establece la dirección IP del Host-C a la dirección IP de la VM-a (a_IP) y mantiene su c_MAC original.

El inquilino C indica al Host-C que envíe tráfico IP a un sistema remoto.

Resultado: Los paquetes del Host-C se descartan. Esto se debe a que el administrador habilitó el bloqueo de puerto de conmutador, lo que evita la suplantación.

Ejemplo 3: Alojamiento web:

Escenario:

Alice es una administradora de infraestructura.

Uno de sus inquilinos, el inquilino B, aloja varios sitios web desde su VM, VM-b. Cada sitio web necesita una dirección IP distinta alojada en la misma interfaz de red virtual (VIF).

Alice reconfigura la VIF del Host-B para que esté bloqueada a una sola MAC pero a muchas direcciones IP.

Cómo funciona el bloqueo de puerto de conmutador

La función de bloqueo de puerto de conmutador le permite controlar el filtrado de paquetes en uno o más de dos niveles:

  • Nivel VIF. La configuración que realice en la VIF determina cómo se filtran los paquetes. Puede configurar la VIF para evitar que la VM envíe cualquier tráfico, restringir la VIF para que solo pueda enviar tráfico utilizando su dirección IP asignada, o permitir que la VM envíe tráfico a cualquier dirección IP en la red conectada a la VIF.

  • Nivel de red. La red de XenServer determina cómo se filtran los paquetes. Cuando el modo de bloqueo de una VIF se establece en network_default, se refiere a la configuración de bloqueo a nivel de red para determinar qué tráfico permitir.

Estados del modo de bloqueo de VIF

La función de bloqueo de puerto de conmutador de XenServer proporciona un modo de bloqueo que permite configurar las VIF en cuatro estados diferentes. Estos estados solo se aplican cuando la VIF está conectada a una máquina virtual en ejecución.

 Esta ilustración muestra cómo se comportan tres estados diferentes del modo de bloqueo de VIF cuando el modo de bloqueo de red está configurado como desbloqueado y el estado de la VIF está configurado. En la primera imagen, el estado de la VIF se establece en predeterminado, por lo que no se filtra tráfico de la VM. La VIF no envía ni recibe ningún paquete porque el modo de bloqueo está establecido en `disabled` en la segunda imagen. En la tercera imagen, el estado de la VIF se establece en bloqueado. Esto significa que la VIF solo puede enviar paquetes si esos paquetes contienen la dirección MAC e IP correctas.

  • Network_default. Cuando el estado de la VIF se establece en network_default, XenServer utiliza el parámetro default-locking-mode de la red para determinar si se deben filtrar los paquetes que viajan a través de la VIF y cómo hacerlo. El comportamiento varía según si la red asociada tiene el parámetro de modo de bloqueo predeterminado de red establecido en deshabilitado o desbloqueado:

    -default-locking-mode=disabled, XenServer aplica una regla de filtrado para que la VIF descarte todo el tráfico.

    -default-locking-mode=unlocked, XenServer elimina todas las reglas de filtrado asociadas con la VIF. Por defecto, el parámetro de modo de bloqueo predeterminado se establece en unlocked.

    Para obtener información sobre el parámetro default-locking-mode, consulte Comandos de red.

    El modo de bloqueo predeterminado de la red no tiene ningún efecto en las VIF adjuntas cuyo estado de bloqueo sea diferente de network_default.

    Nota:

    No puede cambiar el default-locking-mode de una red que tenga VIF activas conectadas.

  • Bloqueado. XenServer aplica reglas de filtrado para que solo el tráfico enviado a/desde las direcciones MAC e IP especificadas pueda salir a través de la VIF. En este modo, si no se especifican direcciones IP, la VM no puede enviar ningún tráfico a través de esa VIF, en esa red.

    Para especificar las direcciones IP desde las que la VIF acepta tráfico, utilice las direcciones IP IPv4 o IPv6 mediante los parámetros ipv4_allowed o ipv6_allowed.

  • Desbloqueado. Todo el tráfico de red puede pasar a través de la VIF. Es decir, no se aplican filtros a ningún tráfico que entre o salga de la VIF.

  • Deshabilitado. No se permite que pase tráfico a través de la VIF. (Es decir, XenServer aplica una regla de filtrado para que la VIF descarte todo el tráfico.)

Configurar el bloqueo de puertos del conmutador

Esta sección proporciona tres procedimientos diferentes:

  • Restringir las VIF para que utilicen una dirección IP específica

  • Añadir una dirección IP a una lista restringida existente. Por ejemplo, para añadir una dirección IP a una VIF cuando la VM se está ejecutando y está conectada a la red (por ejemplo, si está desconectando una red temporalmente).

  • Eliminar una dirección IP de una lista restringida existente

Si el modo de bloqueo de una VIF está establecido en locked, solo puede usar las direcciones especificadas en los parámetros ipv4-allowed o ipv6-allowed.

Debido a que, en algunos casos relativamente raros, las VIF pueden tener más de una dirección IP, es posible especificar varias direcciones IP para una VIF.

Puede realizar estos procedimientos antes o después de que la VIF esté conectada (o se inicie la VM).

Cambie el modo de bloqueo predeterminado a bloqueado, si aún no está usando ese modo, ejecutando el siguiente comando:

xe vif-param-set uuid=vif-uuid locking-mode=locked
<!--NeedCopy-->

vif-uuid representa el UUID de la VIF a la que desea permitir el envío de tráfico. Para obtener el UUID, ejecute el comando xe vif-list en el host. vm-uuid Indica la máquina virtual para la que aparece la información. El ID del dispositivo indica el número de dispositivo de la VIF.

Ejecute el comando vif-param-set para especificar las direcciones IP desde las que la máquina virtual puede enviar tráfico. Realice una o varias de las siguientes acciones:

  • Especifique uno o más destinos de direcciones IP IPv4. Por ejemplo:

     xe vif-param-set uuid=vif-uuid ipv4-allowed=comma separated list of ipv4-addresses
     <!--NeedCopy-->
    
  • Especifique uno o más destinos de direcciones IP IPv6. Por ejemplo:

     xe vif-param-set uuid=vif-uuid ipv6-allowed=comma separated list of ipv6-addresses
     <!--NeedCopy-->
    

Puede especificar varias direcciones IP separándolas con una coma, como se muestra en el ejemplo anterior.

Después de realizar el procedimiento para restringir una VIF a usar una dirección IP específica, puede agregar una o más direcciones IP que la VIF pueda usar.

Ejecute el comando vif-param-add para añadir las direcciones IP a la lista existente. Realice una o varias de las siguientes acciones:

  • Especifique la dirección IP IPv4. Por ejemplo:

     xe vif-param-add uuid=vif-uuid ipv4-allowed=comma separated list of ipv4-addresses
     <!--NeedCopy-->
    
  • Especifique la dirección IP IPv6. Por ejemplo:

     xe vif-param-add uuid=vif-uuid ipv6-allowed=comma separated list of ipv6-addresses
     <!--NeedCopy-->
    

Si restringe un VIF para que use dos o más direcciones IP, puede eliminar una de esas direcciones IP de la lista.

Ejecute el comando vif-param-remove para eliminar las direcciones IP de la lista existente. Realice una o varias de las siguientes acciones:

  • Especifique la dirección IP IPv4 que desea eliminar. Por ejemplo:

     xe vif-param-remove uuid=vif-uuid ipv4-allowed=comma separated list of ipv4-addresses
     <!--NeedCopy-->
    
  • Especifique la dirección IP IPv6 que desea eliminar. Por ejemplo:

     xe vif-param-remove uuid=vif-uuid ipv6-allowed=comma separated list of ipv6-addresses
     <!--NeedCopy-->
    

Evitar que una máquina virtual envíe o reciba tráfico de una red específica

El siguiente procedimiento evita que una máquina virtual se comunique a través de un VIF específico. Como un VIF se conecta a una red XenServer específica, puede usar este procedimiento para evitar que una máquina virtual envíe o reciba tráfico de una red específica. Esto proporciona un nivel de control más granular que deshabilitar una red completa.

Si utiliza el comando CLI, no es necesario desconectar el VIF para establecer el modo de bloqueo del VIF. El comando cambia las reglas de filtrado mientras el VIF está en ejecución. En este caso, la conexión de red aún parece estar presente; sin embargo, el VIF descarta cualquier paquete que la VM intente enviar.

Sugerencia:

Para encontrar el UUID de un VIF, ejecute el comando xe vif-list en el host. El ID del dispositivo indica el número de dispositivo del VIF.

Para evitar que un VIF reciba tráfico, deshabilite el VIF conectado a la red de la que desea que la VM deje de recibir tráfico:

xe vif-param-set uuid=vif-uuid locking-mode=disabled
<!--NeedCopy-->

También puede deshabilitar el VIF en XenCenter seleccionando la interfaz de red virtual en la pestaña Redes de la VM y haciendo clic en Desactivar.

Eliminar la restricción de un VIF a una dirección IP

Para volver al estado predeterminado (original) del modo de bloqueo, utilice el siguiente procedimiento. De forma predeterminada, cuando crea una VIF, XenServer la configura para que no esté restringida a usar una dirección IP específica.

Para revertir una VIF a un estado desbloqueado, cambie el modo de bloqueo predeterminado de la VIF a desbloqueado. Si aún no está utilizando ese modo, ejecute el siguiente comando:

xe vif-param-set uuid=vif_uuid locking-mode=unlocked
<!--NeedCopy-->

Simplificar la configuración del modo de bloqueo de VIF en la nube

En lugar de ejecutar los comandos del modo de bloqueo de VIF para cada VIF, puede asegurarse de que todas las VIF estén deshabilitadas de forma predeterminada. Para ello, debe cambiar el filtrado de paquetes a nivel de red. Cambiar el filtrado de paquetes hace que la red de XenServer determine cómo se filtran los paquetes, como se describe en la sección anterior Cómo funciona el bloqueo de puertos de conmutador.

Específicamente, la configuración default-locking-mode de una red determina cómo se comportan las nuevas VIF con la configuración predeterminada. Siempre que el locking-mode de una VIF se establece en default, la VIF se refiere al modo de bloqueo de red (default-locking-mode) para determinar si debe filtrar y cómo los paquetes que viajan a través de la VIF:

  • Desbloqueado. Cuando el parámetro default-locking-mode de la red se establece en unlocked, XenServer permite que la VM envíe tráfico a cualquier dirección IP en la red a la que se conecta la VIF.

  • Deshabilitado. Cuando el parámetro default-locking-mode se establece en disabled, XenServer aplica una regla de filtrado para que la VIF descarte todo el tráfico.

De forma predeterminada, el default-locking-mode para todas las redes creadas en XenCenter y utilizando la CLI se establece en unlocked.

Al establecer el modo de bloqueo de la VIF en su valor predeterminado (network_default), puede crear una configuración predeterminada básica (a nivel de red) para todas las VIF recién creadas que se conectan a una red específica.

Esta ilustración muestra cómo, cuando el locking-mode de una VIF se establece en su configuración predeterminada (network_default), la VIF utiliza la red default-locking-mode para determinar su comportamiento.

Esta ilustración muestra cómo una VIF, cuando se configura en su ajuste predeterminado (locking-mode=network_default), comprueba la configuración asociada con el modo de bloqueo predeterminado. En esta ilustración, la red está configurada en default-locking-mode=disabled, por lo que no puede pasar tráfico a través de la VIF. ](/es-es/xenserver/9/media/networking-cloud-network-vif-locking-mode.png)

Por ejemplo, de forma predeterminada, las VIF se crean con su locking-mode establecido en network_default. Si establece el default-locking-mode de una red en disabled, cualquier VIF nueva para la que no haya configurado el modo de bloqueo se deshabilitará. Las VIF permanecen deshabilitadas hasta que (a) cambie el parámetro locking-mode de la VIF individual o (b) establezca explícitamente el locking-mode de la VIF en unlocked. Esto es útil cuando confía lo suficiente en una VM específica como para no querer filtrar su tráfico en absoluto.

Para cambiar la configuración del modo de bloqueo predeterminado de una red:

Después de crear la red, cambie el modo de bloqueo predeterminado ejecutando el siguiente comando:

xe network-param-set uuid=network-uuid default-locking-mode=[unlocked|disabled]
<!--NeedCopy-->

Nota:

Para obtener el UUID de una red, ejecute el comando xe network-list. Este comando muestra los UUID de todas las redes en el host donde ejecutó el comando.

Para comprobar la configuración del modo de bloqueo predeterminado de una red:

Ejecute uno de los siguientes comandos:

xe network-param-get uuid=network-uuid param-name=default-locking-mode
<!--NeedCopy-->

O

xe network-list uuid=network-uuid params=default-locking-mode
<!--NeedCopy-->

Usar la configuración de red para el filtrado de tráfico de VIF

El siguiente procedimiento indica a un VIF en una máquina virtual que utilice la configuración de red de XenServer default-locking-mode en la propia red para determinar cómo filtrar el tráfico.

  1. Cambie el estado de bloqueo de VIF a network_default, si aún no está utilizando ese modo, ejecutando el siguiente comando:

    xe vif-param-set uuid=vif_uuid locking-mode=network_default
    <!--NeedCopy-->
    
  2. Cambie el modo de bloqueo predeterminado a unlocked, si aún no está utilizando ese modo, ejecutando el siguiente comando:

    xe network-param-set uuid=network-uuid default-locking-mode=unlocked
    <!--NeedCopy-->