Netzwerke verwalten

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

Netzwerke auf einem eigenständigen Host erstellen

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

• Ein privates Netzwerk verwenden

• Erweiterte Operationen wie VLANs oder NIC-Bonding unterstützen

Informationen zum Hinzufügen oder Löschen von Netzwerken mit XenCenter finden Sie unter Ein neues Netzwerk hinzufügen in der XenCenter-Dokumentation.

Öffnen Sie die Textkonsole des XenServer®-Hosts.

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 einer PIF verbunden und daher intern.

Netzwerke in Ressourcenpools erstellen

Alle XenServer-Hosts in einem Ressourcenpool müssen die gleiche Anzahl physischer NICs haben. Diese Anforderung wird nicht streng durchgesetzt, wenn ein Host einem Pool hinzugefügt wird. Eine der NICs wird immer als Verwaltungsschnittstelle bezeichnet, die für den XenServer-Verwaltungsdatenverkehr verwendet wird.

Da alle Hosts in einem Pool einen gemeinsamen Satz von Netzwerken teilen, ist es wichtig, dass die XenServer-Hosts in einem Pool die gleiche physische Netzwerkkonfiguration aufweisen. PIFs auf den einzelnen Hosts sind basierend auf dem Gerätenamen mit poolweiten Netzwerken verbunden. Zum Beispiel haben alle XenServer-Hosts in einem Pool mit einer eth0-NIC eine entsprechende PIF, die an das poolweite Network 0 Netzwerk angeschlossen ist. Dasselbe gilt für Hosts mit eth1-NICs und Network 1 sowie für andere NICs, die in mindestens einem XenServer-Host im Pool vorhanden sind.

Wenn ein XenServer-Host eine andere Anzahl von NICs als andere Hosts im Pool hat, können Komplikationen auftreten. Die Komplikationen können entstehen, weil nicht alle Pool-Netzwerke für alle Pool-Hosts gültig sind. Wenn beispielsweise die Hosts host1 und host2 im selben Pool sind und host1 vier NICs und host2 nur zwei hat, sind nur die Netzwerke, die mit PIFs verbunden sind, die eth0 und eth1 entsprechen, auf host2 gültig. VMs auf host1 mit VIFs, die mit Netzwerken verbunden sind, die eth2 und eth3 entsprechen, können nicht auf Host host2 migriert werden.

VLANs erstellen

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

Öffnen Sie die XenServer-Hostkonsole.

Erstellen Sie ein Netzwerk zur 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, das der physischen NIC 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 neues PIF wird erstellt und mit dem angegebenen Netzwerk verbunden. Die UUID des neuen PIF-Objekts wird zurückgegeben.

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

Verbinden Sie VM-VIFs mit dem neuen Netzwerk. Weitere Informationen finden Sie unter Erstellen von Netzwerken auf einem eigenständigen Host.

NIC-Bonds auf einem eigenständigen Host erstellen

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

Dieser Abschnitt beschreibt, wie Sie die xe-CLI verwenden, um NIC-Schnittstellen auf XenServer-Hosts zu bündeln, die sich nicht in einem Pool befinden. Informationen zur Verwendung der xe-CLI zum Erstellen von NIC-Bonds auf XenServer-Hosts, die einen Ressourcenpool bilden, finden Sie unter Erstellen von NIC-Bonds in Ressourcenpools.

Einen NIC-Bond erstellen

Wenn Sie eine NIC bündeln, übernimmt der Bond das als Verwaltungsschnittstelle verwendete PIF/NIC. Die Verwaltungsschnittstelle wird automatisch auf das Bond-PIF verschoben.

1. Verwenden Sie den Befehl network-create, um ein Netzwerk zur Verwendung mit der gebündelten 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 im Bond zu verwendenden PIFs zu ermitteln:

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

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

   • Um den Bond im Aktiv-Aktiv-Modus (Standard) zu konfigurieren, verwenden Sie den Befehl bond-create, um den Bond zu erstellen. Trennen Sie die Parameter durch Kommas und geben Sie die neu erstellte Netzwerk-UUID und die UUIDs der zu bündelnden 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 bündeln, und vier UUIDs, wenn Sie vier NICs bündeln. Die UUID für die Bond wird nach Ausführung des Befehls zurückgegeben.

   • Um die Bond im Aktiv-Passiv- oder LACP-Bond-Modus zu konfigurieren, verwenden Sie dieselbe Syntax, fügen Sie den optionalen mode-Parameter 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-->
     

Die MAC-Adresse der Bond steuern

Wenn Sie die Verwaltungsschnittstelle bündeln, übernimmt sie die als Verwaltungsschnittstelle verwendete PIF/NIC. Wenn der Host DHCP verwendet, ist die MAC-Adresse der Bond dieselbe wie die der verwendeten PIF/NIC. Die IP-Adresse der Verwaltungsschnittstelle kann unverändert bleiben.

Sie können die MAC-Adresse der Bond so ändern, dass sie sich von der MAC-Adresse der (aktuellen) Verwaltungsschnittstellen-NIC unterscheidet. Wenn die Bond jedoch aktiviert wird und sich die verwendete MAC-/IP-Adresse ändert, werden bestehende Netzwerksitzungen zum Host getrennt.

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

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

• Wenn der mac-Parameter nicht angegeben ist, verwendet XenServer die MAC-Adresse der Verwaltungsschnittstelle, wenn diese eine der Schnittstellen in der Bond ist. Wenn die Verwaltungsschnittstelle nicht Teil der Bond ist, aber eine andere Verwaltungsschnittstelle vorhanden ist, verwendet die Bond die MAC-Adresse (und auch die IP-Adresse) dieser Verwaltungsschnittstelle. Wenn keine der NICs in der Bond eine Verwaltungsschnittstelle ist, verwendet die Bond die MAC der zuerst genannten NIC.

NIC-Bonds zurücksetzen

Beim Zurücksetzen des XenServer-Hosts auf eine nicht gebündelte Konfiguration konfiguriert der bond-destroy-Befehl die primäre NIC automatisch als Schnittstelle für die Verwaltungsschnittstelle. Daher werden alle VIFs auf die Verwaltungsschnittstelle verschoben. Wenn die Verwaltungsschnittstelle eines Hosts auf einer getaggten VLAN-Bond-Schnittstelle liegt, wird bei Ausführung von bond-destroy das Management-VLAN auf die primäre NIC verschoben.

Der Begriff primäre NIC bezieht sich auf die PIF, von der die MAC- und IP-Konfiguration beim Erstellen der Bond kopiert wurde. Beim Bündeln von zwei NICs ist die primäre NIC:

1. Die Verwaltungsschnittstellen-NIC (wenn die Verwaltungsschnittstelle eine der gebündelten NICs ist).

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

3. Die zuerst genannte NIC. Sie können herausfinden, welche es ist, indem Sie Folgendes ausführen:

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

NIC-Bonds in Ressourcenpools erstellen

Erstellen Sie NIC-Bonds wann immer möglich als Teil der anfänglichen Ressourcengruppenerstellung, bevor Sie weitere Hosts zur Gruppe hinzufügen oder VMs erstellen. Dadurch kann die Bond-Konfiguration automatisch auf Hosts repliziert werden, sobald diese der Gruppe beitreten, und die Anzahl der erforderlichen Schritte wird reduziert.

Das Hinzufügen eines NIC-Bonds zu einer bestehenden Gruppe erfordert eines der folgenden Verfahren:

• Verwenden der CLI, um die Bonds auf dem Pool-Koordinator und dann auf jedem Mitglied des Pools zu konfigurieren.

• Verwenden der CLI, um Bonds auf dem Pool-Koordinator zu konfigurieren und dann jedes Pool-Mitglied neu zu starten, damit es seine Einstellungen vom Pool-Koordinator übernimmt.

• Verwenden von XenCenter®, um die Bonds auf dem Pool-Koordinator zu konfigurieren. XenCenter synchronisiert die Netzwerkeinstellungen auf den Mitglieds-Hosts automatisch mit dem Pool-Koordinator, sodass Sie die Mitglieds-Hosts nicht neu starten müssen.

Aus Gründen der Einfachheit und zur Vermeidung von Fehlkonfigurationen empfehlen wir die Verwendung von XenCenter zum Erstellen von NIC-Bonds. Weitere Informationen finden Sie unter Konfigurieren von NICs.

Dieser Abschnitt beschreibt die Verwendung der xe CLI zum Erstellen von gebündelten NIC-Schnittstellen auf XenServer-Hosts, die eine Ressourcengruppe bilden. Informationen zur Verwendung der xe CLI zum Erstellen von NIC-Bonds auf einem eigenständigen Host finden Sie unter Erstellen von NIC-Bonds auf einem eigenständigen Host.

Warnung:

Versuchen Sie nicht, Netzwerk-Bonds zu erstellen, wenn Hochverfügbarkeit aktiviert ist. Der Prozess der Bond-Erstellung stört den laufenden Hochverfügbarkeits-Heartbeat und führt dazu, dass sich Hosts selbst abschirmen (herunterfahren). Die Hosts können möglicherweise nicht ordnungsgemäß neu starten und benötigen möglicherweise den Befehl host-emergency-ha-disable, um sich zu erholen.

Wählen Sie den Host aus, der der Pool-Koordinator sein soll. Der Pool-Koordinator gehört standardmäßig zu einem unbenannten Pool. Um eine Ressourcengruppe 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 den NIC-Bond wie unter Einen NIC-Bond erstellen beschrieben.

Öffnen Sie eine Konsole auf einem Host, den Sie der Gruppe hinzufügen 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 Bond-Informationen werden automatisch auf den neuen Host repliziert. Die Verwaltungsschnittstelle wird automatisch von der Host-NIC, auf der sie ursprünglich konfiguriert war, auf die gebündelte PIF verschoben. Das heißt, die Verwaltungsschnittstelle ist nun in den Bond integriert, 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, Netzwerk-Bonds zu erstellen, während Hochverfügbarkeit aktiviert ist. Der Prozess der Bond-Erstellung stört den laufenden Hochverfügbarkeits-Heartbeat und führt dazu, dass Hosts sich selbst abschirmen (herunterfahren). Die Hosts können möglicherweise nicht ordnungsgemäß neu starten, und Sie müssen möglicherweise den Befehl host-emergency-ha-disable ausführen, um sie wiederherzustellen.

Dedizierte Speicher-NIC konfigurieren

Sie können XenCenter oder die xe-CLI verwenden, um einer NIC eine IP-Adresse zuzuweisen und sie für eine bestimmte Funktion, wie z. B. Speicherverkehr, zu dedizieren. Wenn Sie eine NIC mit einer IP-Adresse konfigurieren, tun Sie dies, indem Sie eine sekundäre Schnittstelle erstellen. (Die IP-fähige NIC, die XenServer für die Verwaltung verwendet, wird als Verwaltungsschnittstelle bezeichnet.)

Wenn Sie eine sekundäre Schnittstelle für einen bestimmten Zweck dedizieren möchten, stellen Sie sicher, dass die entsprechende Netzwerkkonfiguration vorhanden ist. Dies soll gewährleisten, dass die NIC nur für den gewünschten Datenverkehr verwendet wird. Um eine NIC für den Speicherverkehr zu dedizieren, konfigurieren Sie die NIC, das Speicherziel, den Switch und das VLAN so, dass das Ziel nur über die zugewiesene NIC zugänglich ist. Wenn Ihre physische und IP-Konfiguration den über die Speicher-NIC gesendeten Datenverkehr nicht einschränkt, können Sie Datenverkehr, wie 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:

• Im selben Subnetz wie der Speicher-Controller liegt, falls zutreffend, und

• Nicht im selben Subnetz wie andere sekundäre Schnittstellen oder die Verwaltungsschnittstelle liegt.

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 die sekundäre Schnittstelle 1 und ein Subnetz für die sekundäre Schnittstelle 2.

Wenn Sie Bonding zur Ausfallsicherheit für Ihren Speicherverkehr verwenden, sollten Sie LACP anstelle des Linux-Bridge-Bondings (veraltet) in Betracht ziehen. Um LACP-Bonding zu verwenden, müssen Sie den vSwitch als Ihren Netzwerk-Stack konfigurieren. Weitere Informationen finden Sie unter Netzwerk-Stack-Auswahl.

Hinweis:

Stellen Sie bei der Auswahl einer NIC, die als sekundäre Schnittstelle für die Verwendung mit iSCSI- oder NFS-SRs konfiguriert werden soll, sicher, dass die dedizierte NIC ein separates IP-Subnetz verwendet, das von der Verwaltungsschnittstelle aus nicht routbar ist. Wenn dies nicht erzwungen wird, kann der Speicherverkehr nach einem Host-Neustart über die Hauptverwaltungsschnittstelle geleitet werden, da die Netzwerkschnittstellen in einer bestimmten Reihenfolge initialisiert werden.

Stellen Sie sicher, dass sich die PIF in einem separaten Subnetz befindet oder dass das Routing so konfiguriert ist, dass es Ihrer Netzwerktopologie entspricht, um den gewünschten Datenverkehr über die ausgewählte PIF zu erzwingen.

Richten Sie eine IP-Konfiguration für die PIF ein und fügen Sie geeignete Werte für den Modusparameter hinzu. Wenn Sie 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-->

Setzen Sie den Parameter „disallow-unplug“ der 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 den Speicher verwenden möchten, die auch von der Verwaltungsschnittstelle aus geroutet werden kann (wobei zu beachten ist, dass diese Konfiguration nicht der Best Practice entspricht), haben Sie zwei Optionen:

• Stellen Sie nach einem Host-Neustart 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 korrekte Schnittstelle.

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

SR-IOV-fähige NICs verwenden

Single Root I/O Virtualization (SR-IOV) ist eine Virtualisierungstechnologie, die es einem einzelnen PCI-Gerät ermöglicht, auf dem physischen System als mehrere PCI-Geräte zu erscheinen. Das eigentliche physische Gerät wird als Physical Function (PF) bezeichnet, während die anderen als Virtual Functions (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.

Das Zuweisen einer oder mehrerer NIC-VFs zu einer VM ermöglicht es, dass ihr Netzwerkverkehr den virtuellen Switch umgeht. Nach 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

Eine SR-IOV VF hat eine bessere Leistung als VIF. Sie kann die hardwarebasierte Trennung des Datenverkehrs verschiedener VMs über dieselbe NIC gewährleisten (wobei der XenServer-Netzwerk-Stack umgangen wird).

Mit dieser Funktion können Sie:

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

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

• SR-IOV VFs als VF-Ressourcenpool verwalten.

• SR-IOV VFs einer VM zuweisen.

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

• Tests durchführen, 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. Die folgenden Technologien sind erforderlich:

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

• Alternative Routing-ID-Interpretation (ARI)

• Adressübersetzungsdienste (ATS)

• Zugriffskontrolldienste (ACS)

Informationen zur Konfiguration der Systemfirmware zur Aktivierung der genannten Technologien finden Sie in der Dokumentation Ihres Systems.

Ein SR-IOV-Netzwerk auf einer NIC aktivieren

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

Ein SR-IOV-Netzwerk der virtuellen Schnittstelle zuweisen (VM-Ebene)

Verwenden Sie in XenCenter auf VM-Ebene den Assistenten Virtuelle Schnittstelle hinzufügen 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 Ein neues Netzwerk hinzufügen.

Unterstützte NICs und Gäste

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

Einschränkungen

• Bei bestimmten NICs, die ältere 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 verschiedenen NIC-Typen wird nicht unterstützt.

• Eine SR-IOV VF und eine normale VIF derselben NIC können möglicherweise aufgrund der Hardwarebeschränkungen der NIC nicht miteinander kommunizieren. Um diesen VMs die Kommunikation zu ermöglichen, stellen Sie sicher, dass die Kommunikation dem Muster VF zu VF oder VIF zu VIF folgt und nicht VF zu VIF.

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

• Die Durchführung von Live-Migration, Suspend und Checkpoint wird bei VMs, die eine SR-IOV VF verwenden, nicht unterstützt.

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

• SR-IOV VFs unterstützen keinen Netzwerk-Boot.

• Bei einigen NICs mit älteren NIC-Treibern kann ein Neustart erforderlich sein, selbst nach einem Host-Neustart, was darauf hindeutet, dass die NIC SR-IOV nicht aktivieren kann.

• Wenn Ihre VM eine SR-IOV VF hat, sind Funktionen, die eine Live-Migration erfordern, nicht möglich. Dies liegt daran, dass die VM direkt an die physische SR-IOV-fähige NIC VF gebunden ist.

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

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

SR-IOV VFs für ältere Treiber konfigurieren

Normalerweise kann die maximale Anzahl von VFs, die eine NIC unterstützen kann, automatisch ermittelt werden. Bei NICs, die ältere Treiber verwenden (z. B. Intel I350-Familie), ist die Grenze in der Konfigurationsdatei des Treibermoduls definiert. Die Grenze muss möglicherweise manuell angepasst werden. Um sie auf das Maximum zu setzen, öffnen Sie die Datei mit einem Editor und ändern Sie die Zeile, die beginnt mit:

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

Um beispielsweise die maximale Anzahl von VFs für den igb-Treiber auf 4 zu setzen, 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-default sein.

• Ä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.

Rate ausgehender Daten steuern (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. Die Einstellung ermöglicht es Ihnen, eine maximale Übertragungsrate für ausgehende Pakete in Kilobyte pro Sekunde anzugeben.

Der Quality of Service-Wert begrenzt die Übertragungsrate von der VM. Die Quality of Service-Einstellung begrenzt nicht die Datenmenge, die die VM empfangen kann. Wenn eine solche Begrenzung gewünscht wird, empfehlen wir, die Rate der eingehenden Pakete weiter oben im Netzwerk (z. B. auf Switch-Ebene) zu begrenzen.

Abhängig vom im Pool konfigurierten Netzwerk-Stack 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 Sie können den Quality of Service-Übertragungsratenbegrenzungswert im Eigenschaften-Dialog für die virtuelle Schnittstelle festlegen.
• xe-Befehle Sie können die Quality of Service-Übertragungsrate über die CLI mit den Befehlen im folgenden Abschnitt festlegen.

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

Um eine VIF auf eine maximale Übertragungsrate von 100 Kilobyte pro Sekunde über die CLI 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).

Netzwerkkonfigurationsoptionen ändern

Dieser Abschnitt beschreibt, wie Sie die Netzwerkkonfiguration Ihres XenServer-Hosts ändern können. Er umfasst:

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

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

• Ändern von IP-Adressen

• Ändern der als Verwaltungsschnittstelle verwendeten NIC

• Hinzufügen einer neuen physischen NIC 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 bekannt, ist in der poolweiten Datenbank definiert und wird 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. Zum Beispiel für eine PIF mit einer statischen IP:

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

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

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

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

IP-Adresskonfiguration in Ressourcenpools ändern

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 zum Ändern der IP-Adresse der Verwaltungsschnittstelle eines Hosts 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 Speicher reparieren in XenCenter oder mit dem CLI-Befehl pbd-plug erneut verbunden werden. Aus diesem Grund empfehlen wir, VMs vom Host zu migrieren, bevor Sie dessen IP-Konfiguration ändern.

Verwenden Sie den CLI-Befehl pif-reconfigure-ip, um die IP-Adresse wie gewünscht festzulegen. Details 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 Mitglieds-Host erfolgreich wieder mit dem Pool-Koordinator verbunden wurde, indem Sie überprüfen, ob alle anderen XenServer-Hosts im Pool sichtbar sind:

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

Das Ändern der IP-Adresse des Pool-Koordinator-XenServer-Hosts erfordert zusätzliche Schritte. Dies liegt daran, dass jedes Pool-Mitglied die beworbene IP-Adresse des Pool-Koordinators für die Kommunikation verwendet. Die Pool-Mitglieder wissen nicht, wie sie den Pool-Koordinator kontaktieren können, wenn sich dessen IP-Adresse ändert.

Verwenden Sie, wann immer möglich, eine dedizierte IP-Adresse, die sich während der Lebensdauer des Pools für Pool-Koordinatoren voraussichtlich nicht ändert.

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 Pool-Koordinators ändert, wechseln alle Mitglieds-Hosts in einen 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 es über die neue IP-Adresse des Pool-Koordinators zu informieren:

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

Verwaltungsschnittstelle

Wenn Sie XenServer auf einem Host installieren, wird eine seiner NICs als Verwaltungsschnittstelle festgelegt: die NIC, die für den XenServer-Verwaltungsdatenverkehr verwendet wird. Die Verwaltungsschnittstelle wird für XenCenter-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 bestimmen, welche PIF der als Verwaltungsschnittstelle zu verwendenden NIC entspricht. Die UUID jeder PIF wird zurückgegeben.

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

Verwenden Sie den Befehl pif-param-list, um die IP-Adresskonfiguration für die als Verwaltungsschnittstelle verwendete PIF zu überprüfen. Verwenden Sie bei Bedarf den Befehl pif-reconfigure-ip, um die IP-Adressierung für die zu verwendende 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 Konsole des Mitgliedshosts ausgeführt werden:

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

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

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

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

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

Verwendung von Port 80 einschränken

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 weiterhin geöffnet. Wenn Sie ihn schließen, müssen alle externen Clients, die die Verwaltungsschnittstelle verwenden, HTTPS über Port 443 verwenden, um eine Verbindung zu XenServer herzustellen. Bevor Sie Port 80 schließen, überprüfen Sie jedoch, ob alle Ihre API-Clients (insbesondere Citrix Virtual Apps and Desktops) HTTPS über Port 443 verwenden können.

Um Port 80 zu schließen, siehe den xe CLI-Befehl https-only oder Pooleigenschaften ändern in der XenCenter-Dokumentation.

Verwaltungszugriff deaktivieren

Um den Fernzugriff 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 auszuführen. Externe Schnittstellen wie XenCenter funktionieren nicht, wenn die Verwaltungsschnittstelle deaktiviert ist.

Neue physische NIC hinzufügen

1. Installieren Sie eine neue physische NIC auf Ihrem XenServer-Host auf die übliche Weise.
2. Starten Sie Ihren XenServer-Host neu.

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

   xe pif-list host-uuid=<host_uuid>
   

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

   xe pif-scan host-uuid=<host_uuid>
   

   Dieser Befehl erstellt ein neues PIF-Objekt für die neue NIC.

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

   xe pif-list host-uuid=<host_uuid>
   

6. Die neue PIF wird zunächst als getrennt (currently-attached ( RO): false) aufgeführt. Um sie zu aktivieren, verwenden Sie den folgenden Befehl:

   xe pif-plug uuid=<uuid_of_pif>
   

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

Physische NIC entfernen

Bevor Sie die NIC entfernen, stellen Sie sicher, dass Sie die UUID der entsprechenden PIF kennen. Entfernen Sie die physische NIC auf die übliche Weise 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.

Einem Netzwerk einen Zweck hinzufügen

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

Um einen Netzwerkzweck hinzuzufügen, verwenden Sie den Befehl xe 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 Befehl xe 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 im XenServer Changed Block Tracking Guide.

Switch-Port-Sperre verwenden

Die XenServer Switch-Port-Sperrfunktion ermöglicht es Ihnen, den Datenverkehr von unbekannten, nicht vertrauenswürdigen oder potenziell feindlichen VMs zu steuern, indem Sie deren Fähigkeit einschränken, vorzugeben, eine MAC- oder IP-Adresse zu haben, die ihnen nicht zugewiesen wurde. Sie können die Port-Sperrbefehle 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 Verwendung der Switch-Port-Sperre vereinfacht Ihre Netzwerkkonfiguration, indem alle Ihre Mandanten oder Gäste dasselbe Layer-2-Netzwerk verwenden können.

Eine der wichtigsten Funktionen der Port-Sperrbefehle 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, vorzugeben, eine MAC- oder IP-Adresse zu besitzen, die er tatsächlich nicht hat. Insbesondere können Sie diese Befehle verwenden, um einen Gast daran zu hindern, Folgendes zu tun:

• Eine IP- oder MAC-Adresse zu beanspruchen, die nicht den vom XenServer-Administrator angegebenen Adressen entspricht, die er verwenden darf

• Den Datenverkehr anderer VMs abzufangen, zu fälschen oder zu stören

Anforderungen

• Die XenServer Switch-Port-Sperrfunktion wird auf der Linux-Bridge (veraltet) und den vSwitch-Netzwerk-Stacks unterstützt.

• Wenn Sie die rollenbasierte Zugriffssteuerung (RBAC) in Ihrer Umgebung aktivieren, muss der Benutzer, der die Switch-Port-Sperre konfiguriert, mit einem Konto angemeldet sein, das mindestens die Rolle eines Pool-Operators oder Pool-Administrators besitzt. Wenn RBAC in Ihrer Umgebung nicht aktiviert ist, muss der Benutzer mit dem Root-Konto des Pool-Koordinators angemeldet sein.

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

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

Hinweise

Ohne Switch-Port-Sperrkonfigurationen werden VIFs auf „network_default“ und Netzwerke auf „unlocked“ gesetzt.

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

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

• Einen IP-Level-Angriff auf einen anderen Mandanten/Benutzer durchzuführen. Die Switch-Port-Sperre verhindert jedoch, dass sie den IP-Level-Angriff durchführen, wenn sie versuchen, die folgenden Mittel dazu zu verwenden und die Switch-Port-Sperre konfiguriert ist: a) sich als ein anderer Mandant in der Cloud oder Benutzer auszugeben oder b) das Abfangen von Datenverkehr einzuleiten, der für einen anderen Benutzer bestimmt ist.

• Netzwerkressourcen zu erschöpfen.

• Einen Teil des für andere virtuelle Maschinen bestimmten Datenverkehrs durch normales Switch-Flooding-Verhalten zu empfangen (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 möglicherweise die Verwendung der API.

Beispiele

Dieser Abschnitt enthält Beispiele, wie die Switch-Port-Sperre bestimmte Arten von Angriffen verhindern kann. In diesen Beispielen ist VM-c eine virtuelle Maschine, die ein feindlicher Mandant (Mandant C) für Angriffe mietet und verwendet. VM-a und VM-b sind virtuelle Maschinen, die von nicht angreifenden Mandanten gemietet werden.

Beispiel 1: Wie die Switch-Port-Sperre 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 potenziell dazu führen, dass der Datenverkehr des Knotens stattdessen an den Angreifer gesendet wird. Um dieses Ziel zu erreichen, sendet der Angreifer gefälschte (gespoofte) ARP-Nachrichten an ein Ethernet-LAN.

Szenario:

Virtuelle Maschine A (VM-a) möchte IP-Datenverkehr von VM-a an Virtuelle Maschine B (VM-b) senden, indem sie ihn an die IP-Adresse von VM-b adressiert. Der Besitzer von Virtueller Maschine C möchte ARP-Spoofing verwenden, um vorzugeben, dass seine VM, VM-c, tatsächlich VM-b ist.

1. VM-c sendet einen spekulativen Strom von ARP-Antworten an VM-a. Die ARP-Antworten behaupten, 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-Sperre aktiviert hat, werden diese Pakete alle verworfen, da die Aktivierung der Switch-Port-Sperre eine Identitätsfälschung verhindert.

2. VM-b sendet eine ARP-Antwort an VM-a, die 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-Prävention:

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

Szenario:

Mieter C versucht, einen Denial-of-Service-Angriff mit seinem Host, Host-C, auf ein entferntes System durchzuführen, um seine Identität zu verschleiern.

Versuch 1:

Mieter 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). Mieter C weist Host-C an, IP-Verkehr an ein entferntes System 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, weil die Aktivierung der Switch-Port-Sperre eine Identitätsfälschung verhindert.

Versuch 2:

Mieter C setzt die IP-Adresse von Host-C auf die IP-Adresse von VM-a (a_IP) und behält seine ursprüngliche c_MAC bei.

Mieter C weist Host-C an, IP-Verkehr an ein entferntes System zu senden.

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

Beispiel 3: Webhosting:

Szenario:

Alice ist eine Infrastrukturadministratorin.

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

Alice konfiguriert die VIF von Host-B neu, sodass sie an eine einzelne MAC, aber viele IP-Adressen gebunden ist.

So funktioniert die Switch-Port-Sperre

Die Switch-Port-Sperrfunktion ermöglicht es Ihnen, die Paketfilterung auf einer oder mehreren von zwei Ebenen zu steuern:

• VIF-Ebene. Die Einstellungen, die Sie für das VIF konfigurieren, bestimmen, wie Pakete gefiltert werden. Sie können das VIF so einstellen, dass die VM keinen Datenverkehr sendet, das VIF so einschränken, dass es nur Datenverkehr mit seiner zugewiesenen IP-Adresse senden kann, oder der VM erlauben, Datenverkehr an jede IP-Adresse im mit dem VIF verbundenen Netzwerk zu senden.

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

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 (veraltet) die Switch-Port-Sperre in IPv6 nicht vollständig.

VIF-Sperrmodus-Zustände

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 das VIF an eine laufende virtuelle Maschine angeschlossen ist.

• Network_default. Wenn der Zustand des VIF auf network_default eingestellt ist, verwendet XenServer den default-locking-mode-Parameter des Netzwerks, um zu bestimmen, ob und wie Pakete gefiltert werden, die durch das VIF laufen. Das Verhalten variiert je nachdem, ob für das zugehörige Netzwerk der Standard-Sperrmodus-Parameter auf „deaktiviert“ oder „entsperrt“ eingestellt ist:

  -default-locking-mode=disabled, XenServer wendet eine Filterregel an, sodass das VIF den gesamten Datenverkehr verwirft.

  -default-locking-mode=unlocked, XenServer entfernt alle mit dem VIF verbundenen Filterregeln. Standardmäßig ist der Standard-Sperrmodus-Parameter auf unlocked eingestellt.

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

  Der Standard-Sperrmodus des Netzwerks hat keine Auswirkung auf angeschlossene VIFs, deren Sperrzustand von network_default abweicht.

  Hinweis:

  Sie können den default-locking-mode eines Netzwerks, an das aktive VIFs angeschlossen sind, nicht ändern.

• Gesperrt. XenServer wendet Filterregeln an, sodass nur Datenverkehr, der an/von den angegebenen MAC- und IP-Adressen gesendet wird, über das VIF gesendet werden darf. In diesem Modus kann die VM, wenn keine IP-Adressen angegeben sind, 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 mithilfe der Parameter ipv4_allowed oder ipv6_allowed. Wenn Sie jedoch die Linux-Bridge (veraltet) konfiguriert haben, geben Sie keine IPv6-Adressen ein.

  XenServer ermöglicht die Eingabe von IPv6-Adressen, 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 keine Module zum Filtern von Neighbor Discovery Protocol (NDP)-Paketen besitzt. Daher kann kein vollständiger Schutz implementiert werden, und Gäste könnten sich als andere Gäste ausgeben, indem sie NDP-Pakete fälschen. Wenn Sie daher auch nur eine IPv6-Adresse angeben, lässt XenServer den gesamten IPv6-Verkehr über das VIF passieren. Wenn Sie keine IPv6-Adressen angeben, lässt XenServer keinen IPv6-Verkehr zum VIF passieren.

  Hinweis:

  Der Linux-Bridge-Netzwerk-Stack ist veraltet und wird in einer zukünftigen Version entfernt werden.

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

• Deaktiviert. Es ist kein Datenverkehr erlaubt, der das VIF passiert. (Das heißt, XenServer wendet eine Filterregel an, sodass das VIF den gesamten Datenverkehr verwirft.)

Switch-Port-Sperrung konfigurieren

Dieser Abschnitt bietet drei verschiedene Verfahren:

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

• Eine IP-Adresse zu einer bestehenden eingeschränkten Liste hinzufügen. Zum Beispiel, um einem VIF eine IP-Adresse hinzuzufügen, wenn die VM läuft und mit dem Netzwerk verbunden ist (zum Beispiel, wenn Sie ein Netzwerk vorübergehend offline nehmen).

• Eine IP-Adresse aus einer bestehenden eingeschränkten Liste entfernen

Wenn der Sperrmodus eines VIF auf locked eingestellt ist, kann es nur die in den Parametern ipv4-allowed oder ipv6-allowed 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 durchführen, bevor oder nachdem das VIF angeschlossen (oder die VM gestartet) wurde.

Ändern Sie den Standard-Sperrmodus auf gesperrt, falls dieser Modus noch nicht verwendet wird, indem Sie den folgenden Befehl ausführen:

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

Das vif-uuid stellt die UUID des VIF dar, das Datenverkehr senden darf. Um die UUID zu erhalten, führen Sie den Befehl xe vif-list auf dem Host aus. vm-uuid Zeigt 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. Zum 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. Zum 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 diese, wie im vorhergehenden Beispiel gezeigt, durch ein Komma trennen.

Nachdem Sie das Verfahren zur Beschränkung eines VIF auf die Verwendung einer bestimmten IP-Adresse durchgefü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 einen oder mehrere der folgenden Schritte aus:

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

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

• Geben Sie die IPv6-IP-Adresse an. Zum 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 einen oder mehrere der folgenden Schritte aus:

• Geben Sie die zu löschende IPv4-IP-Adresse an. Zum 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. Zum 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 ein bestimmtes VIF kommuniziert. Da ein VIF mit einem bestimmten XenServer-Netzwerk verbunden ist, 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 granularere Kontrolle als das Deaktivieren eines gesamten Netzwerks.

Wenn Sie den CLI-Befehl verwenden, müssen Sie das VIF nicht trennen, um den Sperrmodus des VIF festzulegen. Der Befehl ändert die Filterregeln, während das VIF läuft. In diesem Fall scheint die Netzwerkverbindung weiterhin zu bestehen, das 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 ein VIF Datenverkehr empfängt, deaktivieren Sie das VIF, das 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 das VIF auch in XenCenter deaktivieren, indem Sie die virtuelle Netzwerkschnittstelle auf der Registerkarte Networking der VM auswählen und auf Deaktivieren klicken.

Einschränkung eines VIF auf eine IP-Adresse aufheben

Um zum Standard- (ursprünglichen) Sperrmodus-Zustand zurückzukehren, verwenden Sie das folgende Verfahren. Standardmäßig konfiguriert XenServer ein VIF bei dessen Erstellung so, dass es nicht auf die Verwendung einer bestimmten IP-Adresse beschränkt ist.

Um ein VIF in einen entsperrten Zustand zurückzuversetzen, ändern Sie den VIF-Standardsperrmodus auf 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-->

VIF-Sperrmodus-Konfiguration in der Cloud vereinfachen

Anstatt die VIF-Sperrmodus-Befehle 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. Das Ändern der Paketfilterung bewirkt, dass das XenServer-Netzwerk bestimmt, wie Pakete gefiltert werden, wie im vorherigen Abschnitt Funktionsweise der Switch-Port-Sperre beschrieben.

Insbesondere bestimmt die default-locking-mode-Einstellung eines Netzwerks, wie sich neue VIFs mit Standardeinstellungen verhalten. Immer wenn die locking-mode eines VIF auf default gesetzt ist, bezieht sich das VIF auf den Netzwerk-Sperrmodus (default-locking-mode), um zu bestimmen, ob und wie Pakete gefiltert werden, die durch das VIF laufen:

• Entsperrt. Wenn der Netzwerkparameter default-locking-mode auf unlocked gesetzt ist, lässt XenServer die VM Datenverkehr an jede IP-Adresse im Netzwerk senden, mit dem das VIF verbunden ist.

• Deaktiviert. Wenn der Parameter default-locking-mode auf disabled gesetzt ist, wendet XenServer eine Filterregel an, sodass das VIF den gesamten Datenverkehr verwirft.

Standardmäßig ist die default-locking-mode für alle in XenCenter erstellten und über die CLI verwendeten Netzwerke auf unlocked gesetzt.

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

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

Standardmäßig werden VIFs beispielsweise mit ihrem locking-mode auf network_default erstellt. Wenn Sie den default-locking-mode eines Netzwerks auf disabled setzen, werden alle neuen VIFs, für die Sie den Sperrmodus nicht konfiguriert haben, deaktiviert. Die VIFs bleiben deaktiviert, bis Sie entweder (a) den locking-mode-Parameter des einzelnen VIFs ändern oder (b) den locking-mode des VIFs explizit auf unlocked setzen. Dies ist hilfreich, wenn Sie einer bestimmten VM so weit vertrauen, dass Sie ihren Datenverkehr überhaupt nicht filtern möchten.

So ändern Sie die Standardeinstellung des Sperrmodus eines Netzwerks:

Nachdem Sie das Netzwerk erstellt haben, ändern Sie den Standard-Sperrmodus, 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. 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 des 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 VIF-Datenverkehrsfilterung verwenden

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

1. Ändern Sie den VIF-Sperrstatus auf network_default, falls er diesen Modus noch nicht verwendet, indem Sie den folgenden Befehl ausführen:

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

2. Ändern Sie den Standard-Sperrmodus auf unlocked, falls er diesen Modus noch nicht verwendet, indem Sie den folgenden Befehl ausführen:

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