Citrix Hypervisor

호스트 및 리소스 풀

January 31, 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 라이센스 개요.

이 섹션에서는 xe CLI(명령줄 인터페이스)를 사용하여 일련의 예제를 통해 리소스 풀을 생성하는 방법에 대해 설명합니다. 간단한 NFS 기반 공유 스토리지 구성이 제공되고 몇 가지 간단한 VM 관리 예제가 논의됩니다. 또한 물리적 노드 장애를 처리하기 위한 절차도 포함되어 있습니다.

Citrix Hypervisor 서버 및 리소스 풀 개요

A 리소스 풀(resource pool) 가상 머신을 호스팅할 수 있는 단일 관리 엔터티에 함께 바인딩된 여러 Citrix Hypervisor 서버 설치로 구성됩니다. 공유 스토리지와 결합된 경우 리소스 풀을 사용하면 다음에서 VM을 시작할 수 있습니다. 어떤 Citrix Hypervisor 서버에 충분한 메모리가 있습니다. 그런 다음 다운타임을 최소화하면서 실행 중인 동안 Citrix Hypervisor 서버 간에 VM을 동적으로 이동할 수 있습니다 (실시간 마이그레이션). 개별 Citrix Hypervisor 서버에 하드웨어 오류가 발생하는 경우 관리자는 동일한 리소스 풀의 다른 Citrix Hypervisor 서버에서 실패한 VM을 다시 시작할 수 있습니다. 리소스 풀에서 고가용성을 사용하도록 설정하면 호스트에 장애가 발생하면 VM이 자동으로 다른 호스트로 이동합니다. 리소스 풀당 최대 64개의 호스트가 지원되지만 이 제한이 적용되지는 않습니다.

풀에는 항상 하나 이상의 물리적 노드가 있으며, 이 노드는 주. 마스터 노드만 관리 인터페이스(XenCenter 및 Citrix Hypervisor 명령줄 인터페이스, xe CLI라고 함)를 노출합니다. 마스터는 필요에 따라 개별 멤버에게 명령을 전달합니다.

메모:

풀 마스터에 장애가 발생하면 고가용성이 활성화된 경우에만 마스터 재선택이 발생합니다.

자원 그룹을 만들기 위한 요구 사항

리소스 풀은 하나 이상의 Citrix Hypervisor 서버로 구성된 동종(또는 제한이 있는 이기종) 집계로, 최대 64개입니다. 동질의 정의는 다음과 같습니다.

풀에 가입하는 서버의 CPU는 공급업체, 모델 및 기능 측면에서 이미 풀에 있는 서버의 CPU와 동일합니다.
풀에 가입하는 서버는 이미 풀에 있는 서버와 동일한 패치 수준에서 동일한 버전의 Citrix Hypervisor 소프트웨어를 실행하고 있습니다.

소프트웨어는 서버를 풀에 조인할 때 추가 제약 조건을 적용합니다. 특히 Citrix Hypervisor는 풀에 가입하는 서버에 대해 다음 조건이 충족되는지 확인합니다.

서버가 기존 리소스 풀의 멤버가 아닙니다.
서버에 공유 스토리지가 구성되어 있지 않습니다.
서버가 실행 중이거나 일시 중단된 VM을 호스팅하지 않습니다.
서버의 VM에서 진행 중인 활성 작업(예: VM 종료)이 없습니다.
서버의 시계는 풀 마스터와 동일한 시간으로 동기화됩니다(예: NTP 사용).
서버의 관리 인터페이스는 결합되어 있지 않습니다. 서버가 풀에 성공적으로 가입할 때 관리 인터페이스를 구성할 수 있습니다.
관리 IP 주소는 서버 자체에서 구성하거나 DHCP 서버에서 적절한 구성을 사용하여 고정됩니다.

리소스 풀의 Citrix Hypervisor 서버에는 다양한 수의 물리적 네트워크 인터페이스가 포함될 수 있으며 다양한 크기의 로컬 스토리지 저장소가 있을 수 있습니다. 실제로 정확히 동일한 CPU를 가진 여러 서버를 확보하는 것은 종종 어렵기 때문에 약간의 변형이 허용됩니다. 다양한 CPU를 가진 호스트를 동일한 풀의 일부로 사용할 수 있는 경우 다음을 전달하여 풀 조인 작업을 강제 실행할 수 있습니다. --포스 매개 변수.

풀의 모든 호스트는 동일한 사이트에 있어야 하며 대기 시간이 짧은 네트워크로 연결되어야 합니다.

메모:

풀에 공유 NFS 또는 iSCSI 스토리지를 제공하는 서버에는 고정 IP 주소가 있어야 합니다.

풀에는 VM을 실행할 Citrix Hypervisor 서버를 선택하고 Citrix Hypervisor 서버 간에 VM을 동적으로 이동하기 위한 공유 스토리지 저장소가 포함되어야 합니다. 가능하면 공유 스토리지를 사용할 수 있게 된 후에 풀을 만듭니다. 공유 스토리지를 추가한 후에는 로컬 스토리지에 있는 디스크가 있는 기존 VM을 공유 스토리지로 이동하는 것이 좋습니다. 를 사용할 수 있습니다. xe vm-copy 명령을 실행하거나 XenCenter를 사용하여 VM을 이동합니다.

자원 그룹 만들기

리소스 풀은 XenCenter 또는 CLI를 사용하여 만들 수 있습니다. 새 호스트가 리소스 풀에 가입하면 가입 호스트는 로컬 데이터베이스를 풀 전체 데이터베이스와 동기화하고 풀에서 일부 설정을 상속합니다.

VM, 로컬 및 원격 스토리지 구성이 풀 전체 데이터베이스에 추가됩니다. 이 구성은 호스트가 풀에 가입한 후 리소스를 명시적으로 공유하도록 만들지 않는 한 풀의 가입 호스트에 적용됩니다.
조인 호스트는 풀의 기존 공유 스토리지 저장소를 상속합니다. 새 호스트가 기존 공유 스토리지에 자동으로 액세스할 수 있도록 적절한 PBD 레코드가 생성됩니다.
네트워킹 정보는 조인 호스트에 부분적으로 상속됩니다. 구조 NIC, VLAN 및 결합된 인터페이스의 세부 정보는 모두 상속되지만 정책 정보는 그렇지 않습니다. 다시 구성해야 하는 이 정책 정보에는 다음이 포함됩니다.
- 원래 구성에서 유지되는 관리 NIC의 IP 주소입니다.
- 원래 구성과 동일하게 유지되는 관리 인터페이스의 위치입니다. 예를 들어, 다른 풀 호스트에 결합된 인터페이스에 관리 인터페이스가 있는 경우 가입 후 가입 호스트를 결합 상태로 마이그레이션해야 합니다.
- XenCenter 또는 CLI에서 조인 호스트에 재할당해야 하는 전용 스토리지 NIC 및 그에 따라 트래픽을 라우팅하기 위해 다시 연결된 PBD입니다. 이는 IP 주소가 풀 조인 작업의 일부로 할당되지 않고 스토리지 NIC가 올바르게 구성된 경우에만 작동하기 때문입니다. CLI에서 스토리지 NIC 전용으로 사용하는 방법에 대한 자세한 내용은 을 참조하십시오 네트워킹 관리.

메모:

호스트의 관리 인터페이스가 리소스 풀과 태그가 지정된 VLAN과 동일한 VLAN에 있는 경우에만 새 호스트를 리소스 풀에 가입시킬 수 있습니다.

xe CLI를 사용하여 풀에 호스트 추가

풀에 가입하려는 Citrix Hypervisor 호스트에서 콘솔을 엽니다.
다음 명령을 실행하여 Citrix Hypervisor 호스트를 풀에 가입합니다.
```
  xe pool-join master-address=<address of pool master> master-username=<administrator username> master-password=<password>

```
이 마스터 주소 풀 마스터의 정규화된 도메인 이름으로 설정해야 합니다. 이 암호 풀 마스터를 설치할 때 설정된 관리자 암호여야 합니다.

메모:

호스트를 풀에 가입시키면 가입 호스트의 관리자 비밀번호가 풀 마스터의 관리자 비밀번호와 일치하도록 자동으로 변경됩니다.

Citrix Hypervisor 서버는 기본적으로 명명되지 않은 풀에 속합니다. 첫 번째 리소스 풀을 만들려면 기존의 이름 없는 풀의 이름을 바꿉니다. tab-complete를 사용하여 pool_uuid:

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

다른 유형의 리소스 풀 만들기Create heterogeneous resource pools

Citrix Hypervisor는 서로 다른 호스트 하드웨어를 이기종 리소스 풀이라고 하는 리소스 풀에 조인할 수 있도록 하여 시간이 지남에 따라 배포를 확장하는 것을 간소화합니다. 이기종 리소스 풀은 CPU “마스킹” 또는 “레벨링”을 제공하는 Intel(FlexMigration) 및 AMD(Extended Migration) CPU의 기술을 사용하여 가능합니다. CPU 마스킹 및 레벨링 기능을 사용하면 CPU를 다음과 같이 구성할 수 있습니다. 나타나다 실제와 다른 제조사, 모델 또는 기능을 제공하는 것입니다. 이 기능을 사용하면 서로 다른 CPU를 가진 호스트 풀을 생성할 수 있지만 실시간 마이그레이션을 안전하게 지원할 수 있습니다.

메모:

이기종 풀에 가입하는 Citrix Hypervisor 서버의 CPU는 이미 풀에 있는 호스트의 CPU와 동일한 공급업체 (즉, AMD, Intel) 의 것이어야 합니다. 그러나 서버는 패밀리, 모델 또는 스테핑 번호 수준에서 동일한 유형일 필요는 없습니다.

Citrix Hypervisor는 이기종 풀의 지원을 간소화합니다. 이제 기본 CPU 유형에 관계없이 기존 리소스 풀에 호스트를 추가할 수 있습니다(CPU가 동일한 공급업체 제품군에 속하는 경우). 풀 기능 집합은 매번 동적으로 계산됩니다.

새 호스트가 풀에 참가합니다.
수영장 구성원이 수영장을 떠납니다.
풀 멤버가 재부팅 후 다시 연결됩니다.

풀 기능 집합의 변경은 풀에서 현재 실행 중인 VM에 영향을 주지 않습니다. 실행 중인 VM은 시작될 때 적용된 기능 집합을 계속 사용합니다. 이 기능 집합은 부팅 시 고정되며 마이그레이션, 일시 중단 및 다시 시작 작업 간에 유지됩니다. 성능이 낮은 호스트가 풀에 가입할 때 풀 수준이 떨어지면 실행 중인 VM을 새로 추가된 호스트를 제외한 풀의 모든 호스트로 마이그레이션할 수 있습니다. 풀 내 또는 풀 간에 다른 호스트로 VM을 이동하거나 마이그레이션할 때 Citrix Hypervisor는 VM의 기능 집합을 대상 호스트의 기능 집합과 비교합니다. 기능 집합이 호환되는 것으로 확인되면 VM을 마이그레이션할 수 있습니다. 이렇게 하면 VM이 사용하는 CPU 기능에 관계없이 풀 내에서 그리고 풀 간에 자유롭게 이동할 수 있습니다. Workload Balancing을 사용하여 VM을 마이그레이션할 최적의 대상 호스트를 선택하는 경우 호환되지 않는 기능 집합이 있는 호스트는 대상 호스트로 권장되지 않습니다.

공유 스토리지 추가하기

지원되는 공유 스토리지 유형의 전체 목록은 다음을 참조하십시오. 스토리지 리포지토리 형식. 이 섹션에서는 기존 NFS 서버에서 공유 스토리지(스토리지 저장소로 표시)를 생성하는 방법을 보여줍니다.

CLI를 사용하여 NFS 공유 스토리지를 리소스 풀에 추가하려면

풀의 Citrix Hypervisor 서버에서 콘솔을 엽니다.
다음 명령을 실행하여 server:/path에 스토리지 저장소를 생성합니다.
```
  xe sr-create content-type=user type=nfs name-label="Example SR" shared=true \
      device-config:server=server \
      device-config:serverpath=path

```
장치 구성:서버 은 NFS 서버의 호스트 이름이고 장치 구성:서버 경로 은 NFS 서버의 경로입니다. 만큼 공유 true로 설정하면 공유 스토리지가 풀의 모든 Citrix Hypervisor 서버에 자동으로 연결됩니다. 나중에 가입하는 모든 Citrix Hypervisor 서버도 스토리지에 연결됩니다. 스토리지 저장소의 UUID(Universally Unique Identifier)가 화면에 인쇄됩니다.
다음 명령을 실행하여 풀의 UUID를 찾습니다.
```
  xe pool-list

```
다음 명령을 사용하여 공유 저장소를 풀 전체 기본값으로 설정합니다.
```
  xe pool-param-set uuid=pool_uuid default-SR=sr_uuid

```
공유 스토리지가 풀 전체 기본값으로 설정되었으므로 이후의 모든 VM에는 기본적으로 공유 스토리지에 디스크가 생성됩니다. 다른 유형의 공유 저장소를 만드는 방법에 대한 자세한 내용은 다음을 참조하십시오. 스토리지 리포지토리 형식.

리소스 풀에서 Citrix Hypervisor 서버 제거

메모:

풀에서 Citrix Hypervisor 서버를 제거하기 전에 해당 호스트에서 실행 중인 모든 VM을 종료해야 합니다. 그렇지 않으면 호스트를 제거할 수 없다는 경고가 표시될 수 있습니다.

제거할 때(꺼내기) 호스트를 풀에서 가져오면 시스템이 재부팅되고 다시 초기화되며 새로 설치와 유사한 상태로 유지됩니다. 로컬 디스크에 중요한 데이터가 있는 경우 풀에서 Citrix Hypervisor 서버를 꺼내지 마십시오.

CLI를 사용하여 리소스 풀에서 호스트를 제거하려면

풀의 호스트에서 콘솔을 엽니다.
다음 명령을 실행하여 호스트의 UUID를 찾습니다.
```
  xe host-list

```
풀에서 필요한 호스트를 꺼냅니다.
```
  xe pool-eject host-uuid=host_uuid

```
Citrix Hypervisor 서버가 배출되고 새로 설치된 상태로 유지됩니다.

경고:

하다 안 리소스 풀에서 호스트를 꺼냅니다(로컬 디스크에 저장된 중요한 데이터가 포함되어 있는 경우). 호스트가 풀에서 배출되면 모든 데이터가 지워집니다. 이 데이터를 보존하려면 XenCenter를 사용하여 VM을 풀의 공유 스토리지에 복사하거나 xe vm-copy CLI 명령을 사용합니다.

로컬에 저장된 VM이 포함된 Citrix Hypervisor 서버를 풀에서 꺼내면 VM이 풀 데이터베이스에 표시됩니다. 로컬에 저장된 VM은 다른 Citrix Hypervisor 서버에서도 볼 수 있습니다. VM과 연결된 가상 디스크가 풀의 다른 Citrix Hypervisor 서버에서 볼 수 있는 공유 스토리지를 가리키도록 변경되거나 제거될 때까지 VM이 시작되지 않습니다. 따라서 풀에 가입할 때 모든 로컬 저장소를 공유 저장소로 이동하는 것이 좋습니다. 공유 스토리지로 이동하면 데이터 손실 없이 개별 Citrix Hypervisor 서버를 꺼내거나 물리적으로 실패할 수 있습니다.

메모:

태그가 지정된 VLAN 네트워크에 관리 인터페이스가 있는 풀에서 호스트를 제거하면 시스템이 재부팅되고 해당 관리 인터페이스를 동일한 네트워크에서 사용할 수 있습니다.

유지 관리를 위해 Citrix Hypervisor 서버 풀을 준비합니다

리소스 풀의 일부인 호스트에서 유지 보수 작업을 수행하기 전에 해당 호스트를 사용하지 않도록 설정해야 합니다. 호스트를 사용하지 않도록 설정하면 호스트에서 VM이 시작되지 않습니다. 그런 다음 해당 VM을 풀의 다른 Citrix Hypervisor 서버로 마이그레이션해야 합니다. XenCenter를 사용하여 Citrix Hypervisor 서버를 유지 관리 모드로 전환하여 이 작업을 수행할 수 있습니다. 자세한 내용은 유지 관리 모드에서 실행 XenCenter 설명서에 나와 있습니다.

백업 동기화는 24시간마다 발생합니다. 마스터 호스트를 유지 보수 모드로 전환하면 오프라인 VM에 대한 마지막 24시간 동안의 RRD 업데이트가 손실됩니다.

경고:

업데이트를 설치하기 전에 모든 Citrix Hypervisor 서버를 재부팅한 다음 구성을 확인하는 것이 좋습니다. 일부 구성 변경 사항은 Citrix Hypervisor 서버를 재부팅할 때만 적용되므로 재부팅 시 업데이트 실패의 원인이 될 수 있는 구성 문제가 발견될 수 있습니다.

CLI를 사용하여 유지 보수 작업을 위해 풀의 호스트를 준비하려면

다음 명령을 실행합니다.
```
  xe host-disable uuid=Citrix Hypervisor_host_uuid
  xe host-evacuate uuid=Citrix Hypervisor_host_uuid

```
이 명령은 Citrix Hypervisor 서버를 비활성화한 다음 실행 중인 모든 VM을 풀의 다른 Citrix Hypervisor 서버로 마이그레이션합니다.
원하는 유지 관리 작업을 수행합니다.
유지 관리 작업이 완료되면 Citrix Hypervisor 서버를 활성화합니다.
```
  xe host-enable

```
중지된 VM을 다시 시작하고 일시 중단된 VM을 다시 시작합니다.

자원 그룹 데이터 내보내기Export resource pool data

리소스 데이터 내보내기 옵션을 사용하면 풀에 대한 리소스 데이터 보고서를 생성하고 보고서를 .xls 또는 .csv 파일로 내보낼 수 있습니다. 이 보고서는 서버, 네트워크, 스토리지, 가상 머신, VDI 및 GPU와 같은 풀의 다양한 리소스에 대한 자세한 정보를 제공합니다. 이 기능을 통해 관리자는 CPU, 스토리지 및 네트워크와 같은 다양한 워크로드를 기반으로 리소스를 추적, 계획 및 할당할 수 있습니다.

메모:

리소스 풀 데이터 내보내기는 Citrix Hypervisor 프리미엄 에디션 고객 또는 Citrix Virtual Apps and Desktops 권한 또는 Citrix DaaS 권한을 통해 Citrix Hypervisor에 액세스할 수 있는 사용자가 사용할 수 있습니다.

보고서에 포함된 자원 및 다양한 유형의 자원 데이터 목록은 다음과 같습니다.

서버:

이름
풀 마스터
UUID
주소
CPU 사용량
네트워크(평균/최대 KB)
사용된 메모리
보관
가동
설명

네트워크:

이름
링크 상태
맥
최대 전송 단위(MTU)
VLAN (영어)
유형
위치

VDI:

이름
유형
UUID
크기
보관
설명

보관:

이름
유형
UUID
크기
위치
설명

가상 머신:

이름
전원 상태
실행 중
주소
맥
NIC (닉)
운영 체제
보관
사용된 메모리
CPU 사용량
UUID
가동
템플렛
설명

그래픽 카드:

이름
서버
PCI 버스 경로
UUID
전력 사용량
온도
사용된 메모리
컴퓨터 활용

메모:

GPU에 대한 정보는 Citrix Hypervisor 서버에 연결된 GPU가 있는 경우에만 사용할 수 있습니다.

자원 데이터를 내보내려면

XenCenter Navigation(XenCenter 탐색) 창에서 인프라 을 클릭한 다음 풀을 선택합니다.
을(를) 선택합니다. 풀 menu 다음 자원 데이터 내보내기Export Resource Data.
보고서를 저장할 위치로 이동한 다음 구해내다.

호스트 전원 켜기

원격으로 호스트 전원 켜기

Citrix Hypervisor 서버 전원 켜기 기능을 사용하여 XenCenter에서 또는 CLI를 사용하여 원격으로 서버를 켜고 끌 수 있습니다.

호스트 전원을 활성화하려면 호스트에 다음 전원 제어 솔루션 중 하나가 있어야 합니다.

Wake on LAN 지원 네트워크 카드.
Dell 원격 액세스 카드(DRAC). DRAC에서 Citrix Hypervisor를 사용하려면 Dell 보조 팩을 설치하여 DRAC 지원을 받아야 합니다. DRAC를 지원하려면 원격 액세스 컨트롤러가 있는 서버에 RACADM 명령줄 유틸리티를 설치하고 DRAC 및 해당 인터페이스를 활성화해야 합니다. RACADM은 DRAC 관리 소프트웨어에 포함되는 경우가 많습니다. 자세한 내용은 Dell의 DRAC 설명서를 참조하십시오.
Citrix Hypervisor를 통해 전원을 켜고 끌 수 있는 관리 API를 기반으로 하는 사용자 지정 스크립트입니다. 자세한 내용은 Host Power On 기능에 대한 사용자 정의 스크립트 구성 다음 섹션에서 설명합니다.

호스트 전원 켜기 기능을 사용하려면 다음 두 가지 작업이 필요합니다.

풀의 호스트가 전원 원격 제어를 지원하는지 확인합니다. 예를 들어 Wake on LAN 기능 또는 DRAC 카드가 있거나 사용자 지정 스크립트를 만들었습니다.
CLI 또는 XenCenter를 사용하여 Host Power On(호스트 전원 켜기) 기능을 활성화합니다.

CLI를 사용하여 호스트 전원 켜기 관리

CLI 또는 XenCenter를 사용하여 호스트 전원 켜기 기능을 관리할 수 있습니다. 이 섹션에서는 CLI를 사용하여 관리하는 방법에 대한 정보를 제공합니다.

호스트 전원 켜기는 호스트 수준 (즉, 각 Citrix Hypervisor)에서 사용하도록 설정됩니다.

Host Power On(호스트 전원 켜기)을 활성화한 후 CLI 또는 XenCenter를 사용하여 호스트를 켤 수 있습니다.

CLI를 사용하여 호스트 전원을 켤 수 있도록 설정하려면To enable host power-on by using the CLI

다음 명령을 실행합니다.

  xe host-set-power-on-mode host=<host uuid> \
      power-on-mode=("" , "wake-on-lan", "DRAC","custom") \
      power-on-config=key:value
<!--NeedCopy-->

DRAC의 경우 키는 다음과 같습니다. power_on_ip 비밀 기능을 사용하는 경우 암호를 지정합니다. 자세한 내용은 비밀.

CLI를 사용하여 원격으로 호스트를 켜려면

다음 명령을 실행합니다.

  xe host-power-on host=<host uuid>
<!--NeedCopy-->

Host Power On 기능에 대한 사용자 지정 스크립트 구성

서버의 원격 전원 솔루션이 기본적으로 지원되지 않는 프로토콜 (예: Wake-On-Ring 또는 Intel Active Management Technology) 을 사용하는 경우 사용자 지정 Linux Python 스크립트를 만들어 Citrix Hypervisor 컴퓨터를 원격으로 켤 수 있습니다. 그러나 DRAC 및 Wake on LAN 원격 전원 솔루션에 대한 사용자 지정 스크립트를 만들 수도 있습니다.

이 섹션에서는 Citrix Hypervisor API 호출과 연결된 키/값 쌍을 사용하여 호스트 전원 켜기에 대한 사용자 지정 스크립트를 구성하는 방법에 대한 정보를 제공합니다 host.power_on.

사용자 지정 스크립트를 만들 때 Citrix Hypervisor 서버에서 원격으로 전원을 제어할 때마다 명령줄에서 실행합니다. 또는 XenCenter에서 지정하고 XenCenter UI 기능을 사용하여 상호 작용할 수 있습니다.

Citrix Hypervisor API는 에서 사용할 수 있는 Citrix Hypervisor 관리 API 문서에 설명되어 있습니다. 개발자 문서 웹 사이트.

경고:

에서 기본적으로 제공되는 스크립트를 변경하지 마십시오. /etc/xapi.d/플러그인/ 디렉토리. 이 디렉토리에 새 스크립트를 포함할 수 있지만 설치 후 해당 디렉토리에 포함된 스크립트를 변경해서는 안 됩니다.

키/값 쌍

Host Power On을 사용하려면 host.power_on_mode 그리고 host.power_on_config 키. 값에 대한 자세한 내용은 다음 섹션을 참조하십시오.

이러한 필드를 동시에 설정할 수 있는 API 호출도 있습니다.

  void host.set_host_power_on_mode(string mode, Dictionary<string,string> config)
<!--NeedCopy-->

host.power_on_mode

정의: 원격 전원 솔루션의 유형(예: Dell DRAC)을 지정하기 위한 키/값 쌍을 포함합니다.
가능한 값:
- power-control disabled를 나타내는 빈 문자열입니다.
- “DRAC”: Dell DRAC를 지정할 수 있습니다. DRAC를 사용하려면 Dell 보조 팩이 이미 설치되어 있어야 합니다.
- “wake-on-lan”: Wake on LAN을 지정할 수 있습니다.
- 다른 이름(사용자 지정 전원 켜기 스크립트를 지정하는 데 사용됨). 이 옵션은 전원 관리를 위한 사용자 지정 스크립트를 지정하는 데 사용됩니다.
형:문자열

host.power_on_config

정의: 모드 구성을 위한 키/값 쌍을 포함합니다. DRAC에 대한 추가 정보를 제공합니다.
가능한 값:
- DRAC를 원격 전원 솔루션 유형으로 구성한 경우 다음 키 중 하나도 지정해야 합니다.
  - “power_on_ip”: 전원 제어 카드와 통신하도록 구성된 지정한 IP 주소입니다. 또는 DRAC가 구성된 네트워크 인터페이스의 도메인 이름을 입력할 수 있습니다.
  - “power_on_user”: 출하 시 기본 설정에서 변경했을 수 있는 관리 프로세서와 연결된 DRAC 사용자 이름입니다.
  - “power_on_password_secret”: 비밀 기능을 사용하여 암호를 보호하도록 지정합니다.
- 비밀 기능을 사용하여 암호를 저장하려면 “power_on_password_secret” 키를 지정합니다. 자세한 내용은 비밀.
형: 맵(문자열, 문자열)

샘플 스크립트

샘플 스크립트는 Citrix Hypervisor API를 가져오고, 자신을 사용자 지정 스크립트로 정의한 다음, 원격으로 제어하려는 호스트와 관련된 매개 변수를 전달합니다. 매개 변수를 정의해야 합니다 세션 모든 사용자 정의 스크립트에서.

스크립트가 실패하면 결과가 나타납니다.

  import XenAPI
  def custom(session,remote_host,
  power_on_config):
  result="Power On Not Successful"
  for key in power_on_config.keys():
  result=result+''
  key=''+key+''
  value=''+power_on_config[key]
  return result
<!--NeedCopy-->

메모:

스크립트를 만든 후 .py 확장자를 사용하여 /etc/xapi.d/plugins에 저장합니다.

Citrix Hypervisor 서버 및 리소스 풀과 통신

TLS

Citrix Hypervisor는 TLS 1.2 프로토콜을 사용하여 관리 API 트래픽을 암호화합니다. Citrix Hypervisor와 관리 API 클라이언트 (또는 어플라이언스) 간의 모든 통신은 TLS 1.2 프로토콜을 사용합니다.

중요:

제품의 암호화 기능에 대한 고객 수정은 지원하지 않습니다.

Citrix Hypervisor는 다음 암호 그룹을 사용합니다.

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

또한 다음 암호 제품군은 Citrix Virtual Apps 및 Desktops의 일부 버전과의 이전 버전과의 호환성을 위해 지원됩니다.

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256

메모:

이러한 추가 암호 그룹은 CBC 모드를 사용합니다. 일부 조직에서는 GCM 모드를 선호하지만 Windows Server 2012 R2는 GCM 모드를 사용하는 RSA 암호 그룹을 지원하지 않습니다. Citrix Hypervisor 서버 또는 풀에 연결하는 Windows Server 2012 R2에서 실행되는 클라이언트는 이러한 CBC 모드 암호 그룹을 사용해야 할 수 있습니다.

SSH를 참조하십시오

SSH 클라이언트를 사용하여 Citrix Hypervisor 서버에 직접 연결하는 경우 다음 알고리즘을 사용할 수 있습니다.

암호:

AES128-CTR
AES256-CTR
aes128-gcm@openssh.com
aes256-gcm@openssh.com
AES128-CBC 시리즈
AES256-CBC 시리즈

맥:

HMAC-SHA2-256
HMAC-SHA2-512
HMAC-SHA1

켐스알고리즘:

곡선25519-SHA256
ECDH-SHA2-NISP256
ECDH-SHA2-NISP384
ECDH-SHA2-NISP521
디피 헬맨 그룹14-SHA1

HostKeyAlgorithms:

ECDSA-SHA2-NISP256
ECDSA-SHA2-NISP384
ECDSA-SHA2-NISP521
SSH-ED25519
SSH-RSA (영문)

Citrix Hypervisor 서버에 대한 SSH 액세스를 비활성화하려면 에서 이 작업을 수행할 수 있습니다. XSS콘솔.

XenCenter에서 서버 콘솔을 열고 다음과 같이 로그인합니다. 뿌리.
형 XSS콘솔.
안으로 XSS콘솔로 가다 원격 서비스 구성 > Remote Shell 사용/사용 안 함.

콘솔에 원격 셸이 활성화되어 있는지 여부가 표시됩니다.
원격 쉘의 사용 가능 또는 사용 불가능 여부를 변경하려면 들어가다.

중요:

제품의 암호화 기능에 대한 고객 수정은 지원하지 않습니다.

서버에 TLS 인증서 설치

Citrix Hypervisor 서버에는 기본 TLS 인증서가 설치되어 있습니다. 그러나 HTTPS를 사용하여 Citrix Hypervisor와 Citrix Virtual Apps and Desktops 간의 통신을 보호하려면 신뢰할 수 있는 인증 기관에서 제공하는 인증서를 설치하십시오.

이 섹션에서는 xe CLI를 사용하여 인증서를 설치하는 방법에 대해 설명합니다. XenCenter를 사용하여 인증서를 사용하는 방법에 대한 자세한 내용은 다음을 참조하십시오. XenCenter 설명서.

TLS 인증서와 해당 키가 다음 요구 사항을 충족하는지 확인합니다.

인증서와 키 쌍은 RSA 키입니다.
키가 인증서와 일치합니다.
키는 인증서에 별도의 파일로 제공됩니다.
인증서는 중간 인증서와 별도의 파일로 제공됩니다.
키 파일은 다음 유형 중 하나여야 합니다. .펨 또는 .열쇠.
모든 인증서 파일은 다음 유형 중 하나여야 합니다. .펨, .cer또는 .crt.
키는 2048비트보다 크거나 같고 길이가 4096비트보다 작거나 같습니다.
키는 암호화되지 않은 PKCS #8 키이며 암호 키가 없습니다.
키와 인증서는 base-64로 인코딩된 ‘PEM’ 형식입니다.
인증서가 유효하며 만료되지 않았습니다.
서명 알고리즘은 SHA-2(SHA256)입니다.

xe CLI는 선택한 인증서와 키가 이러한 요구 사항을 충족하지 않을 경우 경고를 표시합니다.

TLS 인증서는 어디서 얻을 수 있습니까?

Citrix Hypervisor 서버에 설치하려는 신뢰할 수 있는 인증서가 이미 있을 수 있습니다.
또는 서버에 인증서를 만들고 선호하는 인증 기관에 보내 서명할 수 있습니다. 이 방법은 개인 키가 Citrix Hypervisor 서버에 남아 있고 시스템 간에 복사되지 않을 수 있으므로 더 안전합니다.

TLS 인증서를 만들려면 다음 단계를 수행해야 합니다.

1. 인증서 서명 요청 생성

먼저 개인 키 및 인증서 서명 요청을 생성합니다. Citrix Hypervisor 서버에서 다음 단계를 완료합니다.

프라이빗 키 파일을 만들려면 다음 명령을 실행합니다.
```
  openssl genrsa -des3 -out privatekey.pem 2048

```

키에서 암호를 제거합니다.

  openssl rsa -in privatekey.pem -out privatekey.nop.pem
<!--NeedCopy-->

개인 키를 사용하여 인증서 서명 요청을 만듭니다.

  openssl req -new -key privatekey.nop.pem -out csr
<!--NeedCopy-->

프롬프트에 따라 인증서 서명 요청을 생성하는 데 필요한 정보를 제공합니다.
- 국가 이름. 해당 국가의 TLS 인증서 국가 코드를 입력합니다. 예를 들어 캐나다의 경우 CA 또는 자메이카의 경우 JM입니다. 웹에서 TLS 인증서 국가 코드 목록을 찾을 수 있습니다.
- 시/도 이름(전체 이름). 풀이 위치한 시/도를 입력합니다. 예를 들어 매사추세츠 또는 앨버타입니다.
- 구/군/시 이름. 수영장이 위치한 도시의 이름입니다.
- 조직 이름. 회사 또는 조직의 이름입니다.
- 조직 구성 단위 이름. 부서 이름을 입력합니다. 이 필드는 선택 사항입니다.
- 속칭. Citrix Hypervisor 서버의 FQDN을 입력합니다. Citrix에서는 만료되지 않는 FQDN 또는 IP 주소를 지정하는 것이 좋습니다.
- 이메일 주소. 이 이메일 주소는 인증서를 생성할 때 인증서에 포함됩니다.
인증서 서명 요청은 현재 디렉터리에 저장되고 이름이 지정됩니다. CSR.
다음 명령을 실행하여 콘솔 창에 인증서 서명 요청을 표시합니다.
```
  cat csr

```

전체 인증서 서명 요청을 복사하고 이 정보를 사용하여 인증 기관에서 인증서를 요청합니다.

인증서 서명 요청 예:

  -----BEGIN CERTIFICATE REQUEST-----
  MIIDBDCCAewCAQAwgYsxCzAJBgNVBAYTAlVLMRcwFQYDVQQIDA5DYW1icmlkZ2Vz
  aGlyZTESMBAGA1UEBwwJQ2FtYnJpZGdlMRIwEAYDVQQKDAlYZW5TZXJ2ZXIxFTAT
  ...
  SdYCkFdo+85z8hBULFzSH6jgSP0UGQU0PcfIy7KPKyI4jnFQqeCDvLdWyhtAx9gq
  Fu40qMSm1dNCFfnACRwYQkQgqCt/RHeUtl8srxyZC+odbunnV+ZyQdmLwLuQySUk
  ZL8naumG3yU=
  -----END CERTIFICATE REQUEST-----
<!--NeedCopy-->

2. 인증 기관에 인증서 서명 요청 보내기

이제 인증서 서명 요청을 생성했으므로 조직의 기본 인증 기관에 요청을 제출할 수 있습니다.

인증 기관은 디지털 인증서를 제공하는 신뢰할 수 있는 제3자입니다. 일부 인증 기관에서는 인터넷에서 액세스할 수 있는 시스템에서 인증서를 호스팅해야 합니다. 이 요구 사항이 있는 인증 기관을 사용하지 않는 것이 좋습니다.

인증 기관은 서명 요청에 응답하고 다음 파일을 제공합니다.

서명된 인증서
해당되는 경우 중간 인증서

이제 Citrix Hypervisor 서버에 이러한 모든 파일을 설치할 수 있습니다.

3. Citrix Hypervisor 서버에 서명된 인증서를 설치합니다

인증 기관이 인증서 서명 요청에 응답한 후 다음 단계를 완료하여 Citrix Hypervisor 서버에 인증서를 설치합니다.

서명된 인증서를 가져오고, 인증 기관에 중간 인증서가 있는 경우 인증 기관에서 중간 인증서를 가져옵니다.
키와 인증서를 Citrix Hypervisor 서버에 복사합니다.

서버에서 다음 명령을 실행합니다.

  xe host-server-certificate-install certificate=<path_to_certificate_file> private-key=<path_to_private_key> certificate-chain=<path_to_chain_file>

이 인증서 체인 parameter는 선택 사항입니다.

보안을 강화하기 위해 인증서를 설치한 후 개인 키 파일을 삭제할 수 있습니다.

관리자 비밀번호 관리

Citrix Hypervisor 서버를 처음 설치할 때 관리자 또는 뿌리 암호. 이 암호를 사용하여 XenCenter를 서버에 연결하거나 사용자 이름 뿌리)을 클릭하여 로그인합니다. XSS콘솔, 시스템 구성 콘솔.

서버를 풀에 가입시키면 서버의 관리자 비밀번호가 풀 마스터의 관리자 비밀번호와 일치하도록 자동으로 변경됩니다.

메모:

Citrix Hypervisor 관리자 암호에는 인쇄 가능한 ASCII 문자만 포함되어야 합니다.

비밀번호 변경

XenCenter, xe CLI 또는 XSS콘솔 관리자 암호를 변경합니다.

XenCenter (젠센터)

XenCenter를 사용하여 풀 또는 독립 실행형 서버의 관리자 암호를 변경하려면 다음 단계를 완료하십시오.

안에 리소스 창에서 풀 또는 풀의 서버를 선택합니다.
에 풀 메뉴 또는 서버 메뉴에서 선택 서버 비밀번호 변경.

독립 실행형 서버의 루트 암호를 변경하려면 서버에서 서버를 선택합니다. 리소스 창을 클릭하고 암호 그런 다음 잔돈 에서 서버 메뉴.

XenCenter가 세션 간에 서버 로그인 자격 증명을 저장하도록 구성된 경우 새 암호가 기억됩니다. 자세한 내용은 서버 연결 상태 저장.

관리자 암호를 변경한 후 풀 암호를 회전합니다. 자세한 내용은 풀 시크릿 순환.

xe CLI

xe CLI를 사용하여 관리자 암호를 변경하려면 풀의 서버에서 다음 명령을 실행합니다.

    xe user-password-change new=<new_password>
<!--NeedCopy-->

메모:

명령 기록에 일반 텍스트 비밀번호가 저장되지 않도록 명령 앞에 공백을 붙여야 합니다.

관리자 암호를 변경한 후 풀 암호를 회전합니다. 자세한 내용은 풀 시크릿 순환.

XS콘솔

를 사용하여 풀 또는 독립 실행형 서버에 대한 관리자 암호를 변경하려면To change the administrator password for a pool or standalone server by using XSS콘솔를 사용하여 다음 단계를 완료합니다.

풀 마스터에서 콘솔로 이동합니다.
다음 계정으로 로그인 뿌리.
형 XSS콘솔. 누르다 들어가다. 이 XSS콘솔 가 표시됩니다.
안으로 XSS콘솔에서 화살표 키를 사용하여 인증 선택. 누르다 들어가다.
로 이동합니다. 비밀번호 변경. 누르다 들어가다.
관리자 암호로 인증합니다.
안에 비밀번호 변경 대화:
1. 현재 비밀번호를 입력합니다.
2. 새 비밀번호를 입력합니다.
3. 새 비밀번호를 다시 입력하여 확인합니다.
이 비밀번호 변경 성공 화면이 표시됩니다. 누르다 들어가다 기각합니다.

서버가 풀 마스터인 경우 이 업데이트된 암호는 이제 풀의 다른 서버로 전파됩니다.

관리자 암호를 변경한 후 풀 암호를 회전합니다. 자세한 내용은 풀 시크릿 순환.

분실한 루트 암호 재설정

Citrix Hypervisor 서버의 관리자 (루트) 암호를 분실한 경우 서버에 직접 액세스하여 암호를 재설정할 수 있습니다.

Citrix Hypervisor 서버를 재부팅합니다.
GRUB 메뉴가 표시되면 e 부팅 메뉴 항목을 편집합니다.
더하다 초기화=/sysroot/bin/sh 로 시작하는 줄로 모듈2.
누르다 Ctrl-X 키 루트 셸로 부팅합니다.

명령 셸에서 다음 명령을 실행합니다.

  chroot /sysroot
  passwd

  (type the new password twice)

  sync
  /sbin/reboot -f
<!--NeedCopy-->

서버가 풀 마스터인 경우 이 업데이트된 암호는 이제 풀의 다른 서버로 전파됩니다.

관리자 암호를 변경한 후 풀 암호를 회전합니다.

풀 시크릿 순환

풀 암호는 풀의 서버 간에 공유되는 비밀로, 서버가 풀에 대한 멤버 자격을 증명할 수 있도록 합니다.

풀 관리자 역할이 있는 사용자는 이 비밀을 검색할 수 있으므로 이러한 사용자 중 한 명이 조직을 떠나거나 풀 관리자 역할을 잃을 경우 풀 암호를 교체하는 것이 좋습니다.

XenCenter 또는 xe CLI를 사용하여 풀 암호를 회전할 수 있습니다.

XenCenter (젠센터)

XenCenter를 사용하여 풀의 풀 암호를 회전하려면 다음 단계를 완료하십시오.

안에 리소스 창에서 풀 또는 풀의 서버를 선택합니다.
에 풀 메뉴에서 선택 Rotate Pool Secret(풀 시크릿 순환).

풀 시크릿을 회전할 때 루트 비밀번호를 변경하라는 메시지도 표시됩니다. 환경이 손상되었다고 생각하여 풀 암호를 교체한 경우 루트 암호도 변경해야 합니다. 자세한 내용은 비밀번호 변경.

xe CLI

xe CLI를 사용하여 풀 암호를 회전하려면 풀의 서버에서 다음 명령을 실행합니다.

  xe pool-secret-rotate
<!--NeedCopy-->

환경이 손상되었다고 생각하여 풀 암호를 교체한 경우 루트 암호도 변경해야 합니다. 자세한 내용은 비밀번호 변경.

Citrix Hypervisor 풀에서 IGMP 스누핑 활성화

Citrix Hypervisor는 모든 게스트 VM으로 멀티캐스트 트래픽을 전송하여 요청하지 않은 패킷을 처리하도록 요구함으로써 호스트 장치에 불필요한 부하를 초래합니다. IGMP 스누핑을 활성화하면 로컬 네트워크의 호스트가 명시적으로 가입하지 않은 멀티캐스트 그룹에 대한 트래픽을 수신하는 것을 방지하고 멀티캐스트 성능을 향상시킬 수 있습니다. IGMP 스누핑은 IPTV와 같이 대역폭을 많이 사용하는 IP 멀티캐스트 애플리케이션에 특히 유용합니다.

노트:

IGMP 스누핑은 네트워크 백엔드가 Open vSwitch를 사용하는 경우에만 사용할 수 있습니다.

풀에서 이 기능을 활성화할 때 물리적 스위치 중 하나에서 IGMP 쿼리 발생기를 활성화해야 할 수도 있습니다. 그렇지 않으면 서브 네트워크의 멀티캐스트가 브로드캐스트로 대체되어 Citrix Hypervisor 성능이 저하될 수 있습니다.

IGMP v3을 실행하는 풀에서 이 기능을 사용하도록 설정하면 VM 마이그레이션 또는 네트워크 결합 장애 조치(failover)로 인해 IGMP 버전이 v2로 전환됩니다.

GRE 네트워크에서 이 기능을 활성화하려면 사용자가 GRE 네트워크에서 IGMP 쿼리 발생기를 설정해야 합니다. 또는 물리적 네트워크에서 GRE 네트워크로 IGMP 쿼리 메시지를 전달할 수 있습니다. 그렇지 않으면 GRE 네트워크의 멀티캐스트 트래픽을 차단할 수 있습니다.

XenCenter 또는 xe CLI를 사용하여 풀에서 IGMP 스누핑을 활성화할 수 있습니다.

XenCenter (젠센터)

로 이동합니다. 풀 속성.
고르다 네트워크 옵션. 여기에서 IGMP 스누핑을 활성화하거나 비활성화할 수 있습니다.

xe CLI

풀 UUID를 가져옵니다.

xe pool-list
풀에 대한 IGMP 스누핑을 활성화/비활성화합니다.

xe pool-param-set [uuid=pool-uuid] [igmp-snooping-enabled=true|false]

IGMP 스누핑을 활성화한 후 xe CLI를 사용하여 IGMP 스누핑 테이블을 볼 수 있습니다.

IGMP 스누핑 테이블 보기

다음 명령을 사용하여 IGMP 스누핑 테이블을 확인합니다.

ovs-appctl mdb/show [bridge name]

메모:

를 사용하여 브리지 이름을 가져올 수 있습니다. xe 네트워크 목록. 이러한 브리지 이름은 다음과 같을 수 있습니다. xenbr0, xenbr1, 제나피또는 엑스피0.

그러면 4개의 열이 있는 테이블이 출력됩니다.

포트: 스위치(OVS)의 포트입니다.
VLAN: 트래픽의 VLAN ID입니다.
GROUP: 포트가 요청한 멀티캐스트 그룹입니다.
나이: 이 레코드의 나이(초)입니다.

만약에 그룹 은 멀티캐스트 그룹 주소이며, 이는 연결된 스위치 포트에서 IGMP 보고서 메시지가 수신되었음을 의미합니다. 이는 멀티캐스트 그룹의 수신기(구성원)가 이 포트에서 수신 대기하고 있음을 의미합니다.

두 개의 레코드가 포함된 다음 예제를 살펴보겠습니다.

포트	VLAN (영어)	그룹	연령
14	0	227.0.0.1	15
1	0	쿼리 발생기	24

첫 번째 레코드는 멀티캐스트 그룹 227.0.0.1에 대해 포트 14에서 수신 대기하는 수신기가 있음을 보여줍니다. Open vSwitch는 227.0.0.1 멀티캐스트 그룹으로 향하는 트래픽을 모든 포트로 브로드캐스트하지 않고 이 그룹의 수신 포트(이 예에서는 포트 14)로만 전달합니다. 포트 14 및 그룹 227.0.0.1을 연결하는 레코드가 15초 전에 생성되었습니다. 기본적으로 시간 제한 간격은 300초입니다. 즉, 스위치가 레코드를 추가한 후 300초 동안 포트 14에서 더 이상 IGMP 보고서 메시지를 수신하지 않으면 레코드가 만료되고 테이블에서 제거됩니다.

두 번째 레코드에서 그룹 다음과 같음 쿼리 발생기이는 IGMP 쿼리 메시지가 연결된 포트에서 수신되었음을 의미합니다. 쿼리 발생기는 모든 스위치 포트로 브로드캐스트되는 IGMP 쿼리 메시지를 주기적으로 전송하여 멀티캐스트 그룹에서 수신 대기 중인 네트워크 노드를 확인합니다. IGMP 쿼리 메시지를 받으면 수신자는 IGMP 보고서 메시지로 응답하며, 이로 인해 수신자의 멀티캐스트 레코드가 새로 고쳐지고 만료되지 않습니다.

이 VLAN (영어) 열은 수신기/쿼리 발생기가 살고 있음을 VLAN에 나타냅니다. ‘0’은 기본 VLAN을 의미합니다. 태그가 지정된 일부 VLAN에서 멀티캐스트를 실행하려면 VLAN에 레코드가 있는지 확인합니다.

메모:

VLAN 시나리오의 경우 VLAN 열 값이 네트워크의 VLAN ID와 동일한 쿼리 발생기 레코드가 있어야 하며, 그렇지 않으면 VLAN 네트워크에서 멀티캐스트가 작동하지 않습니다.

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

도움이 되었나요?

호스트 및 리소스 풀

January 31, 2025

제공::

January 31, 2025

제공::

이 문서

Citrix Hypervisor 서버 및 리소스 풀 개요
자원 그룹을 만들기 위한 요구 사항
자원 그룹 만들기
xe CLI를 사용하여 풀에 호스트 추가
다른 유형의 리소스 풀 만들기Create heterogeneous resource pools
공유 스토리지 추가하기
리소스 풀에서 Citrix Hypervisor 서버 제거
유지 관리를 위해 Citrix Hypervisor 서버 풀을 준비합니다
자원 그룹 데이터 내보내기Export resource pool data
호스트 전원 켜기
Citrix Hypervisor 서버 및 리소스 풀과 통신
서버에 TLS 인증서 설치
관리자 비밀번호 관리
풀 시크릿 순환
Citrix Hypervisor 풀에서 IGMP 스누핑 활성화

도움이 되었나요?