XenServer

Netzwerke verwalten

August 1, 2026

Beitrag von:

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 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 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, 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. Netzwerk X entspricht der Netzwerkschnittstelle an Position X unter dem Dom0-Netzwerkbenennungsmodell.

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 den ersten beiden Netzwerkschnittstellen von host1 entsprechen, auf host2 gültig. VMs auf host1 mit VIFs, die mit Netzwerken verbunden sind, die den verbleibenden Netzwerkschnittstellen entsprechen, können nicht auf Host host2 migriert werden.

VLANs erstellen

Für Hosts in einem Ressourcenpool können Sie den pool-vlan-create Befehl 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 pif-list Befehl, 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 Netzwerke auf einem eigenständigen Host erstellen.

NIC-Bonds auf einem eigenständigen Host erstellen

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

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, nimmt der Bond das als Verwaltungsschnittstelle verwendete PIF/NIC auf. Die Verwaltungsschnittstelle wird automatisch auf das Bond-PIF verschoben.

Verwenden Sie den network-create Befehl, 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

```
Verwenden Sie den pif-list Befehl, um die UUIDs der im Bond zu verwendenden PIFs zu bestimmen:
```
xe pif-list

```
Führen Sie einen der folgenden Schritte aus:
- Um den Bond im Aktiv-Aktiv-Modus (Standard) zu konfigurieren, verwenden Sie den bond-create Befehl, 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
 
```
  Geben Sie zwei UUIDs ein, wenn Sie zwei NICs binden, und vier UUIDs, wenn Sie vier NICs binden. Die UUID für den Bond wird nach Ausführung des Befehls zurückgegeben.
- Um den Bond im Aktiv-Passiv- oder LACP-Bond-Modus zu konfigurieren, verwenden Sie dieselbe Syntax, fügen Sie den optionalen Parameter mode hinzu und geben Sie lacp oder active-backup an:
```
 xe bond-create network-uuid=network_uuid pif-uuids=pif_uuid_1, /
      pif_uuid_2,pif_uuid_3,pif_uuid_4 /
      mode=balance-slb | active-backup | lacp
 
```

MAC-Adresse des Bonds steuern

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

Sie können die MAC-Adresse des Bonds ändern, sodass sie sich von der MAC-Adresse der (aktuellen) NIC der Verwaltungsschnittstelle unterscheidet. Wenn der 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 einen Bond auf zwei Arten steuern:

Ein optionaler Parameter mac kann im Befehl bond-create angegeben werden. Sie können diesen Parameter verwenden, um die MAC-Adresse des Bonds auf eine beliebige Adresse festzulegen.
Wenn der Parameter mac nicht angegeben wird, verwendet XenServer die MAC-Adresse der Verwaltungsschnittstelle, falls diese eine der Schnittstellen im Bond ist. Wenn die Verwaltungsschnittstelle nicht Teil des Bonds ist, aber eine andere Verwaltungsschnittstelle vorhanden ist, verwendet der Bond die MAC-Adresse (und auch die IP-Adresse) dieser Verwaltungsschnittstelle. Wenn keine der NICs im Bond eine Verwaltungsschnittstelle ist, verwendet der Bond die MAC der zuerst genannten NIC.

NIC-Bonds zurücksetzen

Beim Zurücksetzen des XenServer-Hosts auf eine nicht-gebundene Konfiguration konfiguriert der Befehl bond-destroy 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 beim Ausführen von bond-destroy das Verwaltungs-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 des Bonds kopiert wurde. Beim Binden von zwei NICs ist die primäre NIC:

Die NIC der Verwaltungsschnittstelle (wenn die Verwaltungsschnittstelle eine der gebundenen NICs ist).
Jede andere NIC mit einer IP-Adresse (wenn die Verwaltungsschnittstelle nicht Teil des Bonds war).
Die zuerst genannte NIC. Sie können herausfinden, welche dies ist, indem Sie Folgendes ausführen:
```
xe bond-list params=all

```

NIC-Bonds in Ressourcenpools erstellen

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

Das Hinzufügen eines NIC-Bonds zu einem bestehenden Pool 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.

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

Dieser Abschnitt beschreibt die Verwendung der xe CLI zum Erstellen von gebündelten NIC-Schnittstellen auf XenServer-Hosts, die einen Ressourcenpool 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 Hosts sich selbst abschirmen (sich selbst herunterfahren). Die Hosts können möglicherweise nicht ordnungsgemäß neu starten und benötigen möglicherweise den Befehl host-emergency-ha-disable, um wiederhergestellt zu werden.

Wählen Sie den Host aus, der der Pool-Koordinator sein soll. Der Pool-Koordinator 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 den NIC-Bond wie unter Einen NIC-Bond erstellen beschrieben.

Öffnen Sie eine Konsole auf einem Host, den Sie dem Pool 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 wurde, 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.

Eine dedizierte Speicher-NIC konfigurieren

Sie können XenCenter oder die xe-CLI verwenden, um einer NIC eine IP-Adresse zuzuweisen und sie einer bestimmten Funktion, wie z. B. Speicherverkehr, zu widmen. 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 Managementschnittstelle 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 begrenzt, 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:

falls zutreffend, im selben Subnetz wie der Speicher-Controller liegt, und
nicht im selben Subnetz wie andere sekundäre Schnittstellen oder die Managementschnittstelle liegt.

Wenn Sie sekundäre Schnittstellen konfigurieren, muss jede sekundäre Schnittstelle in einem separaten Subnetz liegen. 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 Managementschnittstelle, ein Subnetz für die sekundäre Schnittstelle 1 und ein Subnetz für die sekundäre Schnittstelle 2.

Hinweis:

Wenn Sie eine NIC als sekundäre Schnittstelle für die Verwendung mit iSCSI- oder NFS-SRs auswählen, stellen Sie sicher, dass die dedizierte NIC ein separates IP-Subnetz verwendet, das von der Managementschnittstelle aus nicht routbar ist. Wird dies nicht erzwungen, kann der Speicherverkehr nach einem Host-Neustart über die Haupt-Managementschnittstelle geleitet werden, da die Reihenfolge, in der Netzwerkschnittstellen initialisiert werden, dies beeinflusst.

Stellen Sie sicher, dass die PIF in einem separaten Subnetz liegt oder 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 Modus-Parameter 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 Managementschnittstelle aus geroutet werden kann (wobei zu beachten ist, dass diese Konfiguration nicht der besten Praxis 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 Kontrolldomä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, als mehrere PCI-Geräte auf dem physischen System 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 dem Netzwerkverkehr, den virtuellen Switch zu umgehen. Bei 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)
Zugriffssteuerungsdienste (ACS)

Informationen zur Konfiguration der Systemfirmware, um die genannten Technologien zu aktivieren, finden Sie in der Dokumentation Ihres Systems.

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.

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 Neues Netzwerk hinzufügen.

Unterstützte NICs und Gäste

Eine Liste der unterstützten Hardwareplattformen und NICs finden Sie unter Hardware-Kompatibilitätsliste. Die Dokumentation des Anbieters für einen bestimmten Gast enthält Informationen darüber, ob SR-IOV unterstützt wird.

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 von derselben NIC können aufgrund von Hardwarebeschränkungen der NIC möglicherweise nicht miteinander kommunizieren. Um die Kommunikation dieser VMs 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.
Live-Migration, Suspend und Checkpoint werden für 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 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. Diese Ressourcen umfassen 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), wird die Grenze in der Konfigurationsdatei des Treibermoduls definiert. Die Grenze muss möglicherweise manuell angepasst werden. Um sie auf das Maximum einzustellen, ö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 einzustellen, 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

Anweisungen zur Erstellung, Löschung und Anzeige von SR-IOV-Netzwerken sowie zur Zuweisung eines SR-IOV-VF zu einer VM über die CLI finden Sie unter (/de-de/xenserver/9/command-line-interface.html#sr-iov-commands).

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. Falls 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 Eigenschaftendialog 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. Dazu gehören:

Ändern des Hostnamens (d. h. des Domain Name System (DNS)-Namens)
DNS-Server hinzufügen oder löschen
IP-Adressen ändern
Ändern, welche NIC als Verwaltungsschnittstelle verwendet wird
Hinzufügen einer neuen physischen NIC zum Server
Hinzufügen eines Zwecks zu einem Netzwerk
ARP-Filterung aktivieren (Switch-Port-Sperre)

Hostname

Der System-Hostname, auch bekannt als Domänen- oder DNS-Name, ist in der Pool-weiten 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. Weitere Informationen 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 Pool-Koordinatoren 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. 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 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-Koordinators 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 sollen, wenn sich dessen IP-Adresse ändert.

Verwenden Sie nach Möglichkeit eine dedizierte IP-Adresse, die sich während der Lebensdauer des Pools für Pool-Koordinatoren voraussichtlich nicht ändern wird.

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

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

Wenn sich die IP-Adresse des 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 bezeichnet: 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 Mitglieds-Hosts ausgeführt werden:

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

Verwenden Sie den network-list-Befehl, 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 network-param-list-Befehl, um die PIF-UUIDs aller Hosts im Pool abzurufen. Verwenden Sie den pif-param-list-Befehl, um die IP-Adresskonfiguration für die PIF der Verwaltungsschnittstelle zu überprüfen. Verwenden Sie bei Bedarf den pif-reconfigure-ip-Befehl, um die IP-Adressierung für die zu verwendende PIF zu konfigurieren.

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

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

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

Nutzung 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 ist Port 80 bei Neuinstallationen standardmäßig geschlossen. Upgrades behalten die vorhandenen Porteinstellungen bei.

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

Verwaltungszugriff deaktivieren

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

Warnung:

Wenn die Verwaltungsschnittstelle deaktiviert ist, müssen Sie sich an der physischen Host-Konsole anmelden, um Verwaltungsaufgaben auszuführen. Externe Schnittstellen wie XenCenter funktionieren nicht, wenn die Verwaltungsschnittstelle deaktiviert ist.

Neue physische NIC hinzufügen

Installieren Sie eine neue physische NIC auf Ihrem XenServer-Host auf die übliche Weise.
Starten Sie Ihren XenServer-Host neu.
Listen Sie alle physischen NICs für diesen XenServer-Host mit dem folgenden Befehl auf:
```
xe pif-list host-uuid=<host_uuid>
```
Wenn Sie die zusätzliche NIC nicht sehen, 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.
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>
```
Die neue PIF wird anfänglich 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 nach neuen NICs zu suchen. Weitere Informationen finden Sie unter NICs konfigurieren 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 von unbekannten, nicht vertrauenswürdigen oder potenziell feindlichen VMs gesendeten Datenverkehr 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 spezifische 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 haben, die er tatsächlich nicht besitzt. Insbesondere können Sie diese Befehle verwenden, um einen Gast daran zu hindern, Folgendes zu tun:

Das Beanspruchen einer IP- oder MAC-Adresse, die nicht von dem XenServer-Administrator zur Nutzung freigegeben wurde
Das Abfangen, Spoofing oder Stören des Datenverkehrs anderer VMs

Anforderungen

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 „Pool-Operator“ oder „Pool-Administrator“ besitzt. Wenn RBAC in Ihrer Umgebung nicht aktiviert ist, muss der Benutzer mit dem Root-Konto für den Pool-Koordinator angemeldet sein.
Wenn Sie die Befehle zur Switch-Port-Sperre ausführen, können Netzwerke online oder offline sein.
In Windows-Gästen wird das Symbol für die getrennte Netzwerkverbindung nur angezeigt, wenn die XenServer VM Tools im Gast installiert sind.

Hinweise

Ohne jegliche Konfigurationen zur Switch-Port-Sperre sind VIFs auf „network_default“ und Netzwerke auf „unlocked“ eingestellt.

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:

Einen Angriff auf IP-Ebene auf einen anderen Mandanten/Benutzer durchzuführen. Die Switch-Port-Sperre verhindert jedoch, dass sie den Angriff auf IP-Ebene 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 als 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.

Implementierungshinweise

Sie können die Switch-Port-Sperrfunktion entweder über die Befehlszeile oder die XenServer-API implementieren. In großen Umgebungen, in denen Automatisierung ein primäres Anliegen ist, ist die typischste Implementierungsmethode jedoch 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) mietet und für Angriffe 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:

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

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 die Identitätsfälschung verhindert.
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:

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

Versuch 1:

Mandant C setzt die IP-Adresse und MAC-Adresse von Host-C auf die IP- und MAC-Adressen von VM-a (a_IP und a_MAC). Mandant C weist Host-C an, IP-Verkehr an ein 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 die Nachahmung verhindert.

Versuch 2:

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

Mandant 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 Nachahmung verhindert.

Beispiel 3: Webhosting:

Szenario:

Alice ist eine Infrastrukturadministratorin.

Einer ihrer Mandanten, Mandant B, hostet mehrere Websites von seiner VM, VM-b. Jede Website benötigt eine eindeutige 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 Ihnen die Steuerung der Paketfilterung auf einer oder mehreren von zwei Ebenen:

VIF-Ebene. Die Einstellungen, die Sie auf der VIF konfigurieren, bestimmen, wie Pakete gefiltert werden. Sie können die VIF so einstellen, dass die VM keinen Datenverkehr senden kann, die VIF so einschränken, dass sie nur Datenverkehr über ihre zugewiesene IP-Adresse senden kann, oder der VM erlauben, Datenverkehr an jede IP-Adresse im mit der 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.

Zustände des 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 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 sollen, die durch das VIF laufen. Das Verhalten variiert je nachdem, ob das zugehörige Netzwerk den Parameter für den Standard-Sperrmodus des Netzwerks auf ‘disabled’ oder ‘unlocked’ gesetzt hat:

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

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

Informationen zum default-locking-mode-Parameter 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 nicht ändern, an das aktive VIFs angeschlossen sind.
Gesperrt. XenServer wendet Filterregeln an, sodass nur Datenverkehr, der an/von den angegebenen MAC- und IP-Adressen gesendet wird, über das VIF ausgeleitet 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.
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 enthält 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 eine IP-Adresse zu einem VIF hinzuzufügen, wenn die VM läuft und mit dem Netzwerk verbunden ist (z. B. 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 vor oder nach dem Anschließen des VIF (oder dem Starten der VM) durchführen.

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

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 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 eine oder mehrere der folgenden Aktionen 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 durch ein Komma trennen, wie im vorhergehenden Beispiel gezeigt.

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 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. 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 eine bestimmte VIF kommuniziert. Da eine 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 detailliertere Kontrollebene als das Deaktivieren eines gesamten Netzwerks.

Wenn Sie den CLI-Befehl verwenden, müssen Sie die VIF nicht 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 einer VIF zu finden, führen Sie den Befehl xe vif-list auf dem Host aus. Die Geräte-ID gibt die Gerätenummer der 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 einer VIF-Beschränkung auf eine IP-Adresse

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

Um eine VIF in einen entsperrten Zustand zurückzuversetzen, ändern Sie den VIF-Standard-Sperrmodus auf „unlocked“. 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 jede VIF auszuführen, können Sie sicherstellen, dass alle VIFs standardmäßig deaktiviert sind. Dazu müssen Sie die Paketfilterung auf Netzwerkebene ändern. Die Änderung 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 einer VIF auf default gesetzt ist, bezieht sich die VIF auf den Netzwerk-Sperrmodus (default-locking-mode), um zu bestimmen, ob und wie Pakete gefiltert werden, die durch die VIF laufen:

Entsperrt. Wenn der Netzwerkparameter default-locking-mode auf unlocked gesetzt ist, erlaubt XenServer der VM, Datenverkehr an jede IP-Adresse im Netzwerk zu senden, mit dem die VIF verbunden ist.
Deaktiviert. Wenn der default-locking-mode-Parameter auf disabled gesetzt ist, wendet XenServer eine Filterregel an, sodass die 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 der VIF auf den 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 eine VIF, wenn ihre locking-mode auf ihre Standardeinstellung (network_default) gesetzt ist, den Netzwerk-default-locking-mode verwendet, um ihr Verhalten zu bestimmen.

Diese Abbildung zeigt, wie eine VIF, wenn sie mit ihrer Standardeinstellung (locking-mode=network_default) konfiguriert ist, die Einstellung überprüft, die mit dem default-locking-mode verbunden ist. In dieser Abbildung ist das Netzwerk auf default-locking-mode=disabled gesetzt, sodass kein Datenverkehr durch die VIF geleitet werden kann. ](/de-de/xenserver/9/media/networking-cloud-network-vif-locking-mode.png)

Beispielsweise werden VIFs standardmäßig mit ihrer locking-mode auf network_default gesetzt erstellt. Wenn Sie die 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 der einzelnen VIF ändern oder (b) die locking-mode der VIF 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 auf dem Netzwerk selbst zu verwenden, um zu bestimmen, wie der Datenverkehr gefiltert werden soll.

Ändern Sie den VIF-Sperrstatus in network_default, falls dieser Modus noch nicht verwendet wird, indem Sie den folgenden Befehl ausführen:
```
xe vif-param-set uuid=vif_uuid locking-mode=network_default

```
Ändern Sie den Standard-Sperrmodus in unlocked, falls dieser Modus noch nicht verwendet wird, indem Sie den folgenden Befehl ausführen:
```
xe network-param-set uuid=network-uuid default-locking-mode=unlocked

```

Die offizielle Version dieser Produktdokumentation ist in englischer Sprache verfasst. Nicht-englische Versionen wurden ausschließlich zu Ihrer Bequemlichkeit verfasst und können maschinell übersetzte Inhalte enthalten. Weitere Informationen finden Sie im Haftungsausschluss zur maschinellen Übersetzung (Machine Translation Disclaimer) auf Cloud Software Group home.

War dieser Artikel hilfreich?

Netzwerke verwalten

August 1, 2026

Beitrag von:

August 1, 2026

Beitrag von:

In diesem Artikel

Netzwerke auf einem eigenständigen Host erstellen
Netzwerke in Ressourcenpools erstellen
VLANs erstellen
NIC-Bonds auf einem eigenständigen Host erstellen
NIC-Bonds in Ressourcenpools erstellen
Eine dedizierte Speicher-NIC konfigurieren
SR-IOV-fähige NICs verwenden
Rate ausgehender Daten steuern (QoS)
Netzwerkkonfigurationsoptionen ändern

War dieser Artikel hilfreich?