Citrix Hypervisor

네트워킹 관리

February 3, 2025

제공::

중요:

Citrix Hypervisor 8.2 누적 업데이트 1은 2025년 6월 25일에 수명이 종료됩니다. 원활한 전환과 지속적인 지원을 위해 지금 XenServer 8로의 업그레이드를 계획하십시오. 자세한 내용은 업그레이드.

Citrix Virtual Apps and Desktops 라이센스 파일을 사용하여 Citrix Hypervisor 8.2 누적 업데이트 1 호스트에 라이센스를 부여하는 경우 이러한 라이센스 파일은 XenServer 8과 호환되지 않습니다. 업그레이드하기 전에 XenServer 8에서 사용할 XenServer Premium Edition 소켓 라이센스 파일을 얻어야 합니다. 이러한 소켓 라이센스 파일은 Citrix 워크로드를 실행하기 위한 Citrix for Private Cloud, Citrix Universal Hybrid Multi-Cloud, Citrix Universal MSP 및 Citrix Platform License 구독의 자격으로 사용할 수 있습니다. 아직 이러한 새로운 서브스크립션으로 전환하지 않은 Citrix 고객은 XenServer Premium Edition 소켓 라이센스 10,000개에 대한 무료 프로모션에 참여를 요청할 수 있습니다. 자세한 내용은 XenServer 서버.

업그레이드하기 전에 XenServer 8에 대한 호환 라이센스를 얻지 못한 경우 호스트를 업그레이드할 때 90일 평가판으로 되돌아갑니다. 평가판은 Premium Edition과 동일한 기능을 제공하지만 몇 가지 제한 사항이 있습니다. 자세한 내용은 XenServer 8 라이센스 개요.

이 섹션의 네트워크 구성 절차는 독립형 서버를 구성하는지 아니면 리소스 풀의 일부인 서버를 구성하는지에 따라 다릅니다.

독립형 서버에서 네트워크 생성

외부 네트워크는 호스트 설치 중에 각 PIF에 대해 생성되므로 일반적으로 다음과 같은 경우에만 추가 네트워크를 생성하면 됩니다.

개인 네트워크를 사용하세요
VLAN이나 NIC 본딩과 같은 고급 작업 지원

XenCenter를 사용하여 네트워크를 추가하거나 삭제하는 방법에 대한 자세한 내용은 XenCenter 설명서의 새 네트워크 추가 를 참조하세요.

Citrix Hypervisor 서버 텍스트 콘솔을 엽니다.

새로 생성된 네트워크의 UUID를 반환하는 network-create 명령을 사용하여 네트워크를 생성합니다.

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

이 시점에서 네트워크는 PIF에 연결되지 않았으므로 내부에 있습니다.

리소스 풀에서 네트워크 생성

리소스 풀에 있는 모든 Citrix Hypervisor 서버에는 동일한 수의 물리적 NIC가 있어야 합니다. 호스트가 풀에 가입하는 경우 이 요구 사항은 엄격하게 적용되지 않습니다. NIC 중 하나는 항상 Citrix Hypervisor 관리 트래픽에 사용되는 관리 인터페이스로 지정됩니다.

풀에 있는 모든 호스트는 공통적인 네트워크 세트를 공유합니다. 풀 내 Citrix Hypervisor 서버에 대해 동일한 물리적 네트워크 구성을 갖는 것이 중요합니다. 개별 호스트의 PIF는 장치 이름을 기반으로 풀 전체 네트워크에 연결됩니다. 예를 들어, eth0 NIC가 있는 풀에 있는 모든 Citrix Hypervisor 서버에는 풀 전체 네트워크 0 네트워크에 연결된 해당 PIF가 있습니다. 이는 eth1 NIC와 Network 1및 풀에 있는 하나 이상의 Citrix Hypervisor 서버에 있는 다른 NIC가 있는 호스트에도 해당됩니다.

한 Citrix Hypervisor 서버의 NIC 수가 풀의 다른 호스트와 다른 경우 문제가 발생할 수 있습니다. 모든 풀 호스트에 대해 모든 풀 네트워크가 유효한 것은 아니기 때문에 문제가 발생할 수 있습니다. 예를 들어, 호스트 host1 및 host2 가 동일한 풀에 있고 host1 에 NIC가 4개 있고 host2 에 NIC가 2개만 있는 경우, eth0 및 eth1에 해당하는 PIF에 연결된 네트워크만이 host2에서 유효합니다. eth2 및 eth3에 해당하는 네트워크에 연결된 VIF가 있는 host1 의 VM은 호스트 host2로 마이그레이션할 수 없습니다.

VLAN 생성

리소스 풀에 있는 서버의 경우 pool-vlan-create 명령을 사용할 수 있습니다. 이 명령은 VLAN을 생성하고 풀의 호스트에 필요한 PIF를 자동으로 생성하여 플러그인합니다. 자세한 내용은 pool-vlan-create을 참조하세요.

Citrix Hypervisor 서버 콘솔을 엽니다.

VLAN과 함께 사용할 네트워크를 생성합니다. 새 네트워크의 UUID가 반환됩니다.

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

pif-list 명령을 사용하여 원하는 VLAN 태그를 지원하는 물리적 NIC에 해당하는 PIF의 UUID를 찾습니다. 기존 VLAN을 포함하여 모든 PIF의 UUID와 장치 이름이 반환됩니다.

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

새 VLAN에 연결할 모든 VM에 원하는 물리적 PIF와 VLAN 태그를 지정하여 VLAN 객체를 만듭니다. 새로운 PIF가 생성되어 지정된 네트워크에 연결됩니다. 새로운 PIF 객체의 UUID가 반환됩니다.

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

새 네트워크에 VM VIF를 연결합니다. 자세한 내용은 독립형 서버에서 네트워크 만들기를 참조하세요.

독립 실행형 호스트에서 NIC 본드 생성

NIC 본드를 생성하려면 XenCenter를 사용하는 것이 좋습니다. 자세한 내용은 NIC 구성.

이 섹션에서는 풀에 없는 Citrix Hypervisor 서버에서 NIC 인터페이스를 본딩하기 위해 xe CLI를 사용하는 방법을 설명합니다. 리소스 풀을 구성하는 Citrix Hypervisor 서버에서 NIC 본드를 생성하기 위해 xe CLI를 사용하는 방법에 대한 자세한 내용은 리소스 풀에서 NIC 본드 생성을 참조하세요.

NIC 본드 생성

NIC를 본딩하면 본딩은 관리 인터페이스로 사용 중인 PIF/NIC를 흡수합니다. 관리 인터페이스는 자동으로 채권 PIF로 이동됩니다.

network-create 명령을 사용하여 본딩된 NIC와 함께 사용할 네트워크를 생성합니다. 새 네트워크의 UUID가 반환됩니다.
```
  xe network-create name-label=bond0

```
pif-list 명령을 사용하여 본드에 사용할 PIF의 UUID를 결정합니다.
```
  xe pif-list

```
다음 중 하나를 수행합니다.
- 활성-활성 모드(기본값)로 본드를 구성하려면 bond-create 명령을 사용하여 본드를 생성합니다. 매개변수를 구분하기 위해 쉼표를 사용하여 새로 생성된 네트워크 UUID와 본딩할 PIF의 UUID를 지정합니다.
```
   xe bond-create network-uuid=network_uuid /
        pif-uuids=pif_uuid_1,pif_uuid_2,pif_uuid_3,pif_uuid_4
 
```
  2개의 NIC를 본딩하는 경우에는 UUID를 2개 입력하고, 4개의 NIC를 본딩하는 경우에는 UUID를 4개 입력합니다. 명령을 실행한 후에는 본드의 UUID가 반환됩니다.
- 액티브-패시브 또는 LACP 본드 모드에서 본드를 구성하려면 동일한 구문을 사용하고 선택적 mode 매개변수를 추가하고 lacp 또는 active-backup를 지정합니다.
```
   xe bond-create network-uuid=network_uuid pif-uuids=pif_uuid_1, /
        pif_uuid_2,pif_uuid_3,pif_uuid_4 /
        mode=balance-slb | active-backup | lacp
 
```

본드의 MAC 주소를 제어합니다

관리 인터페이스를 본딩하면 사용 중인 PIF/NIC가 관리 인터페이스로 포함됩니다. 호스트가 DHCP를 사용하는 경우, 본드의 MAC 주소는 사용 중인 PIF/NIC와 동일합니다. 관리 인터페이스의 IP 주소는 변경되지 않을 수 있습니다.

본드의 MAC 주소를 (현재) 관리 인터페이스 NIC의 MAC 주소와 다르게 변경할 수 있습니다. 그러나 본드가 활성화되고 사용 중인 MAC/IP 주소가 변경되면 호스트에 대한 기존 네트워크 세션이 삭제됩니다.

본드의 MAC 주소는 두 가지 방법으로 제어할 수 있습니다.

선택 사항인 mac 매개변수는 bond-create 명령에서 지정할 수 있습니다. 이 매개변수를 사용하면 본드 MAC 주소를 임의의 주소로 설정할 수 있습니다.
mac 매개변수가 지정되지 않으면 Citrix Hypervisor는 본드의 인터페이스 중 하나인 경우 관리 인터페이스의 MAC 주소를 사용합니다. 관리 인터페이스가 본드의 일부가 아니지만 다른 관리 인터페이스가 본드의 일부인 경우 본드는 해당 관리 인터페이스의 MAC 주소(또한 IP 주소)를 사용합니다. 본드에 있는 NIC 중 어느 것도 관리 인터페이스가 아니면 본드는 첫 번째로 명명된 NIC의 MAC을 사용합니다.

NIC 채권을 되돌리다

Citrix Hypervisor 서버를 비본딩 구성으로 되돌릴 때 bond-destroy 명령은 자동으로 기본 NIC를 관리 인터페이스에 대한 인터페이스로 구성합니다. 따라서 모든 VIF는 관리 인터페이스로 이동됩니다. 호스트의 관리 인터페이스가 태그된 VLAN 본딩 인터페이스에 있는 경우, 본딩-파괴를 수행하면 관리 VLAN이 기본 NIC로 이동됩니다.

기본 NIC라는 용어는 본드를 생성할 때 MAC 및 IP 구성이 복사된 PIF를 나타냅니다. 두 개의 NIC를 본딩할 때 기본 NIC는 다음과 같습니다.

관리 인터페이스 NIC(관리 인터페이스가 본딩된 NIC 중 하나인 경우)
IP 주소가 있는 다른 NIC(관리 인터페이스가 본드의 일부가 아닌 경우).
첫 번째로 명명된 NIC. 다음을 실행하면 어느 것인지 확인할 수 있습니다.
```
  xe bond-list params=all

```

리소스 풀에서 NIC 본드 생성

가능하다면 더 많은 호스트를 풀에 가입시키거나 VM을 만들기 전에, 초기 리소스 풀 생성의 일부로 NIC 본드를 만드세요. 그렇게 하면 호스트가 풀에 가입할 때 본드 구성이 자동으로 호스트에 복제되고 필요한 단계 수가 줄어듭니다.

기존 풀에 NIC 본드를 추가하려면 다음 중 하나가 필요합니다.

CLI를 사용하여 마스터에서 본드를 구성한 다음 풀의 각 멤버에서 본드를 구성합니다.
CLI를 사용하여 마스터에서 본드를 구성한 다음 각 풀 멤버를 다시 시작하여 마스터의 설정을 상속하도록 합니다.
XenCenter를 사용하여 마스터에서 본드를 구성합니다. XenCenter는 구성원 서버의 네트워킹 설정을 마스터와 자동으로 동기화하므로 구성원 서버를 다시 시작할 필요가 없습니다.

간편하게 하고 잘못된 구성을 방지하기 위해 XenCenter를 사용하여 NIC 본드를 만드는 것이 좋습니다. 자세한 내용은 NIC 구성.

이 섹션에서는 Citrix Hypervisor 서버에서 리소스 풀을 구성하는 본딩된 NIC 인터페이스를 생성하기 위해 xe CLI를 사용하는 방법을 설명합니다. 독립형 호스트에서 xe CLI를 사용하여 NIC 본드를 생성하는 방법에 대한 자세한 내용은 독립형 호스트에서 NIC 본드 생성을 참조하세요.

경고:

고가용성이 활성화되어 있을 때는 네트워크 본드를 만들지 마세요. 본드 생성 프로세스가 진행 중인 고가용성 하트비트를 방해하여 호스트가 자체 펜싱(자체 종료)을 발생시킵니다. 호스트가 제대로 다시 시작되지 않을 수 있으며 복구하려면 host-emergency-ha-disable 명령이 필요할 수 있습니다.

마스터로 지정할 호스트를 선택하세요. 마스터 호스트는 기본적으로 이름이 지정되지 않은 풀에 속합니다. CLI로 리소스 풀을 생성하려면 기존 이름 없는 풀의 이름을 바꾸세요.

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

에서 설명한 대로 NIC 본드를 생성합니다.에서 설명한 대로 NIC 본드를 생성합니다.

풀에 가입하려는 호스트에서 콘솔을 열고 다음 명령을 실행합니다.

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

네트워크 및 본드 정보는 자동으로 새 호스트에 복제됩니다. 관리 인터페이스는 원래 구성된 호스트 NIC에서 본딩된 PIF로 자동 이동됩니다. 즉, 관리 인터페이스가 이제 본드에 흡수되어 전체 본드가 관리 인터페이스로 기능하게 됩니다.

host-list 명령을 사용하여 구성 중인 호스트의 UUID를 찾으세요.

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

경고:

고가용성이 활성화되어 있는 동안 네트워크 본드를 만들려고 하지 마세요. 본드 생성 프로세스가 진행 중인 고가용성 하트비트를 방해하여 호스트가 자체 펜싱(자체 종료)을 발생시킵니다. 호스트가 제대로 다시 시작되지 않을 수 있으며 복구하려면 host-emergency-ha-disable 명령을 실행해야 할 수 있습니다.

전용 스토리지 NIC 구성

XenCenter 또는 xe CLI를 사용하여 NIC에 IP 주소를 할당하고 스토리지 트래픽과 같은 특정 기능에 전담시킬 수 있습니다. IP 주소로 NIC를 구성하는 경우 보조 인터페이스를 생성하면 됩니다. (관리에 사용되는 IP 지원 NIC Citrix Hypervisor를 관리 인터페이스라고 합니다.)

특정 목적에 보조 인터페이스를 전용으로 지정하려는 경우 적절한 네트워크 구성이 되어 있는지 확인하세요. 이는 NIC가 원하는 트래픽에만 사용되도록 하기 위한 것입니다. NIC를 스토리지 트래픽에 전용하려면 NIC, 스토리지 대상, 스위치 및 VLAN을 구성하여 할당된 NIC를 통해서만 대상에 액세스할 수 있도록 합니다. 물리적 및 IP 구성이 스토리지 NIC를 통해 전송되는 트래픽을 제한하지 않는 경우 관리 트래픽 등의 트래픽을 보조 인터페이스를 통해 전송할 수 있습니다.

저장소 트래픽을 위한 새로운 보조 인터페이스를 생성할 때 다음과 같은 IP 주소를 할당해야 합니다.

해당되는 경우 스토리지 컨트롤러와 동일한 서브넷에 있음
다른 보조 인터페이스나 관리 인터페이스와 동일한 서브넷에 있지 않습니다.

보조 인터페이스를 구성할 때, 각 보조 인터페이스는 별도의 서브넷에 있어야 합니다. 예를 들어, 스토리지를 위해 두 개의 보조 인터페이스를 더 구성하려면 관리 인터페이스용 서브넷 하나, 보조 인터페이스 1용 서브넷 하나, 보조 인터페이스 2용 서브넷 하나 등 총 세 개의 서로 다른 서브넷에 IP 주소가 필요합니다.

저장소 트래픽의 복원력을 높이기 위해 본딩을 사용하는 경우 Linux 브리지 본딩 대신 LACP를 사용하는 것을 고려해 볼 수 있습니다. LACP 본딩을 사용하려면 네트워킹 스택으로 vSwitch를 구성해야 합니다. 자세한 내용은 vSwitch 네트워크를 참조하세요.

메모:

iSCSI 또는 NFS SR과 함께 사용할 보조 인터페이스로 구성할 NIC를 선택할 때 전용 NIC가 관리 인터페이스에서 라우팅할 수 없는 별도의 IP 서브넷을 사용하는지 확인하세요. 이것이 시행되지 않으면 네트워크 인터페이스가 초기화되는 순서로 인해 호스트가 재시작된 후 스토리지 트래픽이 주 관리 인터페이스를 통해 전송될 수 있습니다.

PIF가 별도의 서브넷에 있는지 또는 네트워크 토폴로지에 맞게 라우팅이 구성되어 원하는 트래픽이 선택한 PIF를 통해 강제로 전송되도록 해야 합니다.

PIF에 대한 IP 구성을 설정하고 모드 매개변수에 적절한 값을 추가합니다. 고정 IP 주소를 사용하는 경우 IP, 넷마스크, 게이트웨이 및 DNS 매개변수를 추가합니다.

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

PIF의 disallow-unplug 매개변수를 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-->

관리 인터페이스에서도 라우팅할 수 있는 스토리지용 보조 인터페이스를 사용하려는 경우(이 구성이 모범 사례는 아니라는 점을 명심하세요) 두 가지 옵션이 있습니다.

호스트를 다시 시작한 후 보조 인터페이스가 올바르게 구성되었는지 확인하세요. xe pbd-unplug 및 xe pbd-plug 명령을 사용하여 호스트의 스토리지 연결을 다시 초기화합니다. 이 명령은 저장소 연결을 다시 시작하고 올바른 인터페이스로 라우팅합니다.
또는 xe pif-forget 를 사용하여 Citrix Hypervisor 데이터베이스에서 인터페이스를 삭제하고 제어 도메인에서 수동으로 구성할 수 있습니다. xe pif-forget 는 고급 옵션이며 Linux 네트워킹을 수동으로 구성하는 방법을 알고 있어야 합니다.

SR-IOV 지원 NIC 사용

SR-IOV(단일 루트 I/O 가상화)는 단일 PCI 장치가 물리적 시스템에서 여러 개의 PCI 장치로 나타나도록 해주는 가상화 기술입니다. 실제 물리적 장치는 물리적 기능(PF)이라고 하며, 다른 장치는 가상 기능(VF)이라고 합니다. 하이퍼바이저는 하나 이상의 VF를 가상 머신(VM)에 할당할 수 있습니다. 그러면 게스트는 마치 직접 할당된 것처럼 장치를 사용할 수 있습니다.

하나 이상의 NIC VF를 VM에 할당하면 네트워크 트래픽이 가상 스위치를 우회할 수 있습니다. 구성 시, 각 VM은 NIC를 직접 사용하는 것처럼 동작하여 처리 오버헤드를 줄이고 성능을 향상시킵니다.

SR-IOV의 이점

SR-IOV VF는 VIF보다 성능이 더 좋습니다. 이는 동일한 NIC를 통해 서로 다른 VM의 트래픽 간에 하드웨어 기반 분리를 보장할 수 있습니다(Citrix Hypervisor 네트워크 스택을 우회).

이 기능을 사용하면 다음을 수행할 수 있습니다.

SR-IOV를 지원하는 NIC에서 SR-IOV를 활성화합니다.
SR-IOV를 지원하는 NIC에서 SR-IOV를 비활성화합니다.
SR-IOV VF를 VF 리소스 풀로 관리합니다.
VM에 SR-IOV VF를 할당합니다.
SR-IOV VF를 구성합니다(예: MAC 주소, VLAN, 속도).
SR-IOV가 자동 인증 키트의 일부로 지원되는지 확인하기 위해 테스트를 실행합니다.

시스템 구성

SR-IOV를 지원하도록 하드웨어 플랫폼을 올바르게 구성합니다. 다음과 같은 기술이 필요합니다.

I/O MMU 가상화(AMD-Vi 및 Intel VT-d)
대체 라우팅 ID 해석(ARI)
주소 번역 서비스(ATS)
접근 제어 서비스(ACS)

언급된 기술을 활성화하기 위해 BIOS를 구성하는 방법에 대한 자세한 내용은 시스템과 함께 제공된 설명서를 확인하세요.

NIC에서 SR-IOV 네트워크 활성화

XenCenter에서 네트워킹 탭의 새 네트워크 마법사를 사용하여 NIC에서 SR-IOV 네트워크를 만들고 활성화합니다.

가상 인터페이스(VM 수준)에 SR-IOV 네트워크 할당

XenCenter에서 VM 수준에서 네트워킹 탭에서 가상 인터페이스 추가 마법사를 사용하여 해당 VM에 대한 가상 인터페이스로 SR-IOV 지원 네트워크를 추가합니다. 자세한 내용은 새 네트워크 추가를 참조하세요.

지원되는 NIC 및 게스트

지원되는 하드웨어 플랫폼 및 NIC 목록은 하드웨어 호환성 목록을 참조하세요. 특정 게스트가 SR-IOV를 지원하는지 확인하려면 공급업체가 제공한 문서를 참조하세요.

제한 사항

레거시 드라이버(예: Intel I350 제품군)를 사용하는 특정 NIC의 경우 이러한 장치에서 SR-IOV를 활성화하거나 비활성화하려면 호스트를 재부팅해야 합니다.
SR-IOV는 HVM 게스트만 지원됩니다.
여러 유형의 NIC가 있는 풀 수준 SR-IOV 네트워크는 지원되지 않습니다.
동일한 NIC의 SR-IOV VF와 일반 VIF는 NIC 하드웨어 제한으로 인해 서로 통신하지 못할 수 있습니다. 이러한 호스트가 통신할 수 있도록 하려면 통신 패턴이 VF 대 VF 또는 VIF 대 VIF여야 하며 VF 대 VIF가 아니어야 합니다.
일부 SR-IOV VF의 서비스 품질 설정은 네트워크 속도 제한을 지원하지 않기 때문에 적용되지 않습니다.
SR-IOV VF를 사용하는 VM에서는 라이브 마이그레이션, 일시 중단 및 체크포인트를 수행할 수 없습니다.
SR-IOV VF는 핫 플러깅을 지원하지 않습니다.
레거시 NIC 드라이버를 사용하는 일부 NIC의 경우 호스트를 재시작한 후에도 재부팅이 필요할 수 있으며, 이는 NIC가 SR-IOV를 활성화할 수 없음을 나타냅니다.
이전 릴리스에서 생성된 VM은 XenCenter의 이 기능을 사용할 수 없습니다.
VM에 SR-IOV VF가 있는 경우 라이브 마이그레이션이 필요한 기능을 사용할 수 없습니다. 이는 VM이 물리적 SR-IOV 지원 NIC VF에 직접 연결되기 때문입니다.
하드웨어 제한: SR-IOV 기능은 하이퍼바이저가 기능 수준 재설정(FLR)을 사용하여 요청할 때 100ms 이내에 컨트롤러가 장치 기능을 원래 상태로 재설정하는 데 의존합니다.
SR-IOV는 고가용성을 활용하는 환경에서 사용될 수 있습니다. 하지만 SR-IOV는 용량 계획에 고려되지 않습니다. SR-IOV VF가 할당된 VM은 적절한 리소스를 보유한 호스트가 풀에 있는 경우 최선의 노력을 기울여 다시 시작됩니다. 이러한 리소스에는 적절한 네트워크에서 활성화된 SR-IOV와 무료 VF가 포함됩니다.

레거시 드라이버에 대한 SR-IOV VF 구성

일반적으로 NIC가 지원할 수 있는 최대 VF 수는 자동으로 결정됩니다. 레거시 드라이버(예: Intel I350 제품군)를 사용하는 NIC의 경우 제한은 드라이버 모듈 구성 파일 내에서 정의됩니다. 한도를 수동으로 조정해야 할 수도 있습니다. 최대값으로 설정하려면 편집기를 사용하여 파일을 열고 다음으로 시작하는 줄을 변경하세요.

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

예를 들어, igb 드라이버에 대해 최대 VF를 4로 설정하려면 /etc/modprobe.d/igb.conf 를 다음과 같이 편집합니다.

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

노트:

값은 VFs-maxvfs-by-default줄에 있는 값보다 작거나 같아야 합니다.

이 파일의 다른 줄은 변경하지 마세요.

SR-IOV를 활성화하기 전에 변경하세요.

CLI

SR-IOV 네트워크를 생성, 삭제, 표시하고, VM에 SR-IOV VF를 할당하는 방법에 대한 CLI 지침은 SR-IOV 명령 을 참조하세요.

발신 데이터 속도 제어(QoS)

VM이 초당 전송할 수 있는 나가는 데이터의 양을 제한하려면 VM 가상 인터페이스(VIF)에서 선택적 서비스 품질(QoS) 값을 설정합니다. 이 설정을 사용하면 나가는 패킷의 최대 전송 속도를 초당 킬로바이트 로 지정할 수 있습니다.

서비스 품질 값은 VM에서</em> 까지의 전송 속도 *을 제한합니다. 서비스 품질 설정은 VM이 수신할 수 있는 데이터 양을 제한하지 않습니다. 이러한 제한이 필요한 경우 네트워크의 상위(예: 스위치 수준)에서 수신 패킷 속도를 제한하는 것이 좋습니다.</p>

풀에 구성된 네트워킹 스택에 따라 두 곳 중 하나에서 VM 가상 인터페이스(VIF)에 서비스 품질 값을 설정할 수 있습니다. xe CLI나 XenCenter를 사용하여 이 값을 설정할 수 있습니다.

XenCenter 가상 인터페이스의 속성 대화 상자에서 서비스 품질 전송 속도 제한 값을 설정할 수 있습니다.
xe 명령어 다음 섹션의 명령어를 사용하여 CLI를 사용하여 서비스 품질 전송 속도를 설정할 수 있습니다.

QoS에 대한 CLI 명령의 예

CLI를 사용하여 VIF를 초당 최대 100킬로바이트의 전송 속도로 제한하려면 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-->

메모:

kbps 매개변수는 초당 킬로바이트 킬로비트(kbps)가 아닌 초당 * 킬로바이트(kBps)를 나타냅니다.</p> </blockquote>

네트워크 구성 옵션 변경

이 섹션에서는 Citrix Hypervisor 서버의 네트워킹 구성을 변경하는 방법에 대해 설명합니다. 다음이 포함됩니다:

호스트 이름(즉, 도메인 이름 시스템(DNS) 이름) 변경

DNS 서버 추가 또는 삭제

IP 주소 변경

관리 인터페이스로 사용되는 NIC 변경

서버에 새로운 물리적 NIC 추가

네트워크에 목적 추가

ARP 필터링 활성화(스위치 포트 잠금)

호스트 이름

시스템 호스트 이름(도메인 또는 DNS 이름이라고도 함)은 풀 전체 데이터베이스에 정의되어 있으며 다음과 같이 xe host-set-hostname-live CLI 명령을 사용하여 변경합니다.
  xe host-set-hostname-live host-uuid=host_uuid host-name=host-name

기본 제어 도메인 호스트 이름은 새로운 호스트 이름을 반영하기 위해 동적으로 변경됩니다.

DNS 서버

Citrix Hypervisor 서버의 IP 주소 구성에서 DNS 서버를 추가하거나 삭제하려면 pif-reconfigure-ip 명령을 사용합니다. 예를 들어, 고정 IP가 있는 PIF의 경우:
  xe pif-reconfigure-ip uuid=pif_uuid mode=static DNS=new_dns_ip IP=IP netmask=netmask

독립형 호스트에 대한 IP 주소 구성 변경

xe CLI를 사용하여 네트워크 인터페이스 구성을 변경할 수 있습니다. 기본 네트워크 구성 스크립트를 직접 변경하지 마세요.

PIF의 IP 주소 구성을 변경하려면 pif-reconfigure-ip CLI 명령을 사용합니다. pif-reconfigure-ip 명령의 매개 변수에 대한 자세한 내용은 pif-reconfigure-ip 을 참조하세요. 리소스 풀에서 호스트 IP 주소를 변경하는 방법에 대한 자세한 내용은 다음 섹션을 참조하세요.

리소스 풀에서 IP 주소 구성 변경

리소스 풀의 Citrix Hypervisor 서버에는 풀 내의 다른 호스트와의 관리 및 통신에 사용되는 단일 관리 IP 주소가 있습니다. 호스트 관리 인터페이스의 IP 주소를 변경하는 데 필요한 단계는 마스터 호스트와 다른 호스트에서 서로 다릅니다.

메모:

서버의 IP 주소와 다른 네트워크 매개변수를 변경할 때는 주의해야 합니다. 네트워크 토폴로지와 변경 사항에 따라 네트워크 스토리지와의 연결이 끊어질 수 있습니다. 이런 경우 XenCenter에서 저장소 복구 기능을 사용하거나 pbd-plug CLI 명령을 사용하여 저장소를 다시 연결해야 합니다. 이러한 이유로 IP 구성을 변경하기 전에 서버에서 VM을 다른 곳으로 마이그레이션하는 것이 좋습니다.

pif-reconfigure-ip CLI 명령을 사용하여 IP 주소를 원하는 대로 설정합니다. pif-reconfigure-ip 명령의 매개 변수에 대한 자세한 내용은 pif-reconfigure-ip 을 참조하세요. :
  xe pif-reconfigure-ip uuid=pif_uuid mode=DHCP

host-list CLI 명령을 사용하여 풀에 있는 다른 모든 Citrix Hypervisor 서버가 표시되는지 확인하여 멤버 호스트가 마스터 호스트에 성공적으로 다시 연결되었는지 확인합니다.
  xe host-list

마스터 Citrix Hypervisor 서버의 IP 주소를 변경하려면 추가 단계가 필요합니다. 이는 각 풀 멤버가 통신을 위해 풀 마스터의 광고된 IP 주소를 사용하기 때문입니다. 풀 멤버는 IP 주소가 변경될 때 마스터에 연락하는 방법을 모릅니다.

가능하다면 풀 마스터의 수명 동안 변경될 가능성이 없는 전용 IP 주소를 사용하세요.

pif-reconfigure-ip CLI 명령을 사용하여 원하는 대로 IP 주소를 설정하세요.
  xe pif-reconfigure-ip uuid=pif_uuid mode=DHCP

풀 마스터의 IP 주소가 변경되면 모든 멤버 호스트는 마스터 호스트에 접속하지 못할 경우 비상 모드로 전환됩니다.

풀 마스터에서 pool-recover-slaves 명령을 사용하여 마스터가 각 풀 멤버에게 연락하여 새 마스터 IP 주소를 알리도록 합니다.
  xe pool-recover-slaves

관리 인터페이스

호스트에 Citrix Hypervisor를 설치하면 NIC 중 하나가 관리 인터페이스로 지정됩니다. 이 NIC는 Citrix Hypervisor 관리 트래픽에 사용됩니다. 관리 인터페이스는 XenCenter 및 호스트에 대한 기타 관리 API 연결(예: Citrix Virtual Apps and Desktops)과 호스트 간 통신에 사용됩니다.

pif-list 명령을 사용하여 관리 인터페이스로 사용될 NIC에 해당하는 PIF를 확인합니다. 각 PIF의 UUID가 반환됩니다.
  xe pif-list

pif-param-list 명령을 사용하여 관리 인터페이스에 사용되는 PIF의 IP 주소 구성을 확인합니다. 필요한 경우 pif-reconfigure-ip 명령을 사용하여 사용할 PIF에 대한 IP 주소를 구성합니다.
  xe pif-param-list uuid=pif_uuid

host-management-reconfigure CLI 명령을 사용하여 관리 인터페이스에 사용되는 PIF를 변경합니다. 이 호스트가 리소스 풀의 일부인 경우, 이 명령은 멤버 호스트 콘솔에서 실행해야 합니다.:
  xe host-management-reconfigure pif-uuid=pif_uuid

network-list 명령을 사용하여 풀에 있는 모든 호스트의 관리 인터페이스로 사용될 NIC에 해당하는 PIF를 확인합니다. 풀 전체 네트워크의 UUID가 반환됩니다.
  xe network-list

network-param-list 명령을 사용하여 풀에 있는 모든 호스트의 PIF UUID를 가져옵니다. pif-param-list 명령을 사용하여 관리 인터페이스의 PIF에 대한 IP 주소 구성을 확인합니다. 필요한 경우 pif-reconfigure-ip 명령을 사용하여 사용할 PIF에 대한 IP 주소를 구성합니다.
  xe pif-param-list uuid=pif_uuid

네트워크 목록에 나열된 관리 인터페이스에 사용되는 PIF를 변경하려면 pool-management-reconfigure CLI 명령을 사용합니다.
  xe pool-management-reconfigure network-uuid=network_uuid

포트 80 사용 제한

Citrix Hypervisor와 통신하려면 포트 443을 통한 HTTPS 또는 포트 80을 통한 HTTP를 사용할 수 있습니다. 보안상의 이유로 관리 인터페이스에서 TCP 포트 80을 닫을 수 있습니다. 기본적으로 포트 80은 여전히 열려 있습니다. 이 포트를 닫으면 관리 API를 사용하는 모든 외부 클라이언트는 Citrix Hypervisor에 연결하기 위해 포트 443을 통해 HTTPS를 사용해야 합니다. 그러나 포트 80을 닫기 전에 모든 API 클라이언트(특히 Citrix Virtual Apps 및 Desktops)가 포트 443을 통해 HTTPS를 사용할 수 있는지 확인하십시오.

포트 80을 닫으려면 XenCenter 설명서의 https-only xe CLI 명령 또는 풀 속성 변경 을 참조하세요.

관리 액세스 비활성화

관리 콘솔에 대한 원격 액세스를 완전히 비활성화하려면 host-management-disable CLI 명령을 사용합니다.

경고:

관리 인터페이스가 비활성화된 경우 관리 작업을 수행하려면 물리적 호스트 콘솔에 로그인해야 합니다. 관리 인터페이스가 비활성화되면 XenCenter와 같은 외부 인터페이스가 작동하지 않습니다.

새로운 물리적 NIC 추가
Citrix Hypervisor 서버에 평소와 같은 방식으로 새로운 물리적 NIC를 설치합니다.

Citrix Hypervisor 서버를 다시 시작합니다.
다음 명령을 사용하여 해당 Citrix Hypervisor 서버의 모든 물리적 NIC를 나열합니다.
   xe pif-list host-uuid=<host_uuid>
추가 NIC가 보이지 않으면 다음 명령을 사용하여 새로운 물리적 인터페이스를 검색합니다.
   xe pif-scan host-uuid=<host_uuid>
이 명령은 새 NIC에 대한 새 PIF 객체를 만듭니다.
Citrix Hypervisor 서버의 물리적 NIC를 다시 나열하여 새 NIC가 표시되는지 확인합니다.
   xe pif-list host-uuid=<host_uuid>
새로운 PIF는 처음에는 연결되지 않음(현재 연결됨( RO): false)으로 나열됩니다. 해당 명령을 사용하려면 다음 명령을 사용하세요.
   xe pif-plug uuid=<uuid_of_pif>
또는 XenCenter를 사용하여 새로운 NIC를 다시 검색할 수 있습니다. 자세한 내용은 XenCenter 설명서의 NIC 구성 을 참조하세요.

물리적 NIC 제거

NIC를 제거하기 전에 해당 PIF의 UUID를 알고 있는지 확인하세요. 평소와 같은 방법으로 Citrix Hypervisor 서버에서 물리적 NIC를 제거합니다. 서버를 다시 시작한 후 xe CLI 명령 pif-forget uuid=<UUID> 을 실행하여 PIF 객체를 삭제합니다.

네트워크에 목적을 추가하세요

네트워크 목적은 네트워크에 추가 기능을 추가하는 데 사용될 수 있습니다. 예를 들어, 네트워크를 사용하여 NBD 연결을 만드는 기능이 있습니다.

네트워크 목적을 추가하려면xe network-param-add 명령을 사용하세요.
  xe network-param-add param-name=purpose param-key=purpose uuid=network-uuid

네트워크 목적을 삭제하려면xe network-param-remove 명령을 사용하세요.
  xe network-param-remove param-name=purpose param-key=purpose uuid=network-uuid

현재 네트워크 목적으로 사용할 수 있는 값은 nbd 및 insecure_nbd입니다. 자세한 내용은 Citrix Hypervisor 변경된 블록 추적 가이드를 참조하세요.

스위치 포트 잠금 사용

Citrix Hypervisor 스위치 포트 잠금 기능을 사용하면 알 수 없거나 신뢰할 수 없거나 잠재적으로 적대적인 VM에서 전송된 트래픽을 제어할 수 있으며 해당 VM이 할당되지 않은 MAC 또는 IP 주소를 사용하는 척하는 기능을 제한할 수 있습니다. 포트 잠금 명령을 사용하면 기본적으로 네트워크의 모든 트래픽을 차단하거나 개별 VM이 트래픽을 보낼 수 있는 특정 IP 주소를 정의할 수 있습니다.

스위치 포트 잠금을 사용하면 모든 테넌트 또는 게스트가 동일한 레이어 2 네트워크를 사용할 수 있으므로 네트워크 구성이 간소화됩니다.

포트 잠금 명령의 가장 중요한 기능 중 하나는 신뢰할 수 없는 게스트가 보내는 트래픽을 제한할 수 있다는 것입니다. 이는 게스트가 실제로 가지고 있지 않은 MAC 주소나 IP 주소를 가지고 있는 척하는 기능을 제한합니다. 특히, 이러한 명령을 사용하면 게스트가 다음을 수행하지 못하도록 할 수 있습니다.

Citrix Hypervisor 관리자가 사용할 수 있도록 지정한 것 외의 IP 또는 MAC 주소를 클레임합니다.

다른 VM의 트래픽을 가로채거나, 스푸핑하거나, 방해합니다.

요구 사항

Citrix Hypervisor 스위치 포트 잠금 기능은 Linux 브리지와 vSwitch 네트워킹 스택에서 지원됩니다.

사용자 환경에서 역할 기반 액세스 제어(RBAC)를 활성화하는 경우 스위치 포트 잠금을 구성하는 사용자는 최소한 풀 운영자 또는 풀 관리자 역할이 있는 계정으로 로그인해야 합니다. 사용자 환경에서 RBAC가 활성화되어 있지 않으면 사용자는 풀 마스터의 루트 계정으로 로그인해야 합니다.

스위치 포트 잠금 명령을 실행하면 네트워크는 온라인 또는 오프라인이 될 수 있습니다.

Windows 게스트에서 연결이 끊긴 네트워크 아이콘은 XenServer VM 도구가 게스트에 설치된 경우에만 나타납니다.

노트

스위치 포트 잠금 구성이 없으면 VIF가 “network_default”로 설정되고 네트워크가 “잠금 해제”로 설정됩니다.

환경에서 타사 컨트롤러를 사용 중인 경우 스위치 포트 잠금 구성이 지원되지 않습니다.

스위치 포트 잠금은 클라우드 테넌트가 다음을 수행하지 못하도록 방지하지 않습니다.

다른 테넌트/사용자에 대해 IP 수준 공격을 수행합니다. 그러나 스위치 포트 잠금은 해당 공격자가 다음 수단을 사용하여 공격을 시도하고 스위치 포트 잠금이 구성된 경우 IP 수준 공격을 수행하는 것을 방지합니다. a) 클라우드의 다른 테넌트 또는 사용자를 가장하거나 b) 다른 사용자를 대상으로 하는 트래픽을 가로채는 경우입니다.

네트워크 리소스가 고갈됩니다.

일반적인 스위치 플러딩 동작(브로드캐스트 MAC 주소 또는 알 수 없는 대상 MAC 주소)을 통해 다른 가상 머신을 대상으로 하는 일부 트래픽을 수신합니다.

마찬가지로, 스위치 포트 잠금은 VM이 트래픽을 보낼 수 있는 위치를 제한하지 않습니다.

구현 노트

명령줄이나 Citrix Hypervisor API를 사용하여 스위치 포트 잠금 기능을 구현할 수 있습니다. 그러나 자동화가 주요 관심사인 대규모 환경에서 가장 일반적인 구현 방법은 API를 사용하는 것일 수 있습니다.

예시

이 섹션에서는 스위치 포트 잠금이 특정 유형의 공격을 방지하는 방법에 대한 예를 제공합니다. 이러한 예에서 VM-c는 적대적인 테넌트(테넌트 C)가 임대하여 공격에 사용하는 가상 머신입니다. VM-a 및 VM-b는 공격하지 않는 테넌트가 임대한 가상 머신입니다.

예 1: 스위치 포트 잠금이 ARP 스푸핑 방지를 방지하는 방법:

ARP 스푸핑은 공격자가 자신의 MAC 주소를 다른 노드의 IP 주소와 연관시키려는 시도를 나타내는 데 사용됩니다. ARP 스푸핑은 노드의 트래픽이 대신 공격자에게 전송될 가능성이 있습니다. 이러한 목표를 달성하기 위해 공격자는 가짜(스푸핑된) ARP 메시지를 이더넷 LAN으로 보냅니다.

시나리오:

가상 머신 A(VM-a)는 VM-a에서 가상 머신 B(VM-b)로 IP 트래픽을 보내려고 하며, 이를 위해 VM-b의 IP 주소로 주소를 지정합니다. 가상 머신 C의 소유자는 ARP 스푸핑을 사용하여 자신의 VM인 VM-c가 실제로는 VM-b인 것처럼 가장하려고 합니다.

VM-c는 VM-a에 ARP 응답의 추측 스트림을 보냅니다. ARP 응답은 응답의 MAC 주소(c_MAC)가 IP 주소 b_IP와 연관되어 있다고 주장합니다.

결과: 관리자가 스위치 포트 잠금을 활성화했기 때문에 스위치 포트 잠금을 활성화하면 사칭이 방지되어 이러한 패킷은 모두 삭제됩니다.

VM-b는 VM-a에 ARP 응답을 보내면서 응답의 MAC 주소(b_MAC)가 IP 주소 b_IP와 연관되어 있다고 주장합니다.

결과: VM-a는 VM-b의 ARP 응답을 수신합니다.

예 2: IP 스푸핑 방지:

IP 주소 스푸핑은 위조된 소스 IP 주소로 인터넷 프로토콜(IP) 패킷을 생성하여 패킷의 신원을 숨기는 프로세스입니다.

시나리오:

세입자 C는 원격 시스템에서 호스트인 Host-C를 사용하여 신원을 위장하여 서비스 거부 공격을 시도하고 있습니다.

시도 1:

테넌트 C는 호스트 C의 IP 주소와 MAC 주소를 VM-a의 IP 및 MAC 주소(a_IP 및 a_MAC)로 설정합니다. 테넌트 C가 호스트 C에게 원격 시스템으로 IP 트래픽을 보내라고 지시합니다.

결과: 호스트 C 패킷이 삭제됩니다. 이는 관리자가 스위치 포트 잠금을 활성화했기 때문입니다. 스위치 포트 잠금을 활성화하면 사칭이 방지되므로 호스트 C 패킷은 삭제됩니다.

시도 2:

테넌트 C는 호스트 C의 IP 주소를 VM-a의 IP 주소(a_IP)로 설정하고 원래 c_MAC을 유지합니다.

테넌트 C가 호스트 C에게 원격 시스템으로 IP 트래픽을 보내라고 지시합니다.

결과: 호스트 C 패킷이 삭제됩니다. 이는 관리자가 사칭을 방지하는 스위치 포트 잠금 기능을 활성화했기 때문입니다.

예시 3: 웹 호스팅:

대본:

앨리스는 인프라 관리자입니다.

세입자 중 한 명인 세입자 B는 VM-b에서 여러 개의 웹사이트를 호스팅하고 있습니다. 각 웹사이트에는 동일한 가상 네트워크 인터페이스(VIF)에 호스팅된 고유한 IP 주소가 필요합니다.

앨리스는 호스트 B의 VIF를 재구성하여 단일 MAC과 여러 IP 주소에 잠그도록 합니다.

스위치 포트 잠금 작동 방식

스위치 포트 잠금 기능을 사용하면 패킷 필터링을 두 수준 중 하나 이상에서 제어할 수 있습니다.

VIF 레벨. VIF에서 구성하는 설정에 따라 패킷이 필터링되는 방식이 결정됩니다. VIF를 설정하여 VM이 트래픽을 전송하지 못하도록 할 수도 있고, VIF가 할당된 IP 주소를 사용해서만 트래픽을 전송하도록 제한할 수도 있으며, VM이 VIF에 연결된 네트워크의 모든 IP 주소로 트래픽을 전송하도록 허용할 수도 있습니다.

네트워크 레벨. Citrix Hypervisor 네트워크는 패킷이 필터링되는 방식을 결정합니다. VIF 잠금 모드가 network_default로 설정된 경우, 어떤 트래픽을 허용할지 결정하기 위해 네트워크 수준 잠금 설정을 참조합니다.

어떤 네트워킹 스택을 사용하든 이 기능은 동일한 방식으로 작동합니다. 그러나 다음 섹션에서 더 자세히 설명하겠지만 Linux 브리지는 IPv6에서 스위치 포트 잠금을 완벽하게 지원하지 않습니다.

VIF 잠금 모드 상태

Citrix Hypervisor 스위치 포트 잠금 기능은 VIF를 4가지 상태로 구성할 수 있는 잠금 모드를 제공합니다. 이러한 상태는 VIF가 실행 중인 가상 머신에 플러그인된 경우에만 적용됩니다.

네트워크_기본값. VIF의 상태가 network_default로 설정되면 Citrix Hypervisor는 네트워크의 default-locking-mode 매개변수를 사용하여 VIF를 통과하는 패킷을 필터링할지 여부와 필터링 방법을 결정합니다. 동작은 연결된 네트워크에 네트워크 기본 잠금 모드 매개변수가 비활성화 또는 잠금 해제로 설정되어 있는지에 따라 다릅니다.

-기본 잠금 모드=비활성화됨, Citrix Hypervisor는 필터링 규칙을 적용하여 VIF가 모든 트래픽을 삭제하도록 합니다.

-기본 잠금 모드= 잠금 해제, Citrix Hypervisor는 VIF와 관련된 모든 필터링 규칙을 제거합니다. 기본적으로 기본 잠금 모드 매개변수는 잠금 해제로 설정됩니다.

기본 잠금 모드 매개변수에 대한 자세한 내용은 네트워크 명령을 참조하세요.

네트워크의 기본 잠금 모드는 잠금 상태가 network_default가 아닌 연결된 VIF에는 영향을 미치지 않습니다.

메모:

활성 VIF가 연결된 네트워크의 기본 잠금 모드 를 변경할 수 없습니다.

잠김. Citrix Hypervisor는 필터링 규칙을 적용하여 지정된 MAC 및 IP 주소에서 전송되거나 해당 주소에서 나가는 트래픽만 VIF를 통해 전송되도록 허용합니다. 이 모드에서 IP 주소가 지정되지 않으면 VM은 해당 네트워크의 VIF를 통해 트래픽을 전송할 수 없습니다.

VIF가 트래픽을 허용하는 IP 주소를 지정하려면 ipv4_allowed 또는 ipv6_allowed 매개변수를 사용하여 IPv4 또는 IPv6 IP 주소를 사용합니다. 하지만 Linux 브리지를 구성한 경우 IPv6 주소를 입력하지 마세요.

Citrix Hypervisor를 사용하면 Linux 브리지가 활성화되어 있을 때 IPv6 주소를 입력할 수 있습니다. 그러나 Citrix Hypervisor는 입력된 IPv6 주소를 기준으로 필터링할 수 없습니다. 그 이유는 Linux 브리지에 NDP(Neighbor Discovery Protocol) 패킷을 필터링하는 모듈이 없기 때문입니다. 따라서 완벽한 보호를 구현할 수 없으며 게스트는 NDP 패킷을 위조하여 다른 게스트로 가장할 수 있습니다. 결과적으로 IPv6 주소를 하나만 지정하더라도 Citrix Hypervisor는 모든 IPv6 트래픽을 VIF를 통과하도록 합니다. IPv6 주소를 지정하지 않으면 Citrix Hypervisor는 어떠한 IPv6 트래픽도 VIF로 통과시키지 않습니다.

잠금 해제됨. 모든 네트워크 트래픽은 VIF를 통과할 수 있습니다. 즉, VIF에서 나가거나 들어오는 모든 트래픽에는 필터가 적용되지 않습니다.

비활성화. VIF를 통과하는 교통은 허용되지 않습니다. (즉, Citrix Hypervisor는 VIF가 모든 트래픽을 삭제하도록 필터링 규칙을 적용합니다.)

스위치 포트 잠금 구성

이 섹션에서는 세 가지 다른 절차를 제공합니다.

VIF가 특정 IP 주소를 사용하도록 제한

기존 제한 목록에 IP 주소를 추가합니다. 예를 들어, VM이 실행 중이고 네트워크에 연결되어 있을 때 VIF에 IP 주소를 추가합니다(예: 네트워크를 일시적으로 오프라인으로 전환하는 경우).

기존 제한 목록에서 IP 주소 제거

VIF 잠금 모드가 locked로 설정된 경우 ipv4-allowed 또는 ipv6-allowed 매개변수에 지정된 주소만 사용할 수 있습니다.

비교적 드문 경우지만 VIF에 두 개 이상의 IP 주소가 있을 수 있으므로 VIF에 여러 개의 IP 주소를 지정할 수 있습니다.

VIF를 연결하기 전이나 후에(또는 VM을 시작하기 전이나 후에) 이러한 절차를 수행할 수 있습니다.

아직 잠금 모드를 사용하지 않는 경우 다음 명령을 실행하여 기본 잠금 모드를 잠금 모드로 변경합니다.
  xe vif-param-set uuid=vif-uuid locking-mode=locked

vif-uuid 는 트래픽을 보낼 수 있도록 허용하려는 VIF의 UUID를 나타냅니다. UUID를 얻으려면 호스트에서 xe vif-list 명령을 실행하세요. vm-uuid 정보가 나타나는 가상 머신을 나타냅니다. 장치 ID는 VIF의 장치 번호를 나타냅니다.

vif-param-set 명령을 실행하여 가상 머신이 트래픽을 보낼 수 있는 IP 주소를 지정합니다. 다음 중 하나 이상을 수행하세요.
하나 이상의 IPv4 IP 주소 대상을 지정합니다. 예를 들어:
       xe vif-param-set uuid=vif-uuid ipv4-allowed=comma separated list of ipv4-addresses
 
하나 이상의 IPv6 IP 주소 대상을 지정합니다. 예를 들어:
       xe vif-param-set uuid=vif-uuid ipv6-allowed=comma separated list of ipv6-addresses
 
앞의 예와 같이 쉼표로 구분하여 여러 IP 주소를 지정할 수 있습니다.

VIF가 특정 IP 주소를 사용하도록 제한하는 절차를 수행한 후에는 VIF가 사용할 수 있는 하나 이상의 IP 주소를 추가할 수 있습니다.

vif-param-add 명령을 실행하여 기존 목록에 IP 주소를 추가합니다. 다음 중 하나 이상을 수행하세요.
IPv4 IP 주소를 지정하세요. 예를 들어:
       xe vif-param-add uuid=vif-uuid ipv4-allowed=comma separated list of ipv4-addresses
 
IPv6 IP 주소를 지정하세요. 예를 들어:
       xe vif-param-add uuid=vif-uuid ipv6-allowed=comma separated list of ipv6-addresses
 
VIF가 두 개 이상의 IP 주소를 사용하도록 제한하는 경우 해당 IP 주소 중 하나를 목록에서 삭제할 수 있습니다.

기존 목록에서 IP 주소를 삭제하려면 vif-param-remove 명령을 실행하세요. 다음 중 하나 이상을 수행하세요.
삭제할 IPv4 IP 주소를 지정하세요. 예를 들어:
       xe vif-param-remove uuid=vif-uuid ipv4-allowed=comma separated list of ipv4-addresses
 
삭제할 IPv6 IP 주소를 지정하세요. 예를 들어:
       xe vif-param-remove uuid=vif-uuid ipv6-allowed=comma separated list of ipv6-addresses
 
가상 머신이 특정 네트워크에서 트래픽을 보내거나 받는 것을 방지합니다

다음 절차는 가상 머신이 특정 VIF를 통해 통신하는 것을 방지합니다. VIF가 특정 Citrix Hypervisor 네트워크에 연결되면 이 절차를 사용하여 가상 머신이 특정 네트워크에서 트래픽을 보내거나 받는 것을 방지할 수 있습니다. 이렇게 하면 전체 네트워크를 비활성화하는 것보다 더욱 세부적인 수준의 제어가 가능합니다.

CLI 명령을 사용하는 경우 VIF의 잠금 모드를 설정하기 위해 VIF의 플러그를 뽑을 필요가 없습니다. 이 명령은 VIF가 실행되는 동안 필터링 규칙을 변경합니다. 이 경우 네트워크 연결은 여전히 있는 것처럼 보이지만 VIF는 VM이 보내려고 시도하는 모든 패킷을 삭제합니다.

팁:

VIF의 UUID를 찾으려면 호스트에서 xe vif-list 명령을 실행하세요. 장치 ID는 VIF의 장치 번호를 나타냅니다.

VIF가 트래픽을 수신하지 못하도록 하려면 VM이 트래픽을 수신하지 못하도록 하려는 네트워크에 연결된 VIF를 비활성화합니다.
  xe vif-param-set uuid=vif-uuid locking-mode=disabled

XenCenter에서 VM의 네트워킹 탭에서 가상 네트워크 인터페이스를 선택하고 비활성화를 클릭하여 VIF를 비활성화할 수도 있습니다.

IP 주소에 대한 VIF 제한 제거

기본(원래) 잠금 모드 상태로 돌아가려면 다음 절차를 따르세요. 기본적으로 VIF를 생성하면 Citrix Hypervisor가 특정 IP 주소에만 국한되지 않도록 구성합니다.

VIF를 잠금 해제 상태로 되돌리려면 VIF 기본 잠금 모드를 잠금 해제로 변경합니다. 아직 해당 모드를 사용하지 않는 경우 다음 명령을 실행하세요.
  xe vif-param-set uuid=vif_uuid locking-mode=unlocked

클라우드에서 VIF 잠금 모드 구성을 간소화합니다

각 VIF에 대해 VIF 잠금 모드 명령을 실행하는 대신, 모든 VIF가 기본적으로 비활성화되도록 할 수 있습니다. 그렇게 하려면 네트워크 수준에서 패킷 필터링을 변경해야 합니다. 패킷 필터링을 변경하면 Citrix Hypervisor 네트워크가 이전 섹션 스위치 포트 잠금 작동 방식에서 설명한 대로 패킷 필터링 방식을 결정합니다.

구체적으로, 네트워크의 기본 잠금 모드 설정은 기본 설정을 가진 새 VIF가 어떻게 동작하는지 결정합니다. VIF의 잠금 모드 가 기본로 설정될 때마다 VIF는 네트워크 잠금 모드(기본 잠금 모드)를 참조하여 VIF를 통과하는 패킷을 필터링할지 여부와 필터링 방법을 결정합니다.

잠금 해제됨. 네트워크 기본 잠금 모드 매개변수가 잠금 해제로 설정되면 Citrix Hypervisor는 VM이 VIF가 연결된 네트워크의 모든 IP 주소로 트래픽을 보낼 수 있도록 합니다.

비활성화. 기본 잠금 모드 매개변수가 비활성화됨로 설정되면 Citrix Hypervisor는 필터링 규칙을 적용하여 VIF가 모든 트래픽을 삭제합니다.

기본적으로 XenCenter에서 생성하고 CLI를 사용하는 모든 네트워크의 기본 잠금 모드 는 잠금 해제로 설정됩니다.

VIF 잠금 모드를 기본값(network_default)으로 설정하면 특정 네트워크에 연결되는 모든 새로 생성된 VIF에 대한 기본 구성(네트워크 수준)을 만들 수 있습니다.

이 그림은 VIF의 잠금 모드 가 기본 설정(network_default)으로 설정된 경우 VIF가 네트워크 기본 잠금 모드 를 사용하여 동작을 결정하는 방식을 보여줍니다.

예를 들어, 기본적으로 VIF는 잠금 모드 가 network_default로 설정되어 생성됩니다. 네트워크의 기본 잠금 모드=비활성화를 설정하면 잠금 모드를 구성하지 않은 모든 새 VIF가 비활성화됩니다. VIF는 (a) 개별 VIF의 잠금 모드 매개변수를 변경하거나 (b) VIF의 잠금 모드 를 명시적으로 ``잠금 해제’‘로 설정할 때까지 비활성화 상태로 유지됩니다. 이 기능은 특정 VM을 충분히 신뢰하여 해당 트래픽을 전혀 필터링하지 않으려는 경우에 유용합니다.

네트워크의 기본 잠금 모드 설정을 변경하려면:

네트워크를 생성한 후 다음 명령을 실행하여 기본 잠금 모드를 변경합니다.
  xe network-param-set uuid=network-uuid default-locking-mode=[unlocked|disabled]

메모:

네트워크의 UUID를 얻으려면 xe network-list 명령을 실행하세요. 이 명령은 명령을 실행한 호스트의 모든 네트워크에 대한 UUID를 표시합니다.

네트워크의 기본 잠금 모드 설정을 확인하려면:

다음 명령 중 하나를 실행하세요.
  xe network-param-get uuid=network-uuid param-name=default-locking-mode

또는
  xe network-list uuid=network-uuid params=default-locking-mode

VIF 트래픽 필터링을 위한 네트워크 설정 사용

다음 절차에서는 가상 머신의 VIF가 네트워크 자체의 Citrix Hypervisor 네트워크 기본 잠금 모드 설정을 사용하여 트래픽을 필터링하는 방법을 결정하도록 지시합니다.
아직 해당 모드를 사용하지 않는 경우 다음 명령을 실행하여 VIF 잠금 상태를 network_default로 변경하세요.
      xe vif-param-set uuid=vif_uuid locking-mode=network_default

아직 해당 모드를 사용하지 않는 경우 다음 명령을 실행하여 기본 잠금 모드를 unlocked로 변경하세요.
      xe network-param-set uuid=network-uuid default-locking-mode=unlocked

이 콘텐츠의 공식 버전은 영어로 작성되었습니다. 일부 Cloud Software Group 설명서 콘텐츠는 사용자의 편의를 위해 기계 번역되었습니다. Cloud Software Group는 기계 번역 콘텐츠를 제어할 수 없으며, 오류, 부정확성 또는 부적절한 언어가 포함될 수 있습니다. 영어 원본에서 다른 언어로 번역된 모든 콘텐츠의 정확성, 신뢰성, 적합성 또는 적절성에 대한 모든 종류의 명시적 또는 묵시적 보증이나 Cloud Software Group 제품 또는 서비스가 기계 번역된 콘텐츠를 준수한다는 보증은 하지 않으며, 해당하는 최종 사용자 사용권 계약, 이용 약관 또는 제품 또는 서비스가 준수해야 하는 Cloud Software Group와의 모든 계약에 제공된 모든 보증은 기계 번역된 범위까지 적용되지 않습니다. Cloud Software Group는 기계 번역된 콘텐츠의 사용으로 인해 발생할 수 있는 손상이나 문제에 대해 책임을 지지 않습니다.

도움이 되었나요?

네트워킹 관리

February 3, 2025

제공::

February 3, 2025

제공::

도움이 되었나요?