Verwalten des Netzwerks

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

Erstellen von Netzwerken auf einem eigenständigen Host

Da externe Netzwerke für jedes PIF während der Hostinstallation erstellt werden, ist das Erstellen zusätzlicher Netzwerke in der Regel nur für folgende Zwecke erforderlich:

• Verwenden eines privaten Netzwerks

• Unterstützung erweiterter 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 XenServer-Host-Textkonsole.

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 XenServer-Hosts in einem Ressourcenpool müssen über die gleiche Anzahl physischer Netzwerkkarten verfügen. Diese Anforderung wird nicht strikt durchgesetzt, wenn ein Host mit einem Pool verbunden ist. Eine der Netzwerkkarten wird immer als Verwaltungsschnittstelle, die für den XenServer-Verwaltungsdatenverkehr verwendet wird.

Da alle Hosts in einem Pool ein gemeinsames Netzwerk verwenden. Es ist wichtig, die gleiche physische Netzwerkkonfiguration für XenServer-Hosts in einem Pool zu haben. PIFs auf den einzelnen Hosts werden basierend auf dem Gerätenamen mit poolweiten Netzwerken verbunden. Beispielsweise haben alle XenServer-Hosts in einem Pool mit eth0-NIC ein entsprechendes PIF, das an das poolweite Netzwerk Netzwerk 0 angeschlossen ist. Dasselbe gilt für Hosts mit eth1-NICs und Netzwerk 1sowie andere NICs, die in mindestens einem XenServer-Host im Pool vorhanden sind.

Wenn ein XenServer-Host über eine andere Anzahl von Netzwerkkarten verfügt als andere Hosts im Pool, kann es zu Komplikationen kommen. Die Komplikationen können auftreten, da nicht alle Poolnetzwerke für alle Poolhosts gültig sind. Wenn beispielsweise Hosts Gastgeber1 und host2 sich im selben Pool befinden und Gastgeber1 verfügt über vier Netzwerkkarten und host2 hat nur zwei, nur die Netzwerke, die mit PIFs verbunden sind, die eth0 und eth1 entsprechen, sind gültig auf host2. VMs auf Gastgeber1 mit VIFs, die mit Netzwerken verbunden sind, die eth2 und eth3 entsprechen, können nicht auf den Host migriert werden host2.

Erstellen von VLANs

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

Öffnen Sie die XenServer-Hostkonsole.

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 des PIF zu finden, die 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 das gewünschte physische 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-->

Fügen Sie VM-VIFs an das neue Netzwerk an. Weitere Informationen finden Sie unter Erstellen von Netzwerken auf einem eigenständigen Host.

Erstellen von NIC-Bindungen auf einem eigenständigen Host

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

In diesem Abschnitt wird beschrieben, wie Sie die xe CLI verwenden, um NIC-Schnittstellen auf XenServer-Hosts zu binden, die sich nicht in einem Pool befinden. Informationen zur Verwendung der xe CLI zum Erstellen von NIC-Bindungen auf XenServer-Hosts, die einen Ressourcenpool umfassen, finden Sie unter Erstellen von NIC-Bindungen in Ressourcenpools.

Erstellen einer NIC-Bindung

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

1. Verwenden Sie den Befehl network-create , um ein Netzwerk zur Verwendung mit der verbundenen Netzwerkkarte 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 in der Bindung zu verwendenden PIFs zu bestimmen:

     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. Geben Sie unter Verwendung von Kommas zur Trennung der Parameter die neu erstellte Netzwerk-UUID und die UUIDs der zu bindenden 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 Netzwerkkarten verbinden, und vier UUIDs, wenn Sie vier Netzwerkkarten verbinden. Die UUID für die Bindung wird nach dem Ausführen des Befehls zurückgegeben.

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

        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 Anleihe

Wenn Sie die Verwaltungsschnittstelle binden, wird die PIF/Netzwerkkarte zusammengefasst, die als Verwaltungsschnittstelle verwendet wird. Wenn der Host DHCP verwendet, ist die MAC-Adresse der Bindung mit der verwendeten PIF/NIC identisch. 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. Wenn die Bindung jedoch aktiviert ist und sich die verwendete MAC/IP-Adresse ändert, werden vorhandene Netzwerksitzungen mit dem Host verworfen.

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

• Im Befehl bond-create kann ein optionaler mac -Parameter angegeben werden. Sie können diesen Parameter verwenden, um die MAC-Adresse der Bindung auf eine beliebige Adresse festzulegen.

• Wenn der Parameter mac nicht angegeben ist, verwendet XenServer die MAC-Adresse der Verwaltungsschnittstelle, wenn es sich um eine der Schnittstellen in der Bindung handelt. Wenn die Verwaltungsschnittstelle nicht Teil der Bindung ist, aber eine andere Verwaltungsschnittstelle, verwendet die Bindung die MAC-Adresse (und auch die IP-Adresse) dieser Verwaltungsschnittstelle. Wenn es sich bei keiner der Netzwerkkarten in der Bindung um eine Verwaltungsschnittstelle handelt, verwendet die Bindung die MAC der ersten benannten Netzwerkkarte.

NIC-Anleihen rückgängig machen

Beim Zurücksetzen des XenServer-Hosts 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 in die Verwaltungsschnittstelle verschoben. Wenn sich die Verwaltungsschnittstelle eines Hosts auf einer getaggten VLAN-gebundenen Schnittstelle befindet, wird beim Ausführen von Bond-Destroydas Verwaltungs-VLAN zur primären Netzwerkkarte verschoben.

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

1. Die Verwaltungsschnittstellen-NIC (wenn es sich bei der Verwaltungsschnittstelle um eine der gebundenen Netzwerkkarten handelt).

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 welche es sich handelt, indem Sie Folgendes ausführen:

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

Erstellen von NIC-Bindungen in Ressourcenpools

Erstellen Sie nach Möglichkeit NIC-Bindungen als Teil der anfänglichen Erstellung des Ressourcenpools, bevor Sie weitere Hosts mit dem Pool verknüpfen oder VMs erstellen. Auf diese Weise kann die Bindungskonfiguration automatisch auf Hosts repliziert werden, wenn diese mit dem Pool verbunden werden, und die Anzahl der erforderlichen Schritte wird reduziert.

Für das Hinzufügen einer NIC-Bindung zu einem vorhandenen Pool ist eine der folgenden Aufgaben erforderlich:

• Verwenden der CLI zum Konfigurieren der Bindungen für den Poolkoordinator und dann für jedes Mitglied des Pools.

• Verwenden der CLI zum Konfigurieren von Bindungen auf dem Poolkoordinator und anschließendes Neustarten jedes Poolmitglieds, sodass es seine Einstellungen vom Poolkoordinator erbt.

• Verwenden von XenCenter zum Konfigurieren der Bindungen auf dem Pool-Koordinator. XenCenter synchronisiert automatisch die Netzwerkeinstellungen auf den Mitgliedshosts mit dem Poolkoordinator, sodass Sie die Mitgliedshosts nicht neu starten müssen.

Der Einfachheit halber und um Fehlkonfigurationen zu vermeiden, empfehlen wir die Verwendung von XenCenter zum Erstellen von NIC-Bonds. Weitere Informationen finden Sie unter Konfigurieren von Netzwerkkarten.

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

Warnung:

Versuchen Sie nicht, Netzwerkbindungen zu erstellen, wenn die Hochverfügbarkeit aktiviert ist. Der Prozess der Bindungserstellung stört den laufenden Hochverfügbarkeits-Heartbeat und führt dazu, dass Hosts sich selbst eingrenzen. Der ordnungsgemäße Neustart der Hosts kann fehlschlagen und zur Wiederherstellung ist möglicherweise der Befehl host-emergency-ha-disable erforderlich.

Wählen Sie den Host aus, der als Poolkoordinator fungieren soll. Der Poolkoordinator 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-Bindung.

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

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

Die Netzwerk- und Bindungsinformationen werden automatisch auf den neuen Host repliziert. Die Verwaltungsschnittstelle wird automatisch von der Host-Netzwerkkarte, auf der sie ursprünglich konfiguriert wurde, in die gebundene PIF verschoben. Das heißt, die Verwaltungsschnittstelle wird nun in die Bindung integriert, so dass die gesamte Bindung 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, während die Hochverfügbarkeit aktiviert ist. Der Prozess der Bindungserstellung stört den laufenden Hochverfügbarkeits-Heartbeat und führt dazu, dass Hosts sich selbst eingrenzen. Der ordnungsgemäße Neustart der Hosts kann möglicherweise fehlschlagen und Sie müssen zur Wiederherstellung möglicherweise den Befehl host-emergency-ha-disable ausführen.

Konfigurieren einer dedizierten Speicher-NIC

Sie können XenCenter oder die xe CLI verwenden, um einer Netzwerkkarte eine IP-Adresse zuzuweisen und sie einer bestimmten Funktion zuzuweisen, z. B. Speicherdatenverkehr. Wenn Sie eine Netzwerkkarte mit einer IP-Adresse konfigurieren, erstellen Sie dazu eine sekundäre Schnittstelle. (Die IP-fähige Netzwerkkarte XenServer, die für die Verwaltung verwendet wird, wird als Verwaltungsschnittstelle bezeichnet.)

Wenn Sie eine sekundäre Schnittstelle für einen bestimmten Zweck zuweisen möchten, stellen Sie sicher, dass die entsprechende Netzwerkkonfiguration vorhanden ist. Dadurch soll sichergestellt werden, dass die Netzwerkkarte nur für den gewünschten Datenverkehr verwendet wird. Um eine Netzwerkkarte für den Speicherdatenverkehr zu reservieren, konfigurieren Sie die Netzwerkkarte, das Speicherziel, den Switch und das VLAN so, dass das Ziel nur über die zugewiesene Netzwerkkarte zugänglich ist. 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 Speicherdatenverkehr erstellen, müssen Sie ihr eine IP-Adresse zuweisen, die wie folgt lautet:

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

• Sie befinden sich 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 z. B. zwei weitere sekundäre Schnittstellen für den Speicher konfigurieren möchten, benötigen Sie IP-Adressen in drei verschiedenen Subnetzen – einem Subnetz für die Verwaltungsschnittstelle, einem Subnetz für die sekundäre Schnittstelle 1 und einem Subnetz für die sekundäre Schnittstelle 2.

Wenn Sie Bonding für die Resilienz Ihres Speicherdatenverkehrs verwenden, sollten Sie die Verwendung von LACP anstelle des Linux-Bridge-Bondings in Betracht ziehen. Um LACP-Bonding zu verwenden, müssen Sie den vSwitch als Netzwerk-Stack konfigurieren. Weitere Informationen finden Sie unter vSwitch-Netzwerke.

Hinweis:

Wenn Sie eine Netzwerkkarte auswählen, die als sekundäre Schnittstelle für die Verwendung mit iSCSI- oder NFS-SRs konfiguriert werden soll, stellen Sie sicher, dass die dedizierte Netzwerkkarte ein separates IP-Subnetz verwendet, das nicht über die Verwaltungsschnittstelle geroutet werden kann. Wenn dies nicht erzwungen wird, kann der Speicherdatenverkehr nach einem Neustart des Hosts aufgrund der Reihenfolge, in der Netzwerkschnittstellen initialisiert werden, über die Hauptverwaltungsschnittstelle geleitet werden.

Stellen Sie sicher, dass sich der PIF in einem separaten Subnetz befindet oder 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 Parameter mode hinzu. Wenn Sie eine statische IP-Adressierung verwenden, fügen Sie die Parameter IP, Netzmaske, Gateway und DNS hinzu:

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

Legen Sie den disallow-unplug-Parameter des PIF auf true fest:

  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 den Speicher verwenden möchten, die auch über die Verwaltungsschnittstelle weitergeleitet werden kann (wobei zu beachten ist, dass diese Konfiguration nicht die bewährte Methode 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 erneut zu initialisieren. Mit diesem Befehl wird die Speicherverbindung neu gestartet und über die richtige Schnittstelle weitergeleitet.

• Alternativ können Sie xe pif-forget verwenden, um die Schnittstelle aus der XenServer-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.

Verwenden von SR-IOV-fähigen Netzwerkkarten

Single Root I/O Virtualization (SR-IOV) ist eine Virtualisierungstechnologie, die es ermöglicht, dass ein einzelnes PCI-Gerät als mehrere PCI-Geräte auf dem physischen System angezeigt wird. Das eigentliche physische Gerät wird als Physical Function (PF) bezeichnet, während die anderen als Virtual Functions (VF) bezeichnet werden. Der Hypervisor kann einer Virtual Machine (VM) einen oder mehrere VFs zuweisen: Der Gast kann das Gerät dann so nutzen, als wäre es direkt zugewiesen.

Durch das Zuweisen eines oder mehrerer Netzwerkkarten-VFs zu einer VM kann der Netzwerkdatenverkehr den virtuellen Switch umgehen. Nach der Konfiguration verhält sich jede VM so, als würde sie die Netzwerkkarte 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 Datenverkehr von verschiedenen VMs über dieselbe Netzwerkkarte sicherstellen (unter Umgehung des XenServer-Netzwerkstapels).

Mit dieser Funktion können Sie:

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

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

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

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

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

• Führen Sie Tests durch, um zu bestätigen, ob SR-IOV als Teil des Automated Certification Kit unterstützt wird.

Systemkonfiguration

Konfigurieren Sie die Hardwareplattform korrekt, um SR-IOV zu unterstützen. Folgende Technologien werden benötigt:

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

• Alternative Routing-ID-Interpretation (ARI)

• Adressübersetzungsdienste (ATS)

• Zugriffskontrolldienste (ACS)

In der Dokumentation zu Ihrem System finden Sie Informationen darüber, wie Sie die Systemfirmware konfigurieren können, um die genannten Technologien zu aktivieren.

Aktivieren eines SR-IOV-Netzwerks auf einer Netzwerkkarte

Verwenden Sie in XenCenter die Neues Netzwerk Assistent im Feld Vernetzung , um ein SR-IOV-Netzwerk auf einer Netzwerkkarte zu erstellen und zu aktivieren.

Zuweisen eines SR-IOV-Netzwerks zur virtuellen Schnittstelle (VM-Ebene)

Verwenden Sie in XenCenter auf VM-Ebene die Virtuelle Schnittstelle hinzufügen Assistent im Feld Vernetzung , um ein SR-IOV-fähiges Netzwerk als virtuelle Schnittstelle für diese VM hinzuzufügen. Weitere Informationen finden Sie unter Hinzufügen eines neuen Netzwerks.

Unterstützte Netzwerkkarten und Gäste

Eine Liste der unterstützten Hardwareplattformen und Netzwerkkarten finden Sie unter Hardware-Kompatibilitätsliste. In der vom Anbieter für einen bestimmten Gast bereitgestellten Dokumentation finden Sie Informationen dazu, ob SR-IOV unterstützt wird.

Begrenzungen

• Bei bestimmten 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.

• Ein SR-IOV-Netzwerk auf Poolebene mit unterschiedlichen Arten von Netzwerkkarten wird nicht unterstützt.

• Ein SR-IOV-VF und ein normaler VIF von derselben Netzwerkkarte können aufgrund der Hardwareeinschränkungen der Netzwerkkarte möglicherweise nicht miteinander kommunizieren. Damit diese VMs kommunizieren können, stellen Sie sicher, dass für die Kommunikation das Muster VF zu VF oder VIF zu VIF und nicht VF zu VIF verwendet wird.

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

• Das Durchführen von Livemigration, Anhalten und Prüfpunkten wird auf VMs, die eine SR-IOV-VF verwenden, nicht unterstützt.

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

• SR-IOV-VFs unterstützen keinen Netzwerkstart.

• Bei einigen Netzwerkkarten mit älteren Netzwerkkartentreibern ist möglicherweise auch nach dem Neustart des Hosts ein Neustart erforderlich, was darauf hinweist, dass die Netzwerkkarte SR-IOV nicht aktivieren kann.

• 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 die physische SR-IOV-fähige Netzwerkkarte VF gebunden ist.

• SR-IOV kann in einer Umgebung verwendet werden, die Hochverfügbarkeit nutzt. SR-IOV wird in der Kapazitätsplanung jedoch nicht berücksichtigt. VMs, denen SR-IOV-VFs zugewiesen sind, werden nach bestem Wissen und Gewissen neu gestartet, wenn ein Host im Pool vorhanden ist, der über die entsprechenden Ressourcen verfügt. Zu diesen Ressourcen gehören SR-IOV, das im richtigen Netzwerk aktiviert ist, und ein kostenloses VF.

• SR-IOV VFs werden mit dem PVS-Accelerator nicht unterstützt.

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

In der Regel kann die maximale Anzahl von VFs, die eine Netzwerkkarte unterstützen kann, automatisch bestimmt werden. Für Netzwerkkarten, die Legacy-Treiber verwenden (z. B. Intel I350-Familie), wird der Grenzwert in der Konfigurationsdatei des Treibermoduls definiert. Das Limit muss möglicherweise manuell angepasst werden. Um es auf das Maximum einzustellen, öffnen Sie die Datei mit einem Editor und ändern Sie den Zeilenanfang:

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

Um beispielsweise die maximale Anzahl an VFs für den igb -Treiber auf 4 festzulegen, bearbeiten Sie /etc/modprobe.d/igb.conf wie folgt:

  ## 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 VFs-maxvfs-by-defaultsein.

• Ändern Sie keine andere Zeile in diesen Dateien.

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

CLI

Siehe SR-IOV-Befehle für CLI-Anweisungen zum Erstellen, Löschen, Anzeigen von SR-IOV-Netzwerken und Zuweisen eines SR-IOV VF zu einer VM.

Steuern der Rate ausgehender Daten (QoS)

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

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

Abhängig vom im Pool konfigurierten Netzwerkstapel können Sie den Quality of Service-Wert für virtuelle VM-Schnittstellen (VIFs) an einer von zwei Stellen festlegen. Sie können diesen Wert entweder über die xe CLI oder in XenCenter festlegen.

• XenCenter (Englisch) Sie können den Grenzwert für die Quality of Service-Übertragungsrate im Eigenschaftendialogfeld für die virtuelle Schnittstelle festlegen.
• XE-Befehle Sie können die Quality of Service-Übertragungsrate mithilfe der CLI mit den Befehlen im folgenden Abschnitt festlegen.

Beispiel für einen CLI-Befehl für QoS

Um eine VIF mithilfe der CLI auf eine maximale Übertragungsrate von 100 Kilobyte pro Sekunde zu begrenzen, 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 bezeichnet Kilobyte pro Sekunde (kBps), nicht Kilobit pro Sekunde (kbps).

Ändern der Netzwerkkonfigurationsoptionen

In diesem Abschnitt wird erläutert, wie Sie die Netzwerkkonfiguration Ihres XenServer-Hosts ändern. Es beinhaltet:

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

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

• Ändern von IP-Adressen

• Ändern, welche Netzwerkkarte als Verwaltungsschnittstelle verwendet wird

• Hinzufügen einer neuen physischen Netzwerkkarte zum Server

• Hinzufügen eines Zwecks zu einem Netzwerk

• Aktivieren der ARP-Filterung (Switch-Port-Sperre)

Hostname

Der System-Hostname, auch als Domänen- oder DNS-Name bezeichnet, wird in der poolweiten Datenbank definiert und mit dem CLI-Befehl xe host-set-hostname-live wie folgt geändert:

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

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

DNS-Server

Um DNS-Server in der IP-Adresskonfiguration des XenServer-Hosts hinzuzufügen oder zu löschen, verwenden Sie den Befehl pif-reconfigure-ip . Beispiel: Für ein PIF mit einer statischen IP-Adresse:

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

XenServer-Hosts 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 zum Ändern der IP-Adresse der Verwaltungsschnittstelle eines Hosts erforderlich sind, unterscheiden sich für den Pool-Koordinator und andere Hosts.

Hinweis:

Sie müssen vorsichtig sein, wenn Sie die IP-Adresse eines Hosts und andere Netzwerkparameter ändern. Abhängig von der Netzwerktopologie und der vorgenommenen Änderung können Verbindungen zum Netzwerkspeicher verloren gehen. In diesem Fall muss der Speicher mit der Funktion Repair Storage in XenCenter oder mit dem CLI-Befehl pbd-plug erneut angeschlossen werden. Aus diesem Grund wird empfohlen, VMs vom Host weg zu migrieren, bevor Sie die IP-Konfiguration ändern.

Verwenden Sie den CLI-Befehl pif-reconfigure-ip , um die IP-Adresse wie gewünscht einzustellen. 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 die Verbindung zum Poolkoordinator wiederhergestellt hat, indem Sie überprüfen, ob alle anderen XenServer-Hosts im Pool sichtbar sind:

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

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

Verwenden Sie nach Möglichkeit eine dedizierte IP-Adresse, die sich während der Lebensdauer des Pools für Poolkoordinatoren wahrscheinlich nicht ändert.

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

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

Wenn sich die IP-Adresse des Pool-Koordinators ändert, wechseln alle Mitglieds-Hosts in den Notfallmodus, wenn sie den Pool-Koordinator nicht kontaktieren können.

Verwenden Sie auf dem Pool-Koordinator den Befehl pool-recover-slaves , um den Pool-Koordinator zu zwingen, jedes Pool-Mitglied zu kontaktieren und ihnen die neue IP-Adresse des Pool-Koordinators mitzuteilen:

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

Verwaltungsschnittstelle

Wenn Sie XenServer auf einem Host installieren, wird eine seiner Netzwerkkarten als Verwaltungsschnittstelle: Die Netzwerkkarte, die für den XenServer-Verwaltungsdatenverkehr verwendet wird. Die Verwaltungsschnittstelle wird für XenCenter-Verbindungen mit dem Host (z. B. Citrix Virtual Apps and Desktops) und für die Host-to-Host-Kommunikation verwendet.

Verwenden Sie den Befehl pif-list , um zu bestimmen, welches 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-Adresskonfiguration für das für die Verwaltungsschnittstelle verwendete PIF zu überprüfen. Verwenden Sie bei Bedarf den Befehl pif-reconfigure-ip , um die IP-Adressierung für das zu verwendende PIF zu konfigurieren.

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

Verwenden Sie den CLI-Befehl host-management-reconfigure , um das für die Verwaltungsschnittstelle verwendete PIF zu ändern. Wenn dieser Host Teil eines Ressourcenpools ist, Dieser Befehl muss in der Hostkonsole des Mitglieds ausgegeben werden:

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

Verwenden Sie den Befehl network-list , um zu bestimmen, welcher PIF der NIC 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-Adresskonfiguration für das PIF für die Verwaltungsschnittstelle zu überprüfen. Verwenden Sie bei Bedarf den Befehl pif-reconfigure-ip , um die IP-Adressierung für das zu verwendende PIF zu konfigurieren.

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

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

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

Einschränken der Verwendung von Port 80

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

Informationen zum Schließen von Port 80 finden Sie im XenCenter-Dokumentationshandbuch unter dem Xe-CLI-Befehl https-only oder Pooleigenschaften ändern .

Deaktivieren des Verwaltungszugriffs

Um den Remote-Zugriff auf die Verwaltungskonsole vollständig zu deaktivieren, verwenden Sie den CLI-Befehl host-management-disable .

Warnung:

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

Hinzufügen einer neuen physischen Netzwerkkarte

1. Installieren Sie eine neue physische Netzwerkkarte auf Ihrem XenServer-Host wie gewohnt.
2. Starten Sie Ihren XenServer-Host neu.

3. Listen Sie alle physischen Netzwerkkarten für diesen XenServer-Host mit dem folgenden Befehl auf:

     xe pif-list host-uuid=<host_uuid>
   

4. Wenn die zusätzliche Netzwerkkarte nicht angezeigt wird, 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 Netzwerkkarte erstellt.

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

     xe pif-list host-uuid=<host_uuid>
   

6. Die neue PIF wird zunächst als getrennt aufgeführt (aktuell verbunden ( RO): false). Um es aufzurufen, verwenden Sie den folgenden Befehl:

     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 Konfigurieren von Netzwerkkarten in der XenCenter-Dokumentation.

Entfernen einer physischen Netzwerkkarte

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

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.

Um einen Netzwerkzweck hinzuzufügen, verwenden Sie den Befehlxe network-param-add :

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

Um einen Netzwerkzweck zu löschen, verwenden Sie den Befehlxe network-param-remove :

  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 in der Leitfaden zur Verfolgung geänderter XenServer-Blöcke.

Verwenden der Switch-Port-Sperre

Mit der XenServer-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 den gesamten Datenverkehr in einem Netzwerk standardmäßig zu blockieren oder bestimmte IP-Adressen zu definieren, von denen eine einzelne VM Datenverkehr senden darf.

Durch die Verwendung von Switch-Port-Sperren können Sie Ihre Netzwerkkonfiguration vereinfachen, indem Sie allen Ihren Mandanten oder Gästen die Verwendung desselben Layer-2-Netzwerks ermöglichen.

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

• Beanspruchen einer anderen IP- oder MAC-Adresse als denen, die der XenServer-Administrator angegeben hat, die er verwenden kann

• Abfangen, Spoofing oder Unterbrechen des Datenverkehrs anderer VMs

Anforderungen

• Die XenServer-Switch-Port-Sperrfunktion wird auf der Linux-Bridge und den vSwitch-Netzwerkstacks unterstützt.

• Wenn Sie die rollenbasierte Zugriffssteuerung (Role Based Access Control, RBAC) in Ihrer Umgebung aktivieren, muss der Benutzer, der die Switch-Port-Sperre konfiguriert, mit einem Konto angemeldet sein, das mindestens über die Rolle “Pool-Operator” oder “Pool-Administrator” verfügt. Wenn RBAC in Ihrer Umgebung nicht aktiviert ist, muss der Benutzer mit dem Stammkonto für den Poolkoordinator angemeldet sein.

• Wenn Sie die Befehle zum Sperren von switch-ports ausführen, können Netzwerke online oder offline sein.

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

Hinweise

Ohne Switch-Port-Sperrkonfigurationen werden VIFs auf “network_default” und Netzwerke auf “entsperrt” gesetzt.

Das Konfigurieren von Switch-Port-Sperren wird nicht unterstützt, wenn Controller von Drittanbietern in der Umgebung verwendet werden.

Die Switch-Port-Sperre hindert Cloud-Mandanten nicht daran, Folgendes zu tun:

• Ausführen eines Angriffs auf IP-Ebene auf einen anderen Mandanten/Benutzer. Die Switch-Port-Sperre verhindert jedoch, dass sie den Angriff auf IP-Ebene durchführen, wenn sie versuchen, dies mit den folgenden Mitteln zu tun, und die Switch-Port-Sperre konfiguriert ist: a) sich als ein anderer Mandant oder Benutzer ausgeben oder b) ein Abfangen des Datenverkehrs initiieren, der für einen anderen Benutzer bestimmt ist.

• Erschöpfung der Netzwerkressourcen.

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

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

Hinweise zur Implementierung

Sie können die Switch-Port-Sperrfunktion entweder über die Befehlszeile oder die XenServer-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 die Switch-Port-Sperre bestimmte Arten von Angriffen verhindern kann. In diesen Beispielen handelt es sich bei VM-c um einen virtuellen Computer, den ein feindlicher Mandant (Mandant C) mietet und für Angriffe verwendet. VM-a und VM-b sind virtuelle Maschinen, die von nicht angreifenden Mandanten geleast werden.

Beispiel 1: Wie die Switch-Port-Sperre die Verhinderung von ARP-Spoofing verhindern kann:

ARP-Spoofing wird verwendet, um die Versuche eines Angreifers anzuzeigen, 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:

Virtueller Computer A (VM-a) möchte IP-Datenverkehr von VM-a an Virtual Machine B (VM-b) senden, indem er an die IP-Adresse von VM-b adressiert wird. 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 Strom 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 verknüpft ist, b_IP

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

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 verknüpft ist, b_IP.

   Ergebnis: VM-a erhält die ARP-Antwort von VM-b.

Beispiel 2: Verhinderung von IP-Spoofing:

IP-Adressen-Spoofing ist ein Prozess, bei dem die Identität von Paketen verschleiert wird, indem IP-Pakete (Internet Protocol) mit einer gefälschten Quell-IP-Adresse erstellt werden.

Szenario:

Mandant C versucht, einen Denial-of-Service-Angriff mit seinem Host Host-C auf einem Remotesystem durchzuführen, um seine Identität zu verschleiern.

Versuch 1:

Mandant C legt die IP-Adresse und MAC-Adresse von Host-C auf die IP- und MAC-Adressen von VM-a (a_IP und a_MAC) fest. Mandant C weist Host-C an, IP-Datenverkehr an ein Remotesystem zu senden.

Ergebnis: Die Host-C-Pakete werden verworfen. Dies liegt daran, dass der Administrator die Switch-Port-Sperre aktiviert hat. Die Host-C-Pakete werden verworfen, da durch das Aktivieren der Switch-Port-Sperre ein Identitätswechsel verhindert wird.

Versuch 2:

Mandant C legt die IP-Adresse von Host-C auf die IP-Adresse (a_IP) von VM-a fest und behält die ursprüngliche c_MAC bei.

Mandant C weist Host-C an, IP-Datenverkehr an ein Remotesystem zu senden.

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

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 eindeutige IP-Adresse, die auf derselben virtuellen Netzwerkschnittstelle (Virtual Network Interface, VIF) gehostet wird.

Alice konfiguriert die VIF von Host-B so, dass sie an eine einzige MAC-Adresse, aber viele IP-Adressen gebunden ist.

Funktionsweise der Switch-Port-Sperre

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

• VIF-Stufe. Die Einstellungen, die Sie in der VIF konfigurieren, bestimmen, wie Pakete gefiltert werden. Sie können die VIF so festlegen, dass die VM keinen Datenverkehr sendet, die VIF so einschränken, dass sie nur Datenverkehr mit der zugewiesenen IP-Adresse senden kann, oder der VM erlauben, Datenverkehr an eine beliebige IP-Adresse im Netzwerk zu senden, das mit der VIF verbunden ist.

• Netzwerk-Ebene. Das XenServer-Netzwerk bestimmt, wie Pakete gefiltert werden. Wenn der Sperrmodus eines VIF auf network_defaulteingestellt ist, bezieht er sich auf die Sperreinstellung auf Netzwerkebene, um zu bestimmen, welcher Datenverkehr zugelassen wird.

Unabhängig davon, welchen Netzwerk-Stack Sie verwenden, funktioniert die Funktion auf die gleiche Weise. Wie jedoch in den folgenden Abschnitten ausführlicher beschrieben, unterstützt die Linux-Bridge die Switch-Port-Sperre in IPv6 nicht vollständig.

Zustände im VIF-Sperrmodus

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

• Network_default. Wenn der Status des VIF auf network_defaulteingestellt ist, verwendet XenServer den Parameter default-locking-mode des Netzwerks, um zu bestimmen, ob und wie Pakete gefiltert werden, die durch das VIF laufen. Das Verhalten hängt davon ab, ob für das zugeordnete Netzwerk der Parameter für den Standardsperrmodus des Netzwerks auf deaktiviert oder entsperrt festgelegt ist:

  -Standard-Sperrmodus=deaktiviert, XenServer wendet eine Filterregel an, sodass das VIF den gesamten Datenverkehr löscht.

  -Standard-Sperrmodus= entsperrt, XenServer entfernt alle mit dem VIF verbundenen Filterregeln. Standardmäßig ist der Parameter für den Standardsperrmodus auf entsperrteingestellt.

  Informationen zum Parameter Standard-Sperrmodus finden Sie unter Netzwerkbefehle.

  Der Standardsperrmodus des Netzwerks hat keine Auswirkungen auf angeschlossene VIFs, deren Sperrstatus etwas anderes als network_defaultist.

  Hinweis:

  Sie können den Standard-Sperrmodus eines Netzwerks, an das aktive VIFs angeschlossen sind, nicht ändern.

• Verschlossen. XenServer 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 das VIF Datenverkehr akzeptiert, verwenden Sie die IPv4- oder IPv6-IP-Adressen mit den Parametern ipv4_allowed oder ipv6_allowed . Wenn Sie jedoch die Linux-Bridge konfiguriert haben, geben Sie keine IPv6-Adressen ein.

  Mit XenServer können Sie IPv6-Adressen eingeben, wenn die Linux-Bridge aktiv ist. XenServer kann jedoch nicht basierend auf den eingegebenen IPv6-Adressen filtern. Der Grund dafür ist, dass die Linux-Bridge nicht über Module zum Filtern von NDP-Paketen (Neighbor Discovery Protocol) verfügt. Daher kann kein vollständiger Schutz implementiert werden, und Gäste könnten sich durch Fälschen von NDP-Paketen als ein anderer Gast ausgeben. Wenn Sie also auch nur eine IPv6-Adresse angeben, lässt XenServer den gesamten IPv6-Datenverkehr durch das VIF leiten. Wenn Sie keine IPv6-Adressen angeben, lässt XenServer keinen IPv6-Datenverkehr an die VIF weiter.

• Unverschlossen. Der gesamte Netzwerkverkehr kann über das VIF geleitet werden. Das heißt, es werden keine Filter auf den Datenverkehr angewendet, der zum oder vom VIF geht.

• Arbeitsunfähig. Es darf kein Verkehr durch das VIF geleitet werden. (Das heißt, XenServer wendet eine Filterregel an, sodass die VIF den gesamten Datenverkehr verwirft.)

Konfigurieren der Switch-Port-Sperre

In diesem Abschnitt werden drei verschiedene Verfahren beschrieben:

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

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

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

Wenn der Sperrmodus eines VIF auf gesperrteingestellt ist, kann es nur die in den Parametern ipv4-zulässig oder ipv6-zulässig angegebenen Adressen verwenden.

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 vor oder nach dem Einstecken der VIF (oder dem Starten des virtuellen Computers) ausführen.

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

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

Die vif-uuid stellt die UUID des VIF dar, dem Sie das Senden von Datenverkehr erlauben möchten. Um die UUID zu erhalten, führen Sie den Befehl xe vif-list auf dem Host aus. vm-uuid Gibt die virtuelle Maschine an, für die die Informationen angezeigt werden. Die Geräte-ID gibt 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 einen oder mehrere der folgenden Schritte aus:

• Geben Sie ein oder mehrere IPv4-IP-Adressziele 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-Adressziele 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 Einschränken einer VIF auf die Verwendung einer bestimmten IP-Adresse ausgeführt haben, können Sie eine oder mehrere IP-Adressen hinzufügen, die von der VIF verwendet werden können.

Führen Sie den Befehl vif-param-add aus, um die IP-Adressen zur vorhandenen Liste hinzuzufügen. Führen Sie einen oder mehrere der folgenden Schritte 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 eine 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 einen oder mehrere der folgenden Schritte 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 ein virtueller Computer Datenverkehr aus einem bestimmten Netzwerk sendet oder empfängt

Das folgende Verfahren verhindert, dass eine virtuelle Maschine über ein bestimmtes VIF kommuniziert. Wenn eine VIF eine Verbindung zu einem bestimmten XenServer-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 ein detaillierteres Maß an Kontrolle als das Deaktivieren eines gesamten Netzwerks.

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

Tipp:

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

Um zu verhindern, dass eine VIF Datenverkehr empfängt, deaktivieren Sie die VIF, die mit dem Netzwerk verbunden ist, 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 die virtuelle Netzwerkschnittstelle auf der Registerkarte Netzwerk der VM auswählen und auf Deaktivieren klicken.

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

Gehen Sie folgendermaßen vor, um den standardmäßigen (ursprünglichen) Zustand des Sperrmodus wiederherzustellen. Wenn Sie ein VIF erstellen, konfiguriert XenServer es standardmäßig so, dass es nicht auf die Verwendung einer bestimmten IP-Adresse beschränkt ist.

Um eine VIF wieder in den gesperrten Zustand zu versetzen, ändern Sie den VIF-Standardsperrmodus in entsperrt. Wenn dieser Modus noch nicht verwendet wird, führen Sie den folgenden Befehl aus:

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

Vereinfachen Sie die 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. Dazu müssen Sie die Paketfilterung auf Netzwerkebene ändern. Wenn Sie die Paketfilterung ändern, bestimmt das XenServer-Netzwerk, wie Pakete gefiltert werden, wie im vorherigen Abschnitt beschrieben Funktionsweise der Switch-Port-Sperre.

Insbesondere bestimmt die Einstellung default-locking-mode eines Netzwerks, wie sich neue VIFs mit Standardeinstellungen verhalten. Wenn der Sperrmodus `` eines VIF auf Standardgesetzt ist, bezieht sich das VIF auf den Netzwerksperrmodus (Standardsperrmodus), um zu bestimmen, ob und wie Pakete gefiltert werden, die durch das VIF laufen:

• Unverschlossen. Wenn der Netzwerkparameter Standardsperrmodus auf entsperrtgesetzt ist, ermöglicht XenServer der VM, Datenverkehr an jede IP-Adresse im Netzwerk zu senden, mit dem das VIF verbunden ist.

• Arbeitsunfähig. Wenn der Parameter default-locking-mode auf disabledgesetzt ist, wendet XenServer eine Filterregel an, sodass das VIF den gesamten Datenverkehr löscht.

Standardmäßig ist der Standardsperrmodus für alle in XenCenter erstellten und die CLI verwendenden Netzwerke auf entsperrteingestellt.

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 ein VIF, wenn sein Sperrmodus auf seine Standardeinstellung (Netzwerkstandard) eingestellt ist, das Netzwerk Standard-Sperrmodus verwendet, um sein Verhalten zu bestimmen.

Beispielsweise werden VIFs standardmäßig mit ihrem Sperrmodus erstellt, der auf Netzwerkstandardeingestellt ist. Wenn Sie den Standard-Sperrmodus eines Netzwerks =`deaktiviert`festlegen, werden alle neuen VIFs deaktiviert, für die Sie den Sperrmodus nicht konfiguriert haben. Die VIFs bleiben deaktiviert, bis Sie entweder (a) den Sperrmodus-Parameter des einzelnen VIFs ändern oder (b) den Sperrmodus `` des VIFs explizit auf „entsperrt“ setzen. Dies ist hilfreich, wenn Sie einer bestimmten VM ausreichend vertrauen und den 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 zu erhalten, führen Sie den Befehl xe network-list aus. Mit diesem Befehl werden die UUIDs für alle Netzwerke auf dem Host angezeigt, 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-->

Verwenden der Netzwerkeinstellungen für die Filterung des VIF-Datenverkehrs

Das folgende Verfahren weist ein VIF auf einer virtuellen Maschine an, die XenServer-Netzwerkeinstellungen default-locking-mode im Netzwerk selbst zu verwenden, um zu bestimmen, wie der Datenverkehr gefiltert wird.

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 entsperrt, sofern 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-->