Verwalten von Netzwerken

Die Netzwerkkonfigurationsverfahren in diesem Abschnitt unterscheiden sich je nachdem, ob Sie einen eigenständigen Server oder einen Server konfigurieren, der Teil eines Ressourcenpools ist.

Erstellen von Netzwerken auf einem eigenständigen Server

Da während der Host-Installation für jedes PIF externe Netzwerke erstellt werden, ist das Erstellen zusätzlicher Netzwerke normalerweise nur erforderlich, um:

• Verwenden Sie ein privates Netzwerk

• Unterstützt erweiterte Vorgänge wie VLANs oder NIC-Bonding

Informationen zum Hinzufügen oder Löschen von Netzwerken mit XenCenter finden Sie unter Hinzufügen eines neuen Netzwerks in der XenCenter-Dokumentation.

Öffnen Sie die Textkonsole des Citrix Hypervisor-Servers.

Erstellen Sie das Netzwerk mit dem Befehl network-create, der die UUID des neu erstellten Netzwerks zurückgibt:

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

Zu diesem Zeitpunkt ist das Netzwerk nicht mit einem PIF verbunden und daher intern.

Erstellen von Netzwerken in Ressourcenpools

Alle Citrix Hypervisor-Server in einem Ressourcenpool müssen über dieselbe Anzahl physischer NICs verfügen. Diese Anforderung wird nicht strikt durchgesetzt, wenn ein Host mit einem Pool verbunden ist. Eine der NICs ist immer als Verwaltungsschnittstelle vorgesehen, die für den Citrix Hypervisor-Verwaltungsverkehr verwendet wird.

Da sich alle Hosts in einem Pool ein gemeinsames Netzwerk teilen. Es ist wichtig, dieselbe physische Netzwerkkonfiguration für Citrix Hypervisor-Server in einem Pool zu haben. PIFs auf den einzelnen Hosts werden basierend auf dem Gerätenamen mit poolweiten Netzwerken verbunden. Beispielsweise haben alle Citrix Hypervisor-Server in einem Pool mit eth0-NIC ein entsprechendes PIF, das an das poolweite Netzwerk Network 0 angeschlossen ist. Gleiches gilt für Hosts mit eth1-NICs und anderen NICs Network 1, die in mindestens einem Citrix Hypervisor-Server im Pool vorhanden sind.

Wenn ein Citrix Hypervisor-Server über eine andere Anzahl von Netzwerkkarten verfügt als andere Hosts im Pool, können Komplikationen auftreten. Die Komplikationen können auftreten, da nicht alle Pool-Netzwerke für alle Pool-Hosts gültig sind. Wenn sich beispielsweise die Hosts host1 und host2 im selben Pool befinden und host1 über vier Netzwerkkarten verfügt und host2 nur über zwei verfügt, sind nur die Netzwerke, die mit PIFs verbunden sind, die eth0 und eth1 entsprechen, auf host2gültig. Virtuelle Rechner auf host1 mit VIFs, die mit Netzwerken verbunden sind, die eth2 und eth3 entsprechen, können nicht auf Host host2migriert werden.

Erstellen von VLANs

Für Server in einem Ressourcenpool können Sie den Befehl pool-vlan-create verwenden. Dieser Befehl erstellt das VLAN und erstellt und fügt automatisch die erforderlichen PIFs auf den Hosts im Pool ein. Weitere Informationen finden Sie unter pool-vlan-create.

Öffnen Sie die Citrix Hypervisor-Serverkonsole.

Erstellen Sie ein Netzwerk für die Verwendung mit dem VLAN. Die UUID des neuen Netzwerks wird zurückgegeben:

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

Verwenden Sie den Befehl pif-list, um die UUID der PIF zu finden, der der physischen Netzwerkkarte entspricht, die das gewünschte VLAN-Tag unterstützt. Die UUIDs und Gerätenamen aller PIFs werden zurückgegeben, einschließlich aller vorhandenen VLANs:

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

Erstellen Sie ein VLAN-Objekt, das den gewünschten physischen PIF- und VLAN-Tag auf allen VMs angibt, die mit dem neuen VLAN verbunden werden sollen. Ein neuer PIF wird erstellt und an das angegebene Netzwerk angeschlossen. Die UUID des neuen PIF-Objekts wird zurückgegeben.

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

Hängen Sie VM-VIFs an das neue Netzwerk an. Weitere Informationen finden Sie unter Erstellen von Netzwerken auf einem eigenständigen Server.

Erstellen von NIC-Bindungen auf einem eigenständigen Host

Wir empfehlen die Verwendung von XenCenter zum Erstellen von NIC-Bonds. Weitere Informationen finden Sie unter Konfigurieren von NICs.

In diesem Abschnitt wird beschrieben, wie Sie die xe CLI verwenden, um NIC-Schnittstellen auf Citrix Hypervisor-Servern zu verbinden, die sich nicht in einem Pool befinden. Informationen zur Verwendung der xe CLI zum Erstellen von NIC-Bonds auf Citrix Hypervisor-Servern, die einen Ressourcenpool umfassen, finden Sie unter Erstellen von NIC-Bondy in Ressourcenpools.

Erstellen einer NIC-Verbindung

Wenn Sie eine Netzwerkkarte binden, absorbiert die Bindung den PIF/NIC, der als Verwaltungsschnittstelle verwendet wird. Die Verwaltungsschnittstelle wird automatisch auf den Bond-PIF verschoben.

1. Verwenden Sie den Befehl network-create, um ein Netzwerk für die Verwendung mit der gebundenen NIC zu erstellen. Die UUID des neuen Netzwerks wird zurückgegeben:

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

2. Verwenden Sie den Befehl pif-list, um die UUIDs der PIFs zu bestimmen, die in der Bindung verwendet werden sollen:

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

3. Führen Sie einen der folgenden Schritte aus:

   • Um die Bindung im Aktiv-Aktiv-Modus (Standard) zu konfigurieren, verwenden Sie den Befehl bond-create, um die Bindung zu erstellen. Trennen Sie die Parameter durch Kommas und geben Sie die neu erstellte Netzwerk-UUID und die UUIDs der zu verbindenden PIFs an:

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

     Geben Sie zwei UUIDs ein, wenn Sie zwei NICs und vier UUIDs verbinden, wenn Sie vier Netzwerkkarten verbinden. Die UUID für die Bindung wird nach Ausführung des Befehls zurückgegeben.

   • Um die Bindung im Aktiv-Passiv- oder LACP-Bond-Modus zu konfigurieren, verwenden Sie dieselbe Syntax, fügen Sie den optionalen Parameter mode hinzu und geben Sie lacp oder active-backup an:

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

Steuern Sie die MAC-Adresse der Bindung

Wenn Sie die Verwaltungsschnittstelle verbinden, wird die verwendete PIF/NIC als Verwaltungsschnittstelle subsumiert. Wenn der Host DHCP verwendet, entspricht die MAC-Adresse der Bindung der verwendeten PIF/NIC. Die IP-Adresse der Verwaltungsschnittstelle kann unverändert bleiben.

Sie können die MAC-Adresse der Bindung so ändern, dass sie sich von der MAC-Adresse für die (aktuelle) Verwaltungsschnittstellen-NIC unterscheidet. Da die Bindung jedoch aktiviert ist und sich die verwendete MAC/IP-Adresse ändert, werden vorhandene Netzwerksitzungen zum Host verworfen.

Sie können die MAC-Adresse für einen Bond auf zwei Arten steuern:

• Im Befehl bond-create kann ein optionaler Parameter mac angegeben werden. Mit diesem Parameter können Sie die Bond-MAC-Adresse auf eine beliebige Adresse setzen.

• Wenn der Parameter mac nicht angegeben ist, verwendet Citrix Hypervisor die MAC-Adresse der Verwaltungsschnittstelle, wenn es sich um eine der Schnittstellen in der Bindung handelt. Wenn die Verwaltungsschnittstelle nicht Teil des Bonds ist, sondern eine andere Verwaltungsschnittstelle, verwendet die Bindung die MAC-Adresse (und auch die IP-Adresse) dieser Verwaltungsschnittstelle. Wenn keine der Netzwerkkarten in der Bindung eine Verwaltungsschnittstelle ist, verwendet die Bindung den MAC der zuerst benannten NIC.

NIC-Bonds rückgängig machen

Beim Wiederherstellen des Citrix Hypervisor-Servers auf eine nicht gebundene Konfiguration konfiguriert der Befehl bond-destroy automatisch die primäre Netzwerkkarte als Schnittstelle für die Verwaltungsschnittstelle. Daher werden alle VIFs auf die Verwaltungsschnittstelle verschoben. Wenn sich die Verwaltungsschnittstelle eines Hosts auf einer getaggten VLAN-gebundenen Schnittstelle befindet, wird das Verwaltungs-VLAN beim Ausführen von bond-destroy auf die primäre Netzwerkkarte verschoben.

Der Begriff primäre Netzwerkkarte bezieht sich auf den PIF, aus dem die MAC- und IP-Konfiguration beim Erstellen der Bindung kopiert wurde. Beim Verbinden von zwei NICs lautet die primäre Netzwerkkarte:

1. Die Netzwerkkarte der Verwaltungsschnittstelle (wenn die Verwaltungsschnittstelle eine der gebundenen NICs ist).

2. Jede andere Netzwerkkarte mit einer IP-Adresse (wenn die Verwaltungsschnittstelle nicht Teil der Bindung war).

3. Die erste benannte NIC. Sie können herausfinden, um welches es sich handelt, indem Sie Folgendes ausführen:

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

NIC-Bindungen in Ressourcenpools erstellen

Erstellen Sie nach Möglichkeit NIC-Bindungen als Teil der anfänglichen Erstellung eines Ressourcenpools, bevor Sie dem Pool weitere Hosts hinzufügen oder VMs erstellen. Dadurch kann die Bond-Konfiguration automatisch auf Hosts repliziert werden, wenn sie mit dem Pool verbunden werden, und reduziert die Anzahl der erforderlichen Schritte.

Das Hinzufügen einer NIC-Bindung zu einem vorhandenen Pool erfordert eine der folgenden Optionen:

• Verwenden der CLI zum Konfigurieren der Bonds auf dem Master und dann auf jedem Mitglied des Pools.

• Verwenden der CLI, um Bonds auf dem Master zu konfigurieren und dann jedes Poolmitglied neu zu starten, sodass es seine Einstellungen vom Master erbt.

• Verwenden von XenCenter zum Konfigurieren der Bonds auf dem Master. XenCenter synchronisiert die Netzwerkeinstellungen auf den Mitgliedsservern automatisch mit dem Master, sodass Sie die Mitgliedsserver nicht neu starten müssen.

Zur Vereinfachung und zur Vermeidung von Fehlkonfigurationen empfehlen wir die Verwendung von XenCenter zum Erstellen von NIC-Bonds. Weitere Informationen finden Sie unter Konfigurieren von NICs.

In diesem Abschnitt wird die Verwendung der xe CLI zum Erstellen gebundener NIC-Schnittstellen auf Citrix Hypervisor-Servern beschrieben, die einen Ressourcenpool umfassen. Informationen zur Verwendung der xe CLI zum Erstellen von NIC-Bindungen auf einem eigenständigen Host finden Sie unter Erstellen von NIC-Bonds auf einem eigenständigen Host.

Warnung:

Versuchen Sie nicht, Netzwerkbindungen zu erstellen, wenn Hochverfügbarkeit aktiviert ist. Der Prozess der Bond-Erstellung stört den laufenden Heartbeat mit hoher Verfügbarkeit und führt dazu, dass Hosts sich selbst abgrenzen (sich selbst herunterfahren). Die Hosts können nicht ordnungsgemäß neu gestartet werden und benötigen möglicherweise den Befehl host-emergency-ha-disable zum Wiederherstellen.

Wählen Sie den Host aus, den Sie Master werden möchten. Der Masterhost gehört standardmäßig zu einem unbenannten Pool. Um einen Ressourcenpool mit der CLI zu erstellen, benennen Sie den vorhandenen namenlosen Pool um:

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

Erstellen Sie die NIC-Bindung wie unter Erstellen einer NIC-Verbindungbeschrieben.

Öffnen Sie eine Konsole auf einem Host, dem Sie dem Pool beitreten möchten, und führen Sie den Befehl aus:

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

Die Netzwerk- und Bondinformationen werden automatisch auf den neuen Host repliziert. Die Verwaltungsschnittstelle wird automatisch von der Host-Netzwerkkarte, auf der sie ursprünglich konfiguriert wurde, in das gebundene PIF verschoben. Das heißt, die Verwaltungsschnittstelle wird nun in den Bond aufgenommen, sodass der gesamte Bond als Verwaltungsschnittstelle fungiert.

Verwenden Sie den Befehl host-list, um die UUID des zu konfigurierenden Hosts zu finden:

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

Warnung:

Versuchen Sie nicht, Netzwerkbindungen zu erstellen, solange Hochverfügbarkeit aktiviert ist. Der Prozess der Bond-Erstellung stört den laufenden Heartbeat mit hoher Verfügbarkeit und führt dazu, dass Hosts sich selbst abgrenzen (sich selbst herunterfahren). Die Hosts können möglicherweise nicht ordnungsgemäß neu gestartet werden, und Sie müssen den Befehl host-emergency-ha-disable zum Wiederherstellen ausführen.

Konfigurieren einer dedizierten Speicher-NIC

Sie können XenCenter oder die xe CLI verwenden, um einer NIC eine IP-Adresse zuzuweisen und sie einer bestimmten Funktion wie Speicherverkehr zuzuweisen. Wenn Sie eine Netzwerkkarte mit einer IP-Adresse konfigurieren, erstellen Sie dazu eine sekundäre Schnittstelle. (Der IP-fähige NIC Citrix Hypervisor, der für die Verwaltung verwendet wird, wird als Verwaltungsschnittstelle bezeichnet.)

Wenn Sie eine sekundäre Schnittstelle für einen bestimmten Zweck reservieren möchten, stellen Sie sicher, dass die entsprechende Netzwerkkonfiguration vorhanden ist. Dadurch wird sichergestellt, dass die Netzwerkkarte nur für den gewünschten Datenverkehr verwendet wird. Um eine Netzwerkkarte für den Speicherverkehr zuzuweisen, konfigurieren Sie die Netzwerkkarte, das Speicherziel, den Switch und das VLAN so, dass auf das Ziel nur über die zugewiesene Netzwerkkarte zugegriffen werden kann. Wenn Ihre physische und IP-Konfiguration den über die Speicher-NIC gesendeten Datenverkehr nicht einschränkt, können Sie Datenverkehr, z. B. Verwaltungsdatenverkehr, über die sekundäre Schnittstelle senden.

Wenn Sie eine neue sekundäre Schnittstelle für den Speicherverkehr erstellen, müssen Sie ihr eine IP-Adresse zuweisen, die lautet:

• im selben Subnetz wie der Speichercontroller, falls zutreffend, und

• Nicht im selben Subnetz wie alle anderen sekundären Schnittstellen oder die Verwaltungsschnittstelle.

Wenn Sie sekundäre Schnittstellen konfigurieren, muss sich jede sekundäre Schnittstelle in einem separaten Subnetz befinden. Wenn Sie beispielsweise zwei weitere sekundäre Schnittstellen für den Speicher konfigurieren möchten, benötigen Sie IP-Adressen in drei verschiedenen Subnetzen — ein Subnetz für die Verwaltungsschnittstelle, ein Subnetz für Secondary Interface 1 und ein Subnetz für Secondary Interface 2.

Wenn Sie Bonding für die Ausfallsicherheit Ihres Speicherverkehrs verwenden, sollten Sie die Verwendung von LACP anstelle der Linux-Brückenbindung in Betracht ziehen. Um LACP-Bonding zu verwenden, müssen Sie den vSwitch als Ihren Netzwerkstapel konfigurieren. Weitere Informationen finden Sie unter vSwitch-Netzwerke.

Hinweis:

Stellen Sie bei der Auswahl einer Netzwerkkarte zur Konfiguration als sekundäre Schnittstelle für die Verwendung mit iSCSI- oder NFS-SRs sicher, dass die dedizierte Netzwerkkarte ein separates IP-Subnetz verwendet, das nicht von der Verwaltungsschnittstelle weitergeleitet werden kann. Wenn dies nicht erzwungen wird, kann der Speicherverkehr aufgrund der Reihenfolge, in der Netzwerkschnittstellen initialisiert werden, nach einem Neustart des Hosts über die Hauptverwaltungsschnittstelle geleitet werden.

Stellen Sie sicher, dass sich der PIF in einem separaten Subnetz befindet oder dass das Routing entsprechend Ihrer Netzwerktopologie konfiguriert ist, um den gewünschten Datenverkehr über den ausgewählten PIF zu erzwingen.

Richten Sie eine IP-Konfiguration für den PIF ein und fügen Sie entsprechende Werte für den Modus-Parameter hinzu. Wenn Sie statische IP-Adressierung verwenden, fügen Sie die IP-, Netmask-, Gateway- und DNS-Parameter hinzu:

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

Setzen Sie den Parameter disallow-unplug des PIF auf 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-->

Wenn Sie eine sekundäre Schnittstelle für Speicher verwenden möchten, die auch von der Verwaltungsschnittstelle geroutet werden kann (wenn Sie bedenken, dass diese Konfiguration nicht die beste Vorgehensweise ist), haben Sie zwei Möglichkeiten:

• Stellen Sie nach einem Neustart des Hosts sicher, dass die sekundäre Schnittstelle korrekt konfiguriert ist. Verwenden Sie die Befehle xe pbd-unplug und xe pbd-plug, um die Speicherverbindungen auf dem Host neu zu initialisieren. Dieser Befehl startet die Speicherverbindung neu und leitet sie über die richtige Schnittstelle weiter.

• Sie können auch xe pif-forget verwenden, um die Schnittstelle aus der Citrix Hypervisor Datenbank zu löschen und sie manuell in der Steuerdomäne zu konfigurieren. xe pif-forget ist eine erweiterte Option und erfordert, dass Sie mit der manuellen Konfiguration von Linux-Netzwerken vertraut sind.

SR-IOV-fähige NICs verwenden

Single Root I/O Virtualization (SR-IOV) ist eine Virtualisierungstechnologie, mit der ein einzelnes PCI-Gerät als mehrere PCI-Geräte auf dem physischen System angezeigt werden kann. Das eigentliche physische Gerät ist als physische Funktion (PF) bekannt, während die anderen als virtuelle Funktionen (VF) bekannt sind. Der Hypervisor kann einer virtuellen Maschine (VM) eine oder mehrere VFs zuweisen: Der Gast kann das Gerät dann so verwenden, als wäre es direkt zugewiesen.

Durch Zuweisen einer oder mehrerer NIC-VFs zu einer VM kann der Netzwerkverkehr den virtuellen Switch Bypass. Bei der Konfiguration verhält sich jede VM so, als würde sie die NIC direkt verwenden, wodurch der Verarbeitungsaufwand reduziert und die Leistung verbessert wird.

Vorteile von SR-IOV

Ein SR-IOV-VF hat eine bessere Leistung als VIF. Es kann die hardwarebasierte Trennung zwischen dem Datenverkehr von verschiedenen VMs über dieselbe Netzwerkkarte sicherstellen (unter Umgehung des Citrix Hypervisor Netzwerkstapels).

Mit dieser Funktion können Sie:

• Aktivieren Sie SR-IOV auf NICs, die SR-IOV unterstützen.

• Deaktivieren Sie SR-IOV auf NICs, die SR-IOV unterstützen.

• Verwalten Sie SR-IOV-VFs als VF-Ressourcenpool.

• Weisen Sie SR-IOV-VFs einer VM zu.

• Konfigurieren Sie SR-IOV-VFs (z. B. MAC-Adresse, VLAN, Rate).

• Führen Sie Tests durch, um zu überprüfen, ob SR-IOV als Teil des automatisierten Zertifizierungskits unterstützt wird.

Konfiguration der Anlage

Konfigurieren Sie die Hardwareplattform korrekt, um SR-IOV zu unterstützen. Die folgenden Technologien sind erforderlich:

• I/O-MMU-Virtualisierung (AMD-VI und Intel VT-d)

• Alternative Routing-ID-Interpretation (ARI)

• Adressübersetzungsdienste (ATS)

• Zugriffssteuerungsdienste (ACS)

In der mit Ihrem System gelieferten Dokumentation finden Sie Informationen zur Konfiguration des BIOS, um die genannten Technologien zu ermöglichen.

Ermöglichen eines SR-IOV-Netzwerks auf einer NIC

Verwenden Sie in XenCenter den Assistenten für Neues Netzwerk auf der Registerkarte Netzwerk, um ein SR-IOV-Netzwerk auf einer Netzwerkkarte zu erstellen und zu aktivieren.

Weisen Sie der virtuellen Schnittstelle ein SR-IOV-Netzwerk zu (VM-Ebene)

Verwenden Sie in XenCenter auf VM-Ebene den Assistenten zum Hinzufügen einer virtuellen Schnittstelle auf der Registerkarte Netzwerk, um ein SR-IOV-fähiges Netzwerk als virtuelle Schnittstelle für diese VM hinzuzufügen. Weitere Informationen finden Sie unter Neues Netzwerk hinzufügen.

Unterstützte NICs und Gäste

Eine Liste der unterstützten Hardwareplattformen und Netzwerkkarten finden Sie unter Hardwarekompatibilitätsliste. In der Dokumentation des Anbieters für einen bestimmten Gast erfahren Sie, ob er SR-IOV unterstützt.

Einschränkungen

• Für bestimmte Netzwerkkarten, die Legacy-Treiber verwenden (z. B. Intel I350-Familie), muss der Host neu gestartet werden, um SR-IOV auf diesen Geräten zu aktivieren oder zu deaktivieren.

• Nur HVM-Gäste werden mit SR-IOV unterstützt.

• Ein SR-IOV-Netzwerk auf Poolebene mit unterschiedlichen NIC-Typen wird nicht unterstützt.

• Ein SR-IOV-VF und ein normaler VIF von derselben Netzwerkkarte können aufgrund der Einschränkungen der NIC-Hardware möglicherweise nicht miteinander kommunizieren. Um diesen Hosts die Kommunikation zu ermöglichen, stellen Sie sicher, dass die Kommunikation das Muster VF zu VF oder VIF zu VIF und nicht VF zu VIF verwendet.

• Die Quality of Service-Einstellungen für einige SR-IOV-VFs werden nicht wirksam, da sie keine Begrenzung der Netzwerkgeschwindigkeit unterstützen.

• Die Durchführung von Livemigration, Suspend und Checkpoint wird auf virtuellen Rechnern, die einen SR-IOV-VF verwenden, nicht unterstützt.

• SR-IOV-VFs unterstützen kein Hot-Plugging.

• Bei einigen NICs mit älteren NIC-Treibern kann ein Neustart auch nach einem Neustart des Hosts erforderlich sein, was darauf hinweist, dass die Netzwerkkarte SR-IOV nicht aktivieren kann.

• In früheren Versionen erstellte VMs können diese Funktion nicht von XenCenter aus verwenden.

• Wenn Ihre VM über einen SR-IOV-VF verfügt, sind Funktionen, die eine Livemigration erfordern, nicht möglich. Dies liegt daran, dass die VM direkt an den physischen SR-IOV-fähigen NIC-VF gebunden ist.

• Hardwarebeschränkung: Die SR-IOV-Funktion ist darauf angewiesen, dass der Controller die Gerätefunktionen innerhalb von 100 ms in einen makellosen Zustand zurücksetzt, wenn dies vom Hypervisor mithilfe von Function Level Reset (FLR) angefordert wird.

• SR-IOV kann in einer Umgebung eingesetzt werden, die Hochverfügbarkeit nutzt. SR-IOV wird jedoch in der Kapazitätsplanung nicht berücksichtigt. VMs, denen SR-IOV-VFs zugewiesen sind, werden nach bestem Ermessen neu gestartet, wenn sich im Pool ein Host mit entsprechenden Ressourcen befindet. Zu diesen Ressourcen gehören SR-IOV-fähig im richtigen Netzwerk und eine kostenlose VF.

Konfigurieren von SR-IOV-VFs für Legacy-Treiber

In der Regel kann die maximale Anzahl von VFs, die eine NIC unterstützen kann, automatisch bestimmt werden. Für NICs, die Legacy-Treiber verwenden (z. B. Intel I350-Familie), ist der Grenzwert in der Treibermodul-Konfigurationsdatei definiert. Das Limit muss möglicherweise manuell angepasst werden. Um es auf das Maximum zu setzen, öffnen Sie die Datei mit einem Editor und ändern Sie die Zeile ab:

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

Um beispielsweise die maximale VFs auf 4 festzulegen, damit die igb-Treiberbearbeitung /etc/modprobe.d/igb.conf liest:

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

Hinweise:

• Der Wert muss kleiner oder gleich dem Wert in der Zeile sein VFs-maxvfs-by-default.

• Ändern Sie keine andere Zeile in diesen Dateien.

• Nehmen Sie die Änderungen vor, bevor Sie SR-IOV aktivieren.

CLI

Unter SR-IOV-Befehle finden Sie CLI-Anweisungen zum Erstellen, Löschen, Anzeigen von SR-IOV-Netzwerken und Zuweisen eines SR-IOV-VF zu einer VM.

Steuern Sie die Rate der ausgehenden Daten (QoS)

Um die Menge der ausgehenden Daten zu begrenzen, die eine VM pro Sekunde senden kann, legen Sie einen optionalen Quality of Service (QoS) -Wert für virtuelle VM-Schnittstellen (VIFs) fest. Mit dieser Einstellung können Sie eine maximale Übertragungsrate für ausgehende Pakete in Kilobyte pro Sekunde angeben.

Der Quality of Service-Wert begrenzt die Übertragungsrate von der VM. Die Einstellung Quality of Service schränkt die Datenmenge, die die VM empfangen kann, nicht ein. Wenn ein solches Limit erwünscht ist, empfehlen wir, die Rate eingehender Pakete weiter oben im Netzwerk zu begrenzen (z. B. auf Switch-Ebene).

Abhängig vom im Pool konfigurierten Netzwerkstapel können Sie den Wert Quality of Service auf virtuellen VM-Schnittstellen (VIFs) an einer von zwei Stellen festlegen. Sie können diesen Wert entweder mit der xe CLI oder in XenCenter festlegen.

• XenCenter Sie können den Grenzwert für die Quality of Service-Übertragungsrate im Eigenschaftendialogfeld der virtuellen Schnittstelle festlegen.
• xe-Befehle Sie können die Quality of Service-Übertragungsrate über die CLI mithilfe der Befehle im folgenden Abschnitt festlegen.

Beispiel eines CLI-Befehls für QoS

Um eine VIF über die CLI auf eine maximale Übertragungsrate von 100 Kilobyte pro Sekunde zu beschränken, verwenden Sie den Befehl 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-->

Hinweis:

Der Parameter kbps gibt Kilobyte pro Sekunde (Kbps) an, nicht Kilobit pro Sekunde (kbps).

Ändern der Netzwerkkonfigurationsoptionen

In diesem Abschnitt wird erläutert, wie Sie die Netzwerkkonfiguration Ihres Citrix Hypervisor-Servers ändern können. Folgendes ist eingeschlossen:

• Änderung des Hostnamens (d. h. des Domain Name System (DNS) -Namens)

• Hinzufügen oder Löschen von DNS-Servern

• IP-Adressen ändern

• Ändern der Netzwerkkarte, die als Verwaltungsschnittstelle verwendet wird

• Hinzufügen einer neuen physischen Netzwerkkarte zum Server

• Hinzufügen eines Zwecks zu einem Netzwerk

• ARP-Filterung aktivieren (Switch-Port-Sperrung)

Hostname

Der System-Hostname, auch als Domain- oder DNS-Name bekannt, wird in der poolweiten Datenbank definiert und mit dem CLI-Befehl xe host-set-hostname-livewie folgt geändert:

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

Der zugrunde liegende Hostname der Steuerdomäne ändert sich dynamisch, um den neuen Hostnamen wiederzugeben.

DNS-Server

Verwenden Sie den Befehl pif-reconfigure-ip, um DNS-Server in der IP-Adressierungskonfiguration des Citrix Hypervisor-Servers hinzuzufügen oder zu löschen. Zum Beispiel für ein PIF mit einer statischen IP:

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

Ändern der IP-Adresskonfiguration für einen eigenständigen Host

Sie können die xe-CLI verwenden, um die Konfiguration der Netzwerkschnittstelle zu ändern. Ändern Sie die zugrunde liegenden Netzwerkkonfigurationsskripte nicht direkt.

Um die IP-Adresskonfiguration eines PIF zu ändern, verwenden Sie den CLI-Befehl pif-reconfigure-ip. Einzelheiten zu den Parametern des Befehls pif-reconfigure-ip finden Sie unter pif-reconfigure-ip. Im folgenden Abschnitt finden Sie Informationen zum Ändern von Host-IP-Adressen in Ressourcenpools.

Ändern der IP-Adresskonfiguration in Ressourcenpools

Citrix Hypervisor-Server in Ressourcenpools verfügen über eine einzige Verwaltungs-IP-Adresse, die für die Verwaltung und Kommunikation zu und von anderen Hosts im Pool verwendet wird. Die Schritte, die erforderlich sind, um die IP-Adresse der Verwaltungsschnittstelle eines Hosts zu ändern, sind für Master- und andere Hosts unterschiedlich.

Hinweis:

Sie müssen vorsichtig sein, wenn Sie die IP-Adresse eines Servers und andere Netzwerkparameter ändern. Abhängig von der Netzwerktopologie und den vorgenommenen Änderungen können Verbindungen zum Netzwerkspeicher verloren gehen. In diesem Fall muss der Speicher mit der Funktion Speicher reparieren in XenCenter oder mit dem CLI-Befehl pbd-plug neu angeschlossen werden. Aus diesem Grund empfehlen wir, dass Sie VMs vom Server weg migrieren, bevor Sie die IP-Konfiguration ändern.

Verwenden Sie den CLI-Befehl pif-reconfigure-ip, um die IP-Adresse wie gewünscht festzulegen. Einzelheiten zu den Parametern des Befehls pif-reconfigure-ip finden Sie unter pif-reconfigure-ip.

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

Verwenden Sie den CLI-Befehl host-list, um zu bestätigen, dass der Mitgliedshost erfolgreich wieder mit dem Masterhost verbunden ist, indem Sie überprüfen, ob alle anderen Citrix Hypervisor-Server im Pool sichtbar sind:

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

Das Ändern der IP-Adresse des Citrix Hypervisor-Masterservers erfordert zusätzliche Schritte. Dies liegt daran, dass jedes Poolmitglied die angekündigte IP-Adresse des Poolmasters für die Kommunikation verwendet. Die Poolmitglieder wissen nicht, wie sie den Master kontaktieren können, wenn sich seine IP-Adresse ändert.

Verwenden Sie nach Möglichkeit eine dedizierte IP-Adresse, die sich für die Lebensdauer des Pools für Poolmaster wahrscheinlich nicht ändern wird.

Verwenden Sie den CLI-Befehl pif-reconfigure-ip, um die IP-Adresse wie gewünscht festzulegen:

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

Wenn sich die IP-Adresse des Poolmasters ändert, wechseln alle Mitgliedshosts in den Notfallmodus, wenn sie den Masterhost nicht kontaktieren können.

Verwenden Sie auf dem Poolmaster den Befehl pool-recover-slaves, um den Master zu zwingen, jedes Poolmitglied zu kontaktieren und es über die neue Master-IP-Adresse zu informieren:

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

Verwaltungsoberfläche

Wenn Sie Citrix Hypervisor auf einem Host installieren, wird eine seiner NICs als Verwaltungsschnittstelle festgelegt: die NIC, die für den Citrix Hypervisor-Verwaltungsverkehr verwendet wird. Die Verwaltungsschnittstelle wird für XenCenter und andere Management-API-Verbindungen zum Host (z. B. Citrix Virtual Apps and Desktops) und für die Host-zu-Host-Kommunikation verwendet.

Verwenden Sie den Befehl pif-list, um zu ermitteln, welcher PIF der NIC entspricht, die als Verwaltungsschnittstelle verwendet werden soll. Die UUID jedes PIF wird zurückgegeben.

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

Verwenden Sie den Befehl pif-param-list, um die IP-Adressierungskonfiguration für den PIF zu überprüfen, der für die Verwaltungsschnittstelle verwendet wird. Verwenden Sie ggf. den Befehl pif-reconfigure-ip, um die IP-Adressierung für den zu verwendenden PIF zu konfigurieren.

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

Verwenden Sie den CLI-Befehl host-management-reconfigure, um die für die Verwaltungsschnittstelle verwendete PIF zu ändern. Wenn dieser Host Teil eines Ressourcenpools ist, muss dieser Befehl auf der Mitgliedshost-Konsole ausgegeben werden:

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

Verwenden Sie den Befehl network-list, um zu ermitteln, welche PIF der Netzwerkkarte entspricht, die als Verwaltungsschnittstelle für alle Hosts im Pool verwendet werden soll. Die UUID des poolweiten Netzwerks wird zurückgegeben.

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

Verwenden Sie den Befehl network-param-list, um die PIF-UUIDs aller Hosts im Pool abzurufen. Verwenden Sie den Befehl pif-param-list, um die IP-Adressierungskonfiguration für das PIF für die Verwaltungsschnittstelle zu überprüfen. Verwenden Sie ggf. den Befehl pif-reconfigure-ip, um die IP-Adressierung für den zu verwendenden PIF zu konfigurieren.

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

Verwenden Sie den CLI-Befehl pool-management-reconfigure, um die PIF zu ändern, die für die in der Liste Netzwerke aufgeführte Verwaltungsschnittstelle verwendet wird.

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

Verwendung von Port 80 beschränken

Sie können entweder HTTPS über Port 443 oder HTTP über Port 80 verwenden, um mit Citrix Hypervisor zu kommunizieren. Aus Sicherheitsgründen können Sie den TCP-Port 80 auf der Verwaltungsschnittstelle schließen. Standardmäßig ist Port 80 immer noch geöffnet. Wenn Sie es schließen, müssen alle externen Clients, die die Management-API verwenden, HTTPS über Port 443 verwenden, um eine Verbindung mit Citrix Hypervisor herzustellen. Bevor Sie jedoch Port 80 schließen, überprüfen Sie, ob alle Ihre API-Clients (insbesondere Citrix Virtual Apps and Desktops) HTTPS über Port 443 verwenden können.

Informationen zum Schließen von Port 80 finden Sie unter https-only xe CLI-Befehl.

Deaktivieren des Verwaltungszugriffs

Verwenden Sie den CLI-Befehl host-management-disable, um den Remotezugriff auf die Verwaltungskonsole vollständig zu deaktivieren.

Warnung:

Wenn die Verwaltungsschnittstelle deaktiviert ist, müssen Sie sich auf der physischen Host-Konsole anmelden, um Verwaltungsaufgaben ausführen zu können. Externe Schnittstellen wie XenCenter funktionieren nicht, wenn die Verwaltungsschnittstelle deaktiviert ist.

Fügen Sie eine neue physische Netzwerkkarte hinzu

1. Installieren Sie wie gewohnt eine neue physische Netzwerkkarte auf Ihrem Citrix Hypervisor-Server.
2. Starten Sie Ihren Citrix Hypervisor-Server neu.

3. Listen Sie alle physischen Netzwerkkarten für diesen Citrix Hypervisor-Server auf, indem Sie den folgenden Befehl verwenden:

   xe pif-list host-uuid=<host_uuid>
   

4. Wenn Sie die zusätzliche Netzwerkkarte nicht sehen, suchen Sie mit dem folgenden Befehl nach neuen physischen Schnittstellen:

   xe pif-scan host-uuid=<host_uuid>
   

   Mit diesem Befehl wird ein neues PIF-Objekt für die neue NIC erstellt.

5. Listen Sie die physischen Netzwerkkarten auf dem Citrix Hypervisor-Server erneut auf, um zu überprüfen, ob die neue Netzwerkkarte sichtbar ist:

   xe pif-list host-uuid=<host_uuid>
   

6. Die neue PIF wird anfänglich als nicht verbunden (currently-attached ( RO): false) aufgeführt. Verwenden Sie den folgenden Befehl, um es aufzurufen:

   xe pif-plug uuid=<uuid_of_pif>
   

Alternativ können Sie XenCenter verwenden, um erneut nach neuen Netzwerkkarten zu suchen. Weitere Informationen finden Sie unter Konfiguration von Netzwerkkarten in der XenCenter-Dokumentation.

Entfernen einer physischen Netzwerkkarte

Stellen Sie vor dem Entfernen der Netzwerkkarte sicher, dass Sie die UUID des entsprechenden PIF kennen. Entfernen Sie die physische Netzwerkkarte wie gewohnt von Ihrem Citrix Hypervisor-Server. Führen Sie nach dem Neustart des Servers den xe-Befehl CLI aus pif-forget uuid=<UUID>, um das PIF-Objekt zu löschen.

Hinzufügen eines Zwecks zu einem Netzwerk

Der Netzwerkzweck kann verwendet werden, um einem Netzwerk zusätzliche Funktionen hinzuzufügen. Zum Beispiel die Möglichkeit, das Netzwerk zu verwenden, um NBD-Verbindungen herzustellen.

Verwenden Sie denxe network-param-add folgenden Befehl, um einen Netzwerkzweck hinzuzufügen:

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

Verwenden Sie denxe network-param-remove folgenden Befehl, um einen Netzwerkzweck zu löschen:

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

Derzeit sind die verfügbaren Werte für den Netzwerkzweck nbd und insecure_nbd. Weitere Informationen finden Sie im Citrix Hypervisor Changed Block Tracking Guide.

Switch Port-Verriegelung verwenden

Mit der Citrix Hypervisor Switch-Port-Sperrfunktion können Sie den Datenverkehr steuern, der von unbekannten, nicht vertrauenswürdigen oder potenziell feindlichen VMs gesendet wird, indem Sie deren Fähigkeit einschränken, so zu tun, als hätten sie eine MAC- oder IP-Adresse, die ihnen nicht zugewiesen wurde. Sie können die Befehle zum Sperren von Ports verwenden, um standardmäßig den gesamten Datenverkehr in einem Netzwerk zu blockieren oder bestimmte IP-Adressen zu definieren, von denen eine einzelne VM Datenverkehr senden darf.

Die Switch-Port-Sperrung ist eine Funktion, die für öffentliche Cloud-Dienstanbieter in Umgebungen entwickelt wurde, die sich mit internen Bedrohungen befassen. Diese Funktion unterstützt öffentliche Cloud-Dienstanbieter mit einer Netzwerkarchitektur, in der jede VM über eine öffentliche, mit dem Internet verbundene IP-Adresse verfügt. Da Cloud-Mandanten nicht vertrauenswürdig sind, können Sie Sicherheitsmaßnahmen wie den Spoofing-Schutz verwenden, um sicherzustellen, dass Mandanten andere virtuelle Maschinen in der Cloud nicht angreifen können.

Durch die Verwendung der Switch-Port-Sperrung können Sie Ihre Netzwerkkonfiguration vereinfachen, indem Sie allen Ihren Mandanten oder Gästen ermöglichen, dasselbe Layer-2-Netzwerk zu verwenden.

Eine der wichtigsten Funktionen der Port-Locking-Befehle ist, dass sie den Datenverkehr einschränken können, den ein nicht vertrauenswürdiger Gast sendet. Dies schränkt die Fähigkeit des Gastes ein, so zu tun, als hätte er eine MAC- oder IP-Adresse, die er nicht wirklich besitzt. Insbesondere können Sie diese Befehle verwenden, um zu verhindern, dass ein Gast:

• Anspruch auf eine andere IP- oder MAC-Adresse als die, die der Citrix Hypervisor-Administrator angegeben hat, dass sie verwendet werden kann

• Abfangen, Spoofing oder Unterbrechen des Datenverkehrs anderer VMs

Anforderungen

• Die Citrix Hypervisor Switch-Port-Sperrfunktion wird auf den Linux-Bridge- und vSwitch-Netzwerkstapeln unterstützt.

• Wenn Sie die rollenbasierte Zugriffssteuerung (RBAC) in Ihrer Umgebung aktivieren, muss der Benutzer, der die Switch-Port-Sperrung konfiguriert, mit einem Konto angemeldet sein, das mindestens eine Pool-Operator- oder Pool-Admin-Rolle hat. Wenn RBAC in Ihrer Umgebung nicht aktiviert ist, muss der Benutzer mit dem Root-Konto für den Poolmaster angemeldet sein.

• Wenn Sie die Switch-Port-Sperrbefehle ausführen, können Netzwerke online oder offline sein.

• Bei Windows-Gästen wird das Symbol für getrennte Netzwerke nur angezeigt, wenn die XenServer VM Tools auf dem Gast installiert sind.

Hinweise

Ohne Switch-Port-Sperrkonfigurationen sind VIFs auf “network_default” und Netzwerke auf “unlocked” gesetzt.

Die Konfiguration der Switch-Port-Sperrung wird nicht unterstützt, wenn Controller von Drittanbietern in der Umgebung verwendet werden.

Das Sperren von Switch-Ports verhindert nicht, dass Cloud-Mandanten:

• Durchführen eines Angriffs auf IP-Ebene auf einen anderen Mandanten/Benutzer. Die Switch-Port-Sperre verhindert jedoch, dass sie den Angriff auf IP-Ebene ausführen, wenn sie versuchen, dies auf folgende Weise zu tun, und die Switch-Port-Sperre konfiguriert ist: a) die Identität eines anderen Mandanten in der Cloud oder eines anderen Benutzers oder b) das Abfangen des für einen anderen Benutzer bestimmten Datenverkehrs.

• Erschöpfende Netzwerkressourcen.

• Empfang von Datenverkehr, der für andere virtuelle Maschinen bestimmt ist, durch normales Switch-Flutverhalten (für Broadcast-MAC-Adressen oder unbekannte Ziel-MAC-Adressen)

Ebenso schränkt die Switch-Port-Sperrung nicht ein, wohin eine VM Datenverkehr senden kann.

Hinweise zur Umsetzung

Sie können die Switch-Port-Sperrfunktion entweder mithilfe der Befehlszeile oder der Citrix Hypervisor-API implementieren. In großen Umgebungen, in denen die Automatisierung ein Hauptanliegen ist, ist die typischste Implementierungsmethode jedoch die Verwendung der API.

Beispiele

In diesem Abschnitt finden Sie Beispiele dafür, wie das Sperren von Switch-Ports bestimmte Arten von Angriffen verhindern kann. In diesen Beispielen ist VM-c eine virtuelle Maschine, die ein feindlicher Mandant (Tenant C) least und für Angriffe verwendet. VM-a und VM-b sind virtuelle Maschinen, die von nicht angreifenden Mandanten geleast werden.

Beispiel 1: Wie das Sperren von Switch-Ports die ARP-Spoofing-Verhinderung verhindern kann:

ARP-Spoofing wird verwendet, um auf die Versuche eines Angreifers hinzuweisen, seine MAC-Adresse mit der IP-Adresse eines anderen Knotens zu verknüpfen. ARP-Spoofing kann möglicherweise dazu führen, dass der Datenverkehr des Knotens stattdessen an den Angreifer gesendet wird. Um dieses Ziel zu erreichen, sendet der Angreifer gefälschte (gefälschte) ARP-Nachrichten an ein Ethernet-LAN.

Szenario:

Virtuelle Maschine A (VM-a) möchte IP-Verkehr von VM-a zur virtuellen Maschine B (VM-b) senden, indem sie ihn an die IP-Adresse von VM-b adressiert. Der Besitzer von Virtual Machine C möchte ARP-Spoofing verwenden, um so zu tun, als wäre seine VM, VM-c, tatsächlich VM-b.

1. VM-c sendet einen spekulativen Stream von ARP-Antworten an VM-a. In den ARP-Antworten wird behauptet, dass die MAC-Adresse in der Antwort (c_Mac) mit der IP-Adresse b_IP verknüpft ist

   Ergebnis: Da der Administrator die Switch-Port-Sperrung aktiviert hat, werden diese Pakete alle verworfen, da die Aktivierung der Switch-Port-Sperrung den Identitätswechsel verhindert.

2. VM-b sendet eine ARP-Antwort an VM-a und behauptet, dass die MAC-Adresse in der Antwort (b_Mac) mit der IP-Adresse b_IP verknüpft ist.

   Ergebnis: VM-a empfängt die ARP-Antwort von VM-b.

Beispiel 2: IP-Spoofing-Verhinderung:

IP-Adress-Spoofing ist ein Prozess, der die Identität von Paketen verbirgt, indem Internetprotokoll-Pakete (IP) mit einer gefälschten Quell-IP-Adresse erstellt werden.

Szenario:

Mandant C versucht, einen Denial-of-Service-Angriff durchzuführen, indem er seinen Host, Host-C, auf einem Remote-System verwendet, um seine Identität zu verschleiern.

Versuch 1:

Mandant C setzt die IP-Adresse und MAC-Adresse von Host-C auf die IP- und MAC-Adressen von VM-A (a_IP und a_Mac). Mandant C weist Host-C an, IP-Verkehr an ein Remote-System zu senden.

Ergebnis: Die Host-C-Pakete werden verworfen. Das liegt daran, dass der Administrator die Switch-Port-Sperrung aktiviert hat Die Host-C-Pakete werden verworfen, da die Aktivierung der Switch-Port-Sperrung den Identitätswechsel verhindert.

Versuch 2:

Mandant C setzt die IP-Adresse von Host-C auf die IP-Adresse von VM-A (a_IP) und behält ihren ursprünglichen c_Mac bei.

Mandant C weist Host-C an, IP-Verkehr an ein Remote-System zu senden.

Ergebnis: Die Host-C-Pakete werden verworfen. Dies liegt daran, dass der Administrator die Switch-Port-Sperrung aktiviert hat, wodurch Identitätswechsel verhindert werden.

Beispiel 3: Webhosting:

Szenario:

Alice ist Infrastrukturadministratorin.

Einer ihrer Mandanten, Mandant B, hostet mehrere Websites von seiner VM “VM-b” aus. Jede Website benötigt eine eigene IP-Adresse, die auf derselben virtuellen Netzwerkschnittstelle (VIF) gehostet wird.

Alice konfiguriert das VIF von Host-B neu, sodass es an einen einzigen MAC, aber viele IP-Adressen gebunden ist.

So funktioniert die Switch-Port-Verriegelung

Mit der Switch-Port-Sperrfunktion können Sie die Paketfilterung auf einer oder mehreren von zwei Ebenen steuern:

• VIF-Ebene. Die Einstellungen, die Sie im VIF konfigurieren, legen fest, wie Pakete gefiltert werden. Sie können das VIF so einstellen, dass verhindert wird, dass die VM Datenverkehr sendet, das VIF so einschränken, dass es nur Datenverkehr mit der zugewiesenen IP-Adresse senden kann, oder der VM erlauben, Datenverkehr an eine beliebige IP-Adresse im Netzwerk zu senden, die mit dem VIF verbunden ist.

• Netzwerk-Ebene. Das Citrix Hypervisor Netzwerk bestimmt, wie Pakete gefiltert werden. Wenn der Sperrmodus eines VIF auf eingestellt ist network_default, bezieht er sich auf die Sperreinstellung auf Netzwerkebene, um zu bestimmen, welcher Datenverkehr zugelassen werden soll.

Unabhängig davon, welchen Netzwerkstapel Sie verwenden, funktioniert die Funktion auf dieselbe Weise. Wie in den folgenden Abschnitten ausführlicher beschrieben, unterstützt die Linux-Brücke jedoch die Switch-Port-Sperrung in IPv6 nicht vollständig.

VIF-Sperrmodus-Zustände

Die Citrix Hypervisor Switch-Port-Sperrfunktion bietet einen Sperrmodus, mit dem Sie VIFs in vier verschiedenen Zuständen konfigurieren können. Diese Zustände gelten nur, wenn das VIF an eine laufende virtuelle Maschine angeschlossen ist.

• network_default. Wenn der Status der VIF auf network_default festgelegt ist, verwendet Citrix Hypervisor den Netzwerkparameter default-locking-mode, um zu bestimmen, ob und wie Pakete gefiltert werden, die durch die VIF übertragen werden. Das Verhalten hängt davon ab, ob für das zugehörige Netzwerk der Standard-Sperrmodus des Netzwerks auf Deaktiviert oder entsperrt eingestellt ist:

  -default-locking-mode=disabled, Citrix Hypervisor wendet eine Filterregel an, damit das VIF den gesamten Datenverkehr verwirft.

  -default-locking-mode= Entsperrt, Citrix Hypervisor entfernt alle mit dem VIF verknüpften Filterregeln. Standardmäßig ist der Standard-Sperrmodus Parameter auf unlocked eingestellt.

  Informationen zum Parameter default-locking-mode finden Sie unter Netzwerkbefehle.

  Der standardmäßige Sperrmodus des Netzwerks hat keine Auswirkung auf angeschlossene VIFs, deren Sperrzustand etwas anderes ist als network_default.

  Hinweis:

  Sie können default-locking-mode für ein Netzwerk, an das aktive VIFs angeschlossen sind, nicht ändern.

• Gesperrt. Citrix Hypervisor wendet Filterregeln an, sodass nur Datenverkehr, der an/von den angegebenen MAC- und IP-Adressen gesendet wird, über das VIF gesendet werden darf. Wenn in diesem Modus keine IP-Adressen angegeben sind, kann die VM keinen Datenverkehr über dieses VIF in diesem Netzwerk senden.

  Um die IP-Adressen anzugeben, von denen die VIF Datenverkehr akzeptiert, verwenden Sie die IPv4- oder IPv6-IP-Adressen mit den Parametern ipv4_allowed oder ipv6_allowed. Wenn Sie jedoch die Linux-Brücke konfiguriert haben, geben Sie keine IPv6-Adressen ein.

  Mit Citrix Hypervisor können Sie IPv6-Adressen eingeben, wenn die Linux-Brücke aktiv ist. Citrix Hypervisor kann jedoch nicht basierend auf den eingegebenen IPv6-Adressen filtern. Der Grund dafür ist, dass die Linux-Brücke keine Module zum Filtern von NDP-Paketen (NDP) hat. Daher kann kein vollständiger Schutz implementiert werden, und Gäste können sich als ein anderer Gast ausgeben, indem sie NDP-Pakete fälschen. Wenn Sie also auch nur eine IPv6-Adresse angeben, lässt Citrix Hypervisor den gesamten IPv6-Verkehr durch das VIF fließen. Wenn Sie keine IPv6-Adressen angeben, lässt Citrix Hypervisor keinen IPv6-Datenverkehr zum VIF passieren.

• Freigeschaltet. Der gesamte Netzwerkverkehr kann das VIF durchlaufen. Das heißt, es werden keine Filter auf Datenverkehr angewendet, der zum oder vom VIF geht.

• Deaktiviert. Es darf kein Verkehr durch das VIF fließen. (Das heißt, Citrix Hypervisor wendet eine Filterregel an, damit das VIF den gesamten Datenverkehr verwirft.)

Konfigurieren der Switch-Port-

In diesem Abschnitt werden drei verschiedene Verfahren beschrieben:

• Beschränken Sie VIFs auf die Verwendung einer bestimmten IP-Adresse

• Fügen Sie eine IP-Adresse zu einer vorhandenen Liste mit eingeschränkten Rechten hinzu. Zum Beispiel, um einer VIF eine IP-Adresse hinzuzufügen, wenn die VM läuft und mit dem Netzwerk verbunden ist (z. B. wenn Sie ein Netzwerk vorübergehend offline schalten).

• Entfernen einer IP-Adresse aus einer vorhandenen Liste mit eingeschränkten Rechten

Wenn der Sperrmodus eines VIF auf locked eingestellt ist, können nur die Adressen verwendet werden, die in den Parametern ipv4-allowed oder ipv6-allowed angegeben sind.

Da VIFs in einigen relativ seltenen Fällen mehr als eine IP-Adresse haben können, ist es möglich, mehrere IP-Adressen für ein VIF anzugeben.

Sie können diese Verfahren ausführen, bevor oder nachdem das VIF angeschlossen wurde (oder die VM gestartet wurde).

Ändern Sie den Standardsperrmodus in gesperrt, falls dieser Modus nicht bereits verwendet wird, indem Sie den folgenden Befehl ausführen:

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

vif-uuid stellt die UUID der VIF dar, die Sie zum Senden von Datenverkehr zulassen möchten. Um die UUID zu erhalten, führen Sie den xe-Befehl vif-list auf dem Host aus. vm-uuid Zeigt die virtuelle Maschine an, für die die Informationen angezeigt werden. Die Geräte-ID zeigt die Gerätenummer des VIF an.

Führen Sie den Befehl vif-param-set aus, um die IP-Adressen anzugeben, von denen die virtuelle Maschine Datenverkehr senden kann. Führen Sie eine oder mehrere der folgenden Aktionen aus:

• Geben Sie ein oder mehrere IPv4-IP-Adressen-Ziele an. Beispiel:

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

• Geben Sie ein oder mehrere IPv6-IP-Adressen-Ziele an. Beispiel:

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

Sie können mehrere IP-Adressen angeben, indem Sie sie durch ein Komma trennen, wie im vorherigen Beispiel gezeigt.

Nachdem Sie das Verfahren zum Beschränken eines VIF auf die Verwendung einer bestimmten IP-Adresse ausgeführt haben, können Sie eine oder mehrere IP-Adressen hinzufügen, die das VIF verwenden kann.

Führen Sie den Befehl vif-param-add aus, um die IP-Adressen zur vorhandenen Liste hinzuzufügen. Führen Sie eine oder mehrere der folgenden Aktionen aus:

• Geben Sie die IPv4-IP-Adresse an. Beispiel:

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

• Geben Sie die IPv6-IP-Adresse an. Beispiel:

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

Wenn Sie ein VIF auf die Verwendung von zwei oder mehr IP-Adressen beschränken, können Sie eine dieser IP-Adressen aus der Liste löschen.

Führen Sie den Befehl vif-param-remove aus, um die IP-Adressen aus der vorhandenen Liste zu löschen. Führen Sie eine oder mehrere der folgenden Aktionen aus:

• Geben Sie die zu löschende IPv4-IP-Adresse an. Beispiel:

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

• Geben Sie die zu löschende IPv6-IP-Adresse an. Beispiel:

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

Verhindern, dass eine virtuelle Maschine Datenverkehr von einem bestimmten Netzwerk sendet oder empfängt

Das folgende Verfahren verhindert, dass eine virtuelle Maschine über eine bestimmte VIF kommuniziert. Wenn ein VIF eine Verbindung zu einem bestimmten Citrix Hypervisor Netzwerk herstellt, können Sie dieses Verfahren verwenden, um zu verhindern, dass eine virtuelle Maschine Datenverkehr von einem bestimmten Netzwerk sendet oder empfängt. Dies bietet eine detailliertere Steuerung als die Deaktivierung eines gesamten Netzwerks.

Wenn Sie den CLI-Befehl verwenden, müssen Sie das VIF nicht trennen, um den Sperrmodus des VIF einzustellen. Der Befehl ändert die Filterregeln, während das VIF ausgeführt wird. In diesem Fall scheint die Netzwerkverbindung immer noch vorhanden zu sein, jedoch verwirft das VIF alle Pakete, die die VM zu senden versucht.

Tipp:

Um die UUID einer VIF zu finden, führen Sie den xe-Befehl vif-list auf dem Host aus. Die Geräte-ID zeigt die Gerätenummer des VIF an.

Um zu verhindern, dass ein VIF Datenverkehr empfängt, deaktivieren Sie das mit dem Netzwerk verbundene VIF, von dem aus Sie verhindern möchten, dass die VM Datenverkehr empfängt:

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

Sie können die VIF auch in XenCenter deaktivieren, indem Sie auf der Registerkarte Netzwerk der VM die virtuelle Netzwerkschnittstelle auswählen und auf Deaktivieren klicken.

Aufhebung der Beschränkung eines VIF auf eine IP-Adresse

Gehen Sie wie folgt vor, um zum standardmäßigen (ursprünglichen) Sperrmoduszustand zurückzukehren. Wenn Sie ein VIF erstellen, konfiguriert Citrix Hypervisor es standardmäßig so, dass es nicht auf die Verwendung einer bestimmten IP-Adresse beschränkt ist.

Um eine VIF in einen entsperrten Zustand zurückzusetzen, ändern Sie den Standardsperrmodus der VIF in “Entsperrt”. Wenn dieser Modus nicht bereits verwendet wird, führen Sie den folgenden Befehl aus:

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

Vereinfachte Konfiguration des VIF-Sperrmodus in der Cloud

Anstatt die Befehle für den VIF-Sperrmodus für jedes VIF auszuführen, können Sie sicherstellen, dass alle VIFs standardmäßig deaktiviert sind. Um dies zu tun, müssen Sie die Paketfilterung auf Netzwerkebene ändern. Durch das Ändern der Paketfilterung bestimmt das Citrix Hypervisor-Netzwerk, wie Pakete gefiltert werden, wie im vorherigen Abschnitt Funktionsweise der Switch-Port-Sperrungbeschrieben.

Insbesondere bestimmt die Einstellung default-locking-mode eines Netzwerks, wie sich neue VIFs mit Standardeinstellungen verhalten. Wann immer locking-mode für VIF auf default eingestellt ist, bezieht sich das VIF auf den Netzwerksperrmodus (default-locking-mode), um zu bestimmen, ob und wie Pakete gefiltert werden, die durch das VIF übertragen werden:

• Freigeschaltet. Wenn der Netzwerkparameter default-locking-mode auf unlocked festgelegt ist, lässt Citrix Hypervisor die VM Datenverkehr an eine beliebige IP-Adresse im Netzwerk senden, mit dem die VIF eine Verbindung herstellt.

• Deaktiviert. Wenn der Parameter default-locking-mode auf disabled festgelegt ist, wendet Citrix Hypervisor eine Filterregel an, sodass die VIF den gesamten Datenverkehr löscht.

Standardmäßig ist default-locking-mode für alle Netzwerke, die in XenCenter erstellt wurden und die CLI verwenden, auf unlocked festgelegt.

Indem Sie den Sperrmodus des VIF auf den Standardwert (network_default) setzen, können Sie eine grundlegende Standardkonfiguration (auf Netzwerkebene) für alle neu erstellten VIFs erstellen, die eine Verbindung zu einem bestimmten Netzwerk herstellen.

Diese Abbildung zeigt, wie die VIF default-locking-mode für das Netzwerk verwendet, um sein Verhalten zu bestimmen, wenn locking-mode für die VIF auf die Standardeinstellung (network_default) eingestellt ist.

Beispielsweise werden VIFs standardmäßig mit der Einstellung locking-mode auf network_default erstellt. Wenn Sie das default-locking-mode= eines Netzwerks festlegendisabled, werden alle neuen VIFs, für die Sie den Sperrmodus nicht konfiguriert haben, deaktiviert. Die VIFs bleiben deaktiviert, bis Sie entweder (a) den Parameter locking-mode des einzelnen VIF ändern oder (b) die locking-mode der VIFs explizit auf “entsperrt” setzen. Dies ist hilfreich, wenn Sie einer bestimmten VM genug vertrauen, sodass Sie ihren Datenverkehr überhaupt nicht filtern möchten.

So ändern Sie die Standardeinstellung für den Sperrmodus eines Netzwerks:

Ändern Sie nach dem Erstellen des Netzwerks den Standardsperrmodus, indem Sie den folgenden Befehl ausführen:

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

Hinweis:

Um die UUID für ein Netzwerk abzurufen, führen Sie den xe-Befehl network-list aus. Dieser Befehl zeigt die UUIDs für alle Netzwerke auf dem Host an, auf dem Sie den Befehl ausgeführt haben.

So überprüfen Sie die Standardeinstellung für den Sperrmodus eines Netzwerks:

Führen Sie einen der folgenden Befehle aus:

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

ODER

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

Netzwerkeinstellungen für die Filterung des VIF-Datenverkehrs verwenden

Das folgende Verfahren weist eine VIF auf einer virtuellen Maschine an, die Citrix Hypervisor default-locking-mode-Netzwerkeinstellungen im Netzwerk selbst zu verwenden, um zu bestimmen, wie der Datenverkehr gefiltert werden soll.

1. Ändern Sie den VIF-Sperrstatus in network_default, falls dieser Modus nicht bereits verwendet wird, indem Sie den folgenden Befehl ausführen:

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

2. Ändern Sie den Standardsperrmodus in unlocked, falls dieser Modus nicht bereits verwendet wird, indem Sie den folgenden Befehl ausführen:

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