검색

가상화

download PDF
OpenShift Container Platform 4.11

OpenShift Virtualization 설치, 사용법, 릴리스 정보

Red Hat OpenShift Documentation Team

초록

이 문서에서는 OpenShift Container Platform에서 OpenShift Virtualization을 사용하는 방법에 대한 정보를 제공합니다.

1장. OpenShift Virtualization 정보

OpenShift Virtualization의 기능 및 지원 범위에 대해 알아보십시오.

1.1. OpenShift Virtualization으로 수행할 수 있는 작업

OpenShift Virtualization은 컨테이너 워크로드와 함께 가상 머신 워크로드를 실행하고 관리할 수 있는 OpenShift Container Platform의 애드온입니다.

OpenShift Virtualization에서는 Kubernetes 사용자 정의 리소스를 사용하여 가상화 작업을 활성화하여 OpenShift Container Platform 클러스터에 새 오브젝트를 추가합니다. 다음과 같은 가상화 작업이 지원됩니다.

  • Linux 및 Windows 가상 머신 생성 및 관리
  • 다양한 콘솔 및 CLI 툴을 통해 가상 머신에 연결
  • 기존 가상 머신 가져오기 및 복제
  • 가상 머신에 연결된 네트워크 인터페이스 컨트롤러 및 스토리지 디스크 관리
  • 노드 간 실시간 가상 머신 마이그레이션

향상된 웹 콘솔에서 제공되는 그래픽 포털을 통해 OpenShift Container Platform 클러스터 컨테이너 및 인프라와 함께 가상화 리소스를 관리할 수 있습니다.

OpenShift Virtualization은 Red Hat OpenShift Data Foundation 기능과 함께 제대로 작동하도록 설계 및 테스트되었습니다.

중요

OpenShift Data Foundation을 사용하여 OpenShift Virtualization을 배포할 때 Windows 가상 머신 디스크용 전용 스토리지 클래스를 생성해야 합니다. 자세한 내용은 Windows VM용 ODF PersistentVolume 최적화 를 참조하십시오.

OVN-Kubernetes,OpenShift SDN 또는 Certified OpenShift CNI Plug-ins 에 나열된 다른 인증된 기본 CNI(Container Network Interface) 네트워크 공급자 중 하나와 함께 OpenShift Virtualization을 사용할 수 있습니다.

Compliance Operator 를 설치하고 ocp4-moderateocp4-moderate-node 프로필 로 검사를 실행하여 OpenShift Virtualization 클러스터에서 규정 준수 문제가 있는지 확인할 수 있습니다. Compliance Operator는 NIST 인증 툴 인 OpenSCAP을 사용하여 보안 정책을 검사하고 시행합니다.

중요

Compliance Operator와 OpenShift Virtualization 통합은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

1.1.1. OpenShift Virtualization 지원 클러스터 버전

OpenShift Container Platform 4.11 클러스터에서 사용할 수 있도록 OpenShift Virtualization 4.11이 지원됩니다. OpenShift Virtualization의 최신 z-stream 릴리스를 사용하려면 먼저 최신 OpenShift Container Platform 버전으로 업그레이드해야 합니다.

2장. OpenShift Virtualization 아키텍처

OpenShift Virtualization 아키텍처에 대해 알아보기.

2.1. OpenShift Virtualization 아키텍처의 작동 방식

OpenShift Virtualization을 설치한 후 OLM(Operator Lifecycle Manager)은 OpenShift Virtualization의 각 구성 요소에 대해 Operator Pod를 배포합니다.

  • 컴퓨팅: virt-operator
  • 스토리지: cdi-operator
  • 네트워크: cluster-network-addons-operator
  • 스케일링: ssp-operator
  • templating: tekton-tasks-operator

또한 OLM은 다른 구성 요소의 배포, 구성 및 라이프사이클을 담당하는 hyperconverged-cluster-operator Pod 및 hco-webhook, hyperconverged-cluster-cli-download 의 여러 도우미 Pod를 배포합니다.

모든 Operator Pod가 배포된 후 HyperConverged CR(사용자 정의 리소스)을 생성해야 합니다. HyperConverged CR에 설정된 구성은 단일 정보 소스 및 OpenShift Virtualization의 진입점 역할을 하며 CR의 동작을 안내합니다.

HyperConverged CR은 조정 루프 내에서 다른 모든 구성 요소의 Operator에 대한 해당 CR을 생성합니다. 그런 다음 각 Operator는 데몬 세트, 구성 맵, OpenShift Virtualization 컨트롤 플레인에 대한 추가 구성 요소와 같은 리소스를 생성합니다. 예를 들어 hco-operator 에서 KubeVirt CR을 생성할 때 virt-operator 는 이를 조정하고 virt-controller,virt-handler, virt-api 와 같은 추가 리소스를 생성합니다.

OLM은 hostpath-provisioner-operator 를 배포하지만 HBA(Host path 프로비전 프로그램 ) CR을 생성할 때까지 작동하지 않습니다.

CNV Deployments

2.2. hco-operator 정보

hco-operator (HCO)는 OpenShift Virtualization 배포 및 관리를 위한 단일 진입점과 의견된 기본값을 사용하여 여러 도우미 운영자를 제공합니다. 또한 해당 Operator에 대한 사용자 정의 리소스(CR)를 생성합니다.

HCO-operator 구성 요소
표 2.1. HCO-operator 구성 요소
구성 요소설명

deployment/hco-webhook

HyperConverged 사용자 정의 리소스 콘텐츠를 검증합니다.

deployment/hyperconverged-cluster-cli-download

클러스터에서 직접 다운로드할 수 있도록 virtctl 툴 바이너리를 클러스터에 제공합니다.

KubeVirt/kubevirt-kubevirt-hyperconverged

OpenShift Virtualization에 필요한 모든 Operator, CR 및 오브젝트를 포함합니다.

SSP/ssp-kubevirt-hyperconverged

An SSP CR. 이는 HCO에 의해 자동으로 생성됩니다.

CDI/cdi-kubevirt-hyperconverged

A CDI CR. 이는 HCO에 의해 자동으로 생성됩니다.

NetworkAddonsConfig/cluster

cluster-network-addons-operator 에 의해 관리되고 있는 CR.

2.3. cdi-operator 정보

cdi-operator 는 데이터 볼륨을 사용하여 가상 머신(VM) 이미지를 PVC(영구 볼륨 클레임)로 가져오는 CDI(Containerized Data Importer) 및 관련 리소스를 관리합니다.

CDI-operator 구성 요소
표 2.2. CDI-operator 구성 요소
구성 요소설명

deployment/cdi-apiserver

보안 업로드 토큰을 발행하여 VM 디스크를 PVC에 업로드하는 권한 부여를 관리합니다.

deployment/cdi-uploadproxy

올바른 PVC에 쓸 수 있도록 외부 디스크 업로드 트래픽을 적절한 업로드 서버 Pod로 보냅니다. 유효한 업로드 토큰이 필요합니다.

pod/cdi-importer

데이터 볼륨을 생성할 때 가상 머신 이미지를 PVC로 가져오는 도우미 Pod

2.4. cluster-network-addons-operator 정보

cluster-network-addons-operator 는 클러스터에 네트워킹 구성 요소를 배포하고 확장된 네트워크 기능을 위한 관련 리소스를 관리합니다.

cluster-network-addons-operator 구성 요소
표 2.3. cluster-network-addons-operator 구성 요소
구성 요소설명

deployment/kubemacpool-cert-manager

Kubemacpool의 웹 후크의 TLS 인증서를 관리합니다.

deployment/kubemacpool-mac-controller-manager

VM(가상 머신) NIC(네트워크 인터페이스 카드)에 대한 MAC 주소 풀링 서비스를 제공합니다.

daemonset/bridge-marker

노드에서 사용 가능한 네트워크 브릿지를 노드 리소스로 표시합니다.

daemonset/kube-cni-linux-bridge-plugin

클러스터 노드에 CNI 플러그인을 설치하여 네트워크 연결 정의를 통해 VM을 Linux 브리지에 연결할 수 있습니다.

2.5. hostpath-provisioner-operator 정보

hostpath-provisioner-operator 는 다중 노드 호스트 경로 프로비전 프로그램(HPP) 및 관련 리소스를 배포하고 관리합니다.

HPP-operator 구성 요소
표 2.4. hostPath-provisioner-operator 구성 요소
구성 요소설명

deployment/hpp-pool-hpp-csi-pvc-block-<worker_node_name>

HPP(Hostpath 프로비전 프로그램)가 실행되도록 지정된 각 노드에 대한 작업자를 제공합니다. Pod는 지정된 백업 스토리지를 노드에 마운트합니다.

daemonset/hostpath-provisioner-csi

HPP의 CSI(Container Storage Interface) 드라이버 인터페이스를 구현합니다.

daemonset/hostpath-provisioner

HPP의 레거시 드라이버 인터페이스를 구현합니다.

2.6. ssp-operator 정보

ssp-operator 는 공통 템플릿, 관련 기본 부팅 소스 및 템플릿 유효성 검증기를 배포합니다.

SSP-operator 구성 요소
표 2.5. SSP-operator 구성 요소
구성 요소설명

deployment/virt-template-validator

템플릿에서 생성된 가상 머신에서 vm.kubevirt.io/validations 주석을 확인하고 유효하지 않은 경우 해당 주석을 거부합니다.

2.7. tekton-tasks-operator 정보

tekton-tasks-operator 는 VM의 OpenShift Pipelines 사용을 보여주는 예제 파이프라인을 배포합니다. 또한 사용자가 템플릿에서 VM을 생성하고 템플릿을 복사 및 수정하고 데이터 볼륨을 생성할 수 있는 추가 OpenShift Pipeline 작업을 배포합니다.

Tekton-tasks-operator 구성 요소

2.8. virt-operator 정보

virt-operator 는 현재 VM(가상 머신) 워크로드를 중단하지 않고 OpenShift Virtualization을 배포, 업그레이드, 관리합니다.

virt-operator 구성 요소
표 2.6. virt-operator 구성 요소
구성 요소설명

deployment/virt-api

모든 가상화 관련 흐름에 대한 진입점 역할을 하는 HTTP API 서버입니다.

deployment/virt-controller

새 VM 인스턴스 오브젝트 생성을 관찰하고 해당 Pod를 생성합니다. Pod가 노드에 예약되면 virt-controller 가 VM을 노드 이름으로 업데이트합니다.

daemonset/virt-handler

VM의 변경 사항을 모니터링하고 virt-launcher 에 필요한 작업을 수행하도록 지시합니다. 이 구성 요소는 노드에 따라 다릅니다.

pod/virt-launcher

libvirtqemu 에서 구현된 대로 사용자가 생성한 VM을 포함합니다.

3장. OpenShift Virtualization 시작하기

기본 OpenShift Virtualization 환경을 설치하고 구성하여 해당 기능 및 기능을 확인할 수 있습니다.

참고

클러스터 구성 절차에는 cluster-admin 권한이 필요합니다.

3.1. 시작하기 전

3.1.1. 추가 리소스

3.2. 시작하기

가상 머신을 생성합니다.

가상 머신에 연결합니다.

가상 머신에 연결
가상 머신 관리
  • 웹 콘솔에서 가상 머신을 중지, 시작, 일시 중지 및 재시작합니다.
  • 가상 머신을 관리하고, 포트를 노출한 다음 virtctl사용하여 명령줄에서 가상 머신의 직렬 콘솔에 연결합니다.

3.3. 다음 단계

보조 네트워크에 VM 연결
OpenShift Virtualization 환경 모니터링
배포 자동화

3.3.1. 추가 리소스

4장. OpenShift Virtualization 릴리스 정보

4.1. 보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 Red Hat CTO Chris Wright의 메시지에서 참조하십시오.

4.2. Red Hat OpenShift Virtualization 정보

Red Hat OpenShift Virtualization을 사용하면 기존 VM(가상 머신)을 컨테이너와 함께 실행되는 OpenShift Container Platform으로 가져와 네이티브 Kubernetes 오브젝트로 관리할 수 있습니다.

OpenShift Virtualization은 OpenShift Virtualization 아이콘으로 표시됩니다.

OVN-Kubernetes 또는 OpenShiftSDN 기본 CNI(Container Network Interface) 네트워크 공급자와 함께 OpenShift Virtualization을 사용할 수 있습니다.

OpenShift Virtualization으로 수행할 수 있는 작업에 대해 자세히 알아보십시오.

OpenShift Virtualization 아키텍처 및 배포에 대해 자세히 알아보십시오.

OpenShift Virtualization을 위해 클러스터를 준비합니다.

4.2.1. OpenShift Virtualization 지원 클러스터 버전

OpenShift Container Platform 4.11 클러스터에서 사용할 수 있도록 OpenShift Virtualization 4.11이 지원됩니다. OpenShift Virtualization의 최신 z-stream 릴리스를 사용하려면 먼저 최신 OpenShift Container Platform 버전으로 업그레이드해야 합니다.

4.2.2. 지원되는 게스트 운영 체제

OpenShift Virtualization에서 지원되는 게스트 운영 체제를 보려면 Red Hat OpenStack Platform, Red Hat Virtualization 및 OpenShift Virtualization에서 인증된 게스트 운영 체제를 참조하십시오.

4.3. 새로운 기능 및 변경된 기능

  • 이제 컴퓨팅 노드가 0인 3- 노드 클러스터에 OpenShift Virtualization을 배포할 수 있습니다.
  • 가상 머신은 기본적으로 세션 모드에서 권한이 없는 워크로드로 실행됩니다. 이 기능을 사용하면 권한 에스컬레이션 공격을 완화하여 클러스터 보안이 향상됩니다.
  • RHEL(Red Hat Enterprise Linux) 9는 이제 게스트 운영 체제로 지원됩니다.
  • OpenShift Container Platform 웹 콘솔에서 Migration Toolkit for Virtualization (MTV) Operator를 설치하는 링크가 이동되었습니다. 이제 가상화개요 페이지에 있는 시작 리소스 카드의 관련 운영자 섹션에 있습니다.
  • HyperConverged CR(사용자 정의 리소스)을 편집하여 virtLauncher,virtController,virtAPI, virtOperator Pod 로그의 상세 정보 수준을 구성하여 특정 구성 요소를 디버깅할 수 있습니다.

4.3.1. 퀵스타트

  • 여러 OpenShift Virtualization 기능에 대한 퀵스타트 둘러보기를 사용할 수 있습니다. 둘러보기를 보려면 OpenShift Virtualization 콘솔 헤더에 있는 메뉴 표시줄에서 Help 아이콘 ?을 클릭한 다음 퀵스타트를 선택합니다. 필터 필드에 virtualization 키워드를 입력하여 사용 가능한 둘러보기를 필터링할 수 있습니다.

4.3.2. 스토리지

4.3.3. 웹 콘솔

  • 웹 콘솔을 사용하여 템플릿 및 가상 머신의 부팅 모드BIOS,UEFI 또는 UEFI (보안) 로 설정할 수 있습니다.
  • 이제 VirtualMachine 세부 정보 페이지의 스케줄링 탭에 있는 웹 콘솔에서 Descheduler를 활성화 및 비활성화할 수 있습니다.
  • 사이드 메뉴에서 VirtualizationVirtualMachines 로 이동하여 가상 머신에 액세스할 수 있습니다. 각 가상 머신에는 가상 머신 구성, 경고, 스냅샷, 네트워크 인터페이스, 디스크, 사용 데이터 및 하드웨어 장치에 대한 정보를 제공하는 업데이트된 개요 탭이 있습니다.
  • 웹 콘솔에서 가상 머신 생성 마법사가 이제 카탈로그 페이지로 교체되어 가상 머신을 생성하는 데 사용할 수 있는 사용 가능한 템플릿이 나열됩니다. 사용 가능한 부팅 소스와 함께 템플릿을 사용하여 가상 머신을 빠르게 생성하거나 템플릿을 사용자 지정하여 가상 머신을 생성할 수 있습니다.
  • Windows 가상 머신에 vGPU가 연결된 경우 웹 콘솔 을 사용하여 기본 디스플레이와 vGPU 표시 간에 전환 할 수 있습니다.
  • 사이드 메뉴에서 가상화 → 템플릿으로 이동하여 가상 머신 템플릿에 액세스할 수 있습니다. 업데이트된 VirtualMachine 템플릿 페이지에서 워크로드 프로필, 부팅 소스, CPU 및 메모리 구성을 포함하여 각 템플릿에 대한 유용한 정보를 제공합니다.
  • Create Template (템플릿 생성) 마법사가 VirtualMachine Templates ( VirtualMachine 템플릿) 페이지에서 제거되었습니다. YAML 파일 예제를 편집하여 가상 머신 템플릿을 생성합니다.

4.4. 사용되지 않거나 삭제된 기능

4.4.1. 더 이상 사용되지 않는 기능

더 이상 사용되지 않는 기능은 현재 릴리스에 포함되어 있으며 지원됩니다. 그러나 향후 릴리스에서 제거될 예정이므로 새로운 배포에는 사용하지 않는 것이 좋습니다.

  • 향후 릴리스에서는 레거시 HPP 사용자 정의 리소스 및 관련 스토리지 클래스에 대한 지원이 더 이상 사용되지 않습니다. OpenShift Virtualization 4.11부터 HPP Operator는 Kubernetes CSI(Container Storage Interface) 드라이버를 사용하여 로컬 스토리지를 구성합니다. Operator는 HPP 사용자 정의 리소스 및 관련 스토리지 클래스의 기존(레거시) 형식을 계속 지원합니다. HPP Operator를 사용하는 경우 마이그레이션 전략의 일부로 CSI 드라이버의 스토리지 클래스를 생성할 계획입니다.

4.4.2. 삭제된 기능

제거된 기능은 현재 릴리스에서 지원되지 않습니다.

  • OpenShift Virtualization 4.11에서는 다음 오브젝트를 포함하여 nmstate 에 대한 지원을 제거합니다.

    • NodeNetworkState
    • NodeNetworkConfigurationPolicy
    • NodeNetworkConfigurationEnactment

    기존 nmstate 구성을 유지하고 지원하려면 OpenShift Virtualization 4.11로 업데이트하기 전에 Kubernetes NMState Operator 를 설치합니다. OpenShift Container Platform 웹 콘솔의 OperatorHub 에서 설치하거나 OpenShift CLI(oc)를 사용하여 설치할 수 있습니다.

  • Node Maintenance Operator (NMO)는 더 이상 OpenShift Virtualization과 함께 제공되지 않습니다. OpenShift Container Platform 웹 콘솔 OperatorHub 에서 NMO를 설치하거나 OpenShift CLI(oc)를 사용하여 NMO를 설치할 수 있습니다.

    OpenShift Virtualization 4.10.2 이상 릴리스에서 OpenShift Virtualization 4.11로 업데이트하기 전에 다음 작업 중 하나를 수행해야 합니다.

    • 모든 노드를 유지보수 모드에서 이동합니다.
    • 독립 실행형 NMO를 설치하고 nodemaintenances.nodemaintenance.kubevirt.io CR(사용자 정의 리소스)을 nodemaintenances.nodemaintenance.medik8s.io CR로 교체합니다.
  • 더 이상 가상 머신 템플릿을 즐겨 찾기로 표시할 수 없습니다.

4.5. 기술 프리뷰 기능

이 릴리스의 일부 기능은 현재 기술 프리뷰 단계에 있습니다. 이러한 실험적 기능은 프로덕션용이 아닙니다. 해당 기능은 Red Hat Customer Portal의 지원 범위를 참조하십시오.

기술 프리뷰 기능 지원 범위

  • 이제 Microsoft Windows 11을 게스트 운영 체제로 사용할 수 있습니다. 그러나 OpenShift Virtualization 4.11은 USB 디스크를 지원하지 않습니다.이 디스크는ECDHE 복구의 중요한 기능에 필요합니다. 복구 키를 보호하려면ECDHE 복구 가이드에 설명된 다른 방법을 사용하십시오.
  • 이제 AWS 베어 메탈 노드에 OpenShift Virtualization을 배포할 수 있습니다.
  • OpenShift Virtualization에는 즉각적인 주의가 필요한 문제가 발생할 때 이를 알리는 중요한 경고 가 있습니다. 이제 각 경고에 해당 문제에 대한 설명, 경고가 발생하는 이유, 문제 소스를 진단하는 문제 해결 프로세스, 경고 해결 단계 등이 있습니다.
  • 이제 관리자는 HyperConverged CR을 편집하여 가상 그래픽 처리 장치(vGPU)와 같은 중재된 장치를 작성하고 노출 할 수 있습니다. 그런 다음 가상 머신 소유자는 이러한 장치를 VM에 할당할 수 있습니다.
  • 이제 IBM Cloud 베어메탈 서버에 OpenShift Virtualization을 설치할 수 있습니다. 다른 클라우드 공급자가 제공하는 베어 메탈 서버는 지원되지 않습니다.
  • OpenShift Virtualization에는 이제 클러스터 유지 관리 및 문제 해결에 사용할 수 있는 사전 정의된 점검 기능을 실행하는 진단 프레임워크 가 포함되어 있습니다. 사전 정의된 검사를 실행하여 보조 네트워크의 가상 머신에 대한 네트워크 연결 및 대기 시간을 확인할 수 있습니다.
  • 대역폭 사용량, 최대 병렬 마이그레이션 및 시간 초과와 같은 특정 매개 변수로 실시간 마이그레이션 정책을 생성하고 가상 머신 및 네임스페이스 레이블을 사용하여 가상 머신 그룹에 정책을 적용할 수 있습니다.

4.6. 버그 수정

  • 이전에는 대규모 클러스터에서 OpenShift Virtualization MAC 풀 관리자가 부팅하는 데 너무 많은 시간이 걸렸고 OpenShift Virtualization이 준비되지 않을 수 있었습니다. 이번 업데이트를 통해 풀 초기화 및 시작 대기 시간이 단축됩니다. 결과적으로 VM을 성공적으로 정의할 수 있습니다. (BZ#2035344)
  • 종료 중에 Windows VM이 충돌하거나 중단되는 경우 이제 VM을 중지하도록 강제 종료 요청을 수동으로 실행할 수 있습니다. (BZ#2040766)
  • 이제 VM 마법사의 YAML 예제가 최신 업스트림 변경 사항을 포함하도록 업데이트되었습니다. (BZ#2055492)
  • 권한이 없는 사용자에게는 VM 네트워크 인터페이스 탭의 네트워크 인터페이스 추가 버튼이 더 이상 비활성화되어 있지 않습니다. (BZ#2056420)
  • 권한이 없는 사용자는 RBAC 규칙 오류 없이 VM에 디스크를 성공적으로 추가할 수 있습니다. (BZ#2056421)
  • 이제 웹 콘솔에서 사용자 정의 네임스페이스에 배포된 가상 머신 템플릿을 성공적으로 표시합니다. (BZ#2054650)
  • 이전 버전에서는 spec.evictionStrategy 필드가 VMI의 LiveMigrate 로 설정된 경우 SNO(Single Node OpenShift) 클러스터를 업데이트하는 데 실패했습니다. 실시간 마이그레이션에 성공하려면 클러스터에 컴퓨팅 노드가 두 개 이상 있어야 합니다. 이번 업데이트를 통해 spec.evictionStrategy 필드가 SNO 환경의 가상 머신 템플릿에서 제거됩니다. 이로 인해 클러스터 업데이트가 성공적으로 수행됩니다. (BZ#2073880)

4.7. 확인된 문제

  • 단일 스택 IPv6 클러스터에서는 OpenShift Virtualization을 실행할 수 없습니다. (BZ#2193267)
  • 다른 컴퓨팅 노드가 있는 이기종 클러스터에서는 TSC(Timest-counter scaling)를 지원하지 않거나 적절한 TSC 빈도를 갖는 노드에 HyperV Reenlightenment가 활성화된 가상 머신을 예약할 수 없습니다. (BZ#2151169)
  • 다른 SELinux 컨텍스트가 있는 두 개의 Pod를 사용하면 ocs-storagecluster-cephfs 스토리지 클래스가 있는 VM이 마이그레이션되지 않고 VM 상태가 일시 중지됨으로 변경됩니다. 두 Pod 모두 공유 ReadWriteMany CephFS 볼륨에 동시에 액세스하려고 하기 때문입니다. (BZ#2092271)

    • 이 문제를 해결하려면 ocs-storagecluster-ceph-rbd 스토리지 클래스를 사용하여 Red Hat Ceph Storage를 사용하는 클러스터에서 VM을 실시간 마이그레이션합니다.
  • OpenShift Virtualization을 업데이트하지 않고 OpenShift Container Platform을 버전 4.11로 업데이트하면 VM 스냅샷이 복원되지 않습니다. 이는 스냅샷 오브젝트에 사용된 API 버전이 일치하지 않기 때문입니다. (BZ#2159442)

  • OpenShift Virtualization을 설치 제거해도 OpenShift Virtualization에서 생성한 노드 레이블은 제거되지 않습니다. 라벨을 수동으로 제거해야 합니다. (CNV-22036)
  • NodePort 서비스를 많이 생성하면 OVN-Kubernetes 클러스터 네트워크 공급자가 최대 RAM 및 CPU 사용량에서 충돌합니다. 이는 NodePort 서비스를 사용하여 다수의 VM(가상 머신)에 대한 SSH 액세스를 노출하는 경우 발생할 수 있습니다. (OCPBUGS-1940)

    • 이 문제를 해결하려면 NodePort 서비스를 통해 많은 VM에 SSH 액세스를 노출하려면 OpenShift SDN 클러스터 네트워크 공급자를 사용하십시오.
  • 버전 4.10에서 OpenShift Virtualization 4.11로 업데이트하는 것은 독립 실행형 Kubernetes NMState Operator를 설치할 때까지 차단됩니다. 이는 클러스터 구성에서 nmstate 리소스를 사용하지 않는 경우에도 발생합니다. (BZ#2126537)

    • 해결 방법:

      1. 클러스터에 정의된 노드 네트워크 구성 정책이 없는지 확인합니다.

        $ oc get nncp
      2. OpenShift Virtualization을 업데이트하는 적절한 방법을 선택합니다.

        1. 노드 네트워크 구성 정책 목록이 비어 있지 않은 경우 다음 절차를 종료하고 Kubernetes NMState Operator 를 설치하여 기존 nmstate 구성을 유지하고 지원합니다.
        2. 목록이 비어 있으면 3단계로 이동합니다.
      3. HyperConverged CR(사용자 정의 리소스)에 주석을 추가합니다. 다음 명령은 기존 JSON 패치를 덮어씁니다.

        $ oc annotate --overwrite -n openshift-cnv hco kubevirt-hyperconverged 'networkaddonsconfigs.kubevirt.io/jsonpatch=[{"op": "replace","path": "/spec/nmstate", "value": null}]'
        참고

        HyperConverged 오브젝트 는 이 패치가 적용되는 동안 TaintedConfiguration 조건을 보고합니다. 이것은 benign입니다.

      4. OpenShift Virtualization을 업데이트합니다.
      5. 업데이트가 완료되면 다음 명령을 실행하여 주석을 제거합니다.

        $ oc annotate -n openshift-cnv hco kubevirt-hyperconverged networkaddonsconfigs.kubevirt.io/jsonpatch-
      6. 선택 사항: 이전에 구성된 JSON 패치를 다시 추가하여 덮어씁니다.
  • CDI(Containerized Data Importer)로 생성된 일부 PVC(영구 볼륨 클레임) 주석은 가상 머신 스냅샷 복원 작업이 무기한 중단될 수 있습니다. (BZ#2070366)

    • 이 문제를 해결하려면 주석을 수동으로 제거할 수 있습니다.

      1. VirtualMachineSnapshot CR의 status.virtualMachineSnapshotContentName 값에서 VirtualMachineSnapshotContent CR(사용자 정의 리소스) 이름을 가져옵니다.
      2. VirtualMachineSnapshotContent CR을 편집하고 k8s.io/cloneRequest 가 포함된 모든 행을 제거합니다.
      3. VirtualMachine 오브젝트에서 spec.dataVolumeTemplates 값을 지정하지 않은 경우 다음 두 조건이 모두 true인 이 네임스페이스의 모든 DataVolumePersistentVolumeClaim 오브젝트를 삭제합니다.

        1. 오브젝트의 이름은 restore로 시작합니다.
        2. 가상 머신에서 오브젝트를 참조하지 않습니다.

          spec.dataVolumeTemplates 에 값을 지정한 경우 이 단계는 선택 사항입니다.

      4. 업데이트된 VirtualMachineSnapshot CR을 사용하여 복원 작업을 반복합니다.
  • Windows 11 가상 머신은 FIPS 모드에서 실행되는 클러스터에서 부팅되지 않습니다. Windows 11에는 기본적으로 TPM(신뢰할 수 있는 플랫폼 모듈) 장치가 필요합니다. 그러나 swtpm (software TPM 에뮬레이터) 패키지는 FIPS와 호환되지 않습니다. (BZ#2089301)
  • SRMNO(Single Node OpenShift) 클러스터에서 제거 전략이 LiveMigrate 로 설정된 공통 템플릿에서 생성된 가상 머신에서 VMCannotBeEvicted 경고가 발생합니다. (BZ#2092412)
  • Fedora 35 가상 머신의 QEMU 게스트 에이전트는 SELinux에 의해 차단되며 데이터를 보고하지 않습니다. 다른 Fedora 버전은 영향을 받을 수 있습니다. (BZ#2028762)

    • 이 문제를 해결하려면 가상 머신에서 SELinux를 비활성화하고 QEMU 게스트 에이전트 명령을 실행한 다음 SELinux를 다시 활성화합니다.
  • OpenShift Container Platform 클러스터에서 OVN-Kubernetes를 기본 CNI(Container Network Interface) 공급자로 사용하는 경우 OVN-Kubernetes의 호스트 네트워크 토폴로지 변경으로 인해 Linux 브리지 또는 본딩 장치를 호스트의 기본 인터페이스에 연결할 수 없습니다. (BZ#1885605)

    • 해결 방법으로 호스트에 연결된 보조 네트워크 인터페이스를 사용하거나 OpenShift SDN 기본 CNI 공급자로 전환할 수 있습니다.
  • Red Hat Ceph Storage 또는 Red Hat OpenShift Data Foundation Storage를 사용하는 경우 한 번에 100개 이상의 VM을 복제하지 못할 수 있습니다. (BZ#1989527)

    • 이 문제를 해결하려면 스토리지 프로필 매니페스트에서 spec.cloneStrategy: copy 를 설정하여 호스트 지원 사본을 수행할 수 있습니다. 예를 들어 다음과 같습니다.

      apiVersion: cdi.kubevirt.io/v1beta1
      kind: StorageProfile
      metadata:
        name: <provisioner_class>
      #   ...
      spec:
        claimPropertySets:
        - accessModes:
          - ReadWriteOnce
          volumeMode: Filesystem
        cloneStrategy: copy 1
      status:
        provisioner: <provisioner>
        storageClass: <provisioner_class>
      1
      복사 하도록 설정된 기본 복제 방법입니다.
  • 경우에 따라 여러 가상 머신이 동일한 PVC를 읽기-쓰기 모드로 마운트할 수 있으므로 데이터가 손상될 수 있습니다. (BZ#1992753)

    • 이 문제를 해결하려면 여러 VM에서 읽기-쓰기 모드에서 단일 PVC를 사용하지 마십시오.
  • Pod Disruption Budget(PDB)은 Pod가 모호한 가상 머신 이미지에 대한 Pod 중단을 방지합니다. PDB에서 Pod 중단을 감지하면 openshift-monitoringLiveMigrate 제거 전략을 사용하는 가상 머신 이미지에 대해 60분마다 PodDisruptionBudgetAtLimit 경고를 보냅니다. (BZ#2026733)

  • OpenShift Virtualization은 Pod에서 사용하는 서비스 계정 토큰을 해당 특정 포드에 연결합니다. OpenShift Virtualization은 토큰이 포함된 디스크 이미지를 생성하여 서비스 계정 볼륨을 구현합니다. VM을 마이그레이션하는 경우 서비스 계정 볼륨이 잘못되었습니다. (BZ#2037611)

    • 이 문제를 해결하려면 사용자 계정 토큰이 특정 Pod에 바인딩되지 않으므로 서비스 계정 대신 사용자 계정을 사용하십시오.
  • 드라이버를 설치하기 전에 중재 장치를 활성화하도록 HyperConverged CR(사용자 정의 리소스)을 구성하면 새 장치 구성이 적용되지 않습니다. 이 문제는 업데이트를 통해 트리거할 수 있습니다. 예를 들어 NVIDIA 드라이버를 설치하는 daemonset 전에 virt-handler 가 업데이트되면 노드는 가상 머신 GPU를 제공할 수 없습니다. (BZ#2046298)

    • 해결 방법:

      1. HyperConverged CR에서 mediatedDevicesConfigurationpermittedHostDevices 를 제거합니다.
      2. 사용하려는 구성으로 mediatedDevicesConfigurationpermittedHostDevices 스탠자를 모두 업데이트합니다.
  • csi-clone 복제 전략을 사용하여 VM 100개를 복제하는 경우 Ceph CSI에서 복제본을 제거하지 못할 수 있습니다. 복제본을 수동으로 삭제하면 실패할 수도 있습니다. (BZ#2055595)

    • 이 문제를 해결하려면 ceph-mgr 을 다시 시작하여 VM 복제본을 제거할 수 있습니다.

5장. 설치

5.1. OpenShift Virtualization을 위한 클러스터 준비

OpenShift Virtualization을 설치하기 전에 이 섹션을 검토하여 클러스터가 요구 사항을 충족하는지 확인합니다.

중요

사용자 프로비저닝, 설치 관리자 프로비저닝 또는 지원 설치 프로그램을 포함하여 설치 방법을 사용하여 OpenShift Container Platform을 배포할 수 있습니다. 그러나 설치 방법과 클러스터 토폴로지는 스냅샷 또는 실시간 마이그레이션과 같은 OpenShift Virtualization 기능에 영향을 줄 수 있습니다.

단일 노드 OpenShift 차이점

단일 노드 클러스터에 OpenShift Virtualization을 설치할 수 있습니다. 자세한 내용은 단일 노드 OpenShift 정보를 참조하십시오. 단일 노드 OpenShift는 고가용성을 지원하지 않으므로 다음과 같은 차이점이 발생합니다.

FIPS 모드

FIPS 모드에서 클러스터를 설치하는 경우 OpenShift Virtualization에 추가 설정이 필요하지 않습니다.

IPv6

단일 스택 IPv6 클러스터에서는 OpenShift Virtualization을 실행할 수 없습니다. (BZ#2193267)

5.1.1. 하드웨어 및 운영 체제 요구 사항

OpenShift Virtualization에 대한 다음 하드웨어 및 운영 체제 요구 사항을 검토합니다.

지원되는 플랫폼

중요

AWS 베어 메탈 인스턴스에 OpenShift Virtualization을 설치하거나 IBM Cloud Bare Metal Server에 설치하는 것은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

  • 다른 클라우드 공급자가 제공하는 베어 메탈 인스턴스 또는 서버는 지원되지 않습니다.

CPU 요구사항

  • RHEL (Red Hat Enterprise Linux) 8에서 지원
  • Intel 64 또는 AMD64 CPU 확장 지원
  • Intel VT 또는 AMD-V 하드웨어 가상화 확장 기능 활성화
  • NX(실행 없음) 플래그를 사용할 수 있음

스토리지 요구사항

  • OpenShift Container Platform에서 지원
주의

Red Hat OpenShift Data Foundation을 사용하여 OpenShift Virtualization을 배포하는 경우 Windows 가상 머신 디스크용 전용 스토리지 클래스를 생성해야 합니다. 자세한 내용은 Windows VM용 ODF PersistentVolume 최적화 를 참조하십시오.

운영 체제 요구 사항

  • 작업자 노드에 설치된 RHCOS(Red Hat Enterprise Linux CoreOS)

    참고

    RHEL 작업자 노드는 지원되지 않습니다.

  • 클러스터에서 다른 CPU가 있는 작업자 노드를 사용하는 경우 다른 CPU의 기능이 다르기 때문에 실시간 마이그레이션 오류가 발생할 수 있습니다. 이러한 오류를 방지하려면 각 노드에 적절한 용량이 있는 CPU를 사용하고 가상 머신에서 노드 선호도를 설정하여 마이그레이션이 성공적으로 수행됩니다. 자세한 내용은 필수 노드 유사성 규칙 구성을 참조하십시오.

추가 리소스

5.1.2. 물리적 리소스 오버헤드 요구사항

OpenShift Virtualization은 OpenShift Container Platform의 추가 기능이며 클러스터를 계획할 때 고려해야 하는 추가 오버헤드를 적용합니다. 각 클러스터 머신은 OpenShift Container Platform 요구 사항 이외에도 다음과 같은 오버헤드 요구 사항을 충족해야 합니다. 클러스터에서 물리적 리소스를 초과 구독하면 성능에 영향을 미칠 수 있습니다.

중요

이 문서에 명시된 수치는 Red Hat의 테스트 방법론 및 설정을 기반으로 한 것입니다. 고유한 개별 설정 및 환경에 따라 수치가 달라질 수 있습니다.

5.1.2.1. 메모리 오버헤드

아래 식을 사용하여 OpenShift Virtualization의 메모리 오버헤드 값을 계산합니다.

클러스터 메모리 오버헤드

Memory overhead per infrastructure node ≈ 150 MiB

Memory overhead per worker node ≈ 360 MiB

또한, OpenShift Virtualization 환경 리소스에는 모든 인프라 노드에 분산된 총 2179MiB의 RAM이 필요합니다.

가상 머신 메모리 오버헤드

Memory overhead per virtual machine ≈ (1.002 × requested memory) \
              + 216 MiB \ 1
              + 8 MiB × (number of vCPUs) \ 2
              + 16 MiB × (number of graphics devices) \ 3
              + (additional memory overhead) 4

1
virt-launcher Pod에서 실행되는 프로세스에 필요합니다.
2
가상 머신에서 요청한 가상 CPU 수입니다.
3
가상 머신에서 요청한 가상 그래픽 카드 수입니다.
4
추가 메모리 오버헤드:
  • 환경에 SR-IOV(Single Root I/O Virtualization) 네트워크 장치 또는 GPU(Graphics Processing Unit)가 포함된 경우 각 장치에 대해 1GiB의 추가 메모리 오버헤드를 할당합니다.
5.1.2.2. CPU 오버헤드

아래 식을 사용하여 OpenShift Virtualization에 대한 클러스터 프로세서 오버헤드 요구 사항을 계산합니다. 가상 머신당 CPU 오버헤드는 개별 설정에 따라 다릅니다.

클러스터 CPU 오버헤드

CPU overhead for infrastructure nodes ≈ 4 cores

OpenShift Virtualization은 로깅, 라우팅 및 모니터링과 같은 클러스터 수준 서비스의 전반적인 사용률을 높입니다. 이 워크로드를 처리하려면 인프라 구성 요소를 호스팅하는 노드에 4 개의 추가 코어 (4000밀리코어)가 해당 노드에 분산되어 있는지 확인합니다.

CPU overhead for worker nodes ≈ 2 cores + CPU overhead per virtual machine

가상 머신을 호스팅하는 각 작업자 노드는 가상 머신 워크로드에 필요한 CPU 외에도 OpenShift Virtualization 관리 워크로드에 대한 2개의 추가 코어(2000밀리코어)용 용량이 있어야 합니다.

가상 머신 CPU 오버헤드

전용 CPU가 요청되면 클러스터 CPU 오버헤드 요구 사항에 대한 1:1 영향이 있습니다. 그러지 않으면 가상 머신에 필요한 CPU 수에 대한 구체적인 규칙이 없습니다.

5.1.2.3. 스토리지 오버헤드

아래 지침을 사용하여 OpenShift Virtualization 환경에 대한 스토리지 오버헤드 요구 사항을 추정할 수 있습니다.

클러스터 스토리지 오버헤드

Aggregated storage overhead per node ≈ 10 GiB

10GiB는 OpenShift Virtualization을 설치할 때 클러스터의 각 노드에 대해 예상되는 온디스크 스토리지 영향입니다.

가상 머신 스토리지 오버헤드

가상 머신당 스토리지 오버헤드는 가상 머신 내의 리소스 할당 요청에 따라 다릅니다. 이 요청은 클러스터의 다른 위치에서 호스팅되는 노드 또는 스토리지 리소스의 임시 스토리지에 대한 요청일 수 있습니다. 현재 OpenShift Virtualization은 실행 중인 컨테이너 자체에 대한 추가 임시 스토리지를 할당하지 않습니다.

5.1.2.4. 예

클러스터 관리자가 클러스터에서 10개의 가상 머신을 호스팅하는 경우 1GiB RAM과 2개의 vCPU가 장착된 메모리의 클러스터 전체에 대한 영향은 11.68GiB입니다. 클러스터의 각 노드에 대한 디스크 스토리지 영향은 10GiB이며 호스트 가상 머신 워크로드가 최소 2개 코어인 작업자 노드에 대한 CPU 영향은 최소 2개입니다.

5.1.3. 오브젝트 최대값

클러스터를 계획할 때 다음과 같은 테스트된 오브젝트 최대값을 고려해야 합니다.

5.1.4. 제한된 네트워크 환경

인터넷 연결이 없는 제한된 환경에서 OpenShift Virtualization을 설치하는 경우 제한된 네트워크에 대해 Operator Lifecycle Manager를 구성해야 합니다.

인터넷 연결이 제한된 경우 Red Hat 제공 OperatorHub에 액세스하도록 Operator Lifecycle Manager에서 프록시 지원을 구성 할 수 있습니다.

5.1.5. 실시간 마이그레이션

실시간 마이그레이션에는 다음과 같은 요구 사항이 있습니다.

  • RWX( ReadWriteMany ) 액세스 모드를 사용한 공유 스토리지.
  • 충분한 RAM 및 네트워크 대역폭.
  • 가상 머신에서 호스트 모델 CPU를 사용하는 경우 노드에서 가상 머신의 호스트 모델 CPU를 지원해야 합니다.
참고

노드 드레이닝을 지원하기 위해 클러스터에 메모리 요청 용량이 충분한지 확인하여 실시간 마이그레이션을 수행해야 합니다. 다음 계산을 사용하여 필요한 예비 메모리를 확인할 수 있습니다.

Product of (Maximum number of nodes that can drain in parallel) and (Highest total VM memory request allocations across nodes)

  클러스터에서 병렬로 실행할 수 있는 기본 마이그레이션 수는 5입니다.

5.1.6. 스냅샷 및 복제

스냅샷 및 복제 요구 사항은 OpenShift Virtualization 스토리지 기능을 참조하십시오.

5.1.7. 클러스터 고가용성 옵션

클러스터에 대해 다음과 같은 HA(고가용성) 옵션 중 하나를 구성할 수 있습니다.

  • 머신 상태 점검 을 배포하여 설치 관리자 프로비저닝 인프라 (IPI)의 자동 고가용성을 사용할 수 있습니다.

    참고

    설치 관리자 프로비저닝 인프라를 사용하여 설치하고 MachineHealthCheck가 올바르게 구성된 OpenShift Container Platform 클러스터에서는 노드가 MachineHealthCheck에 실패하여 클러스터에서 사용할 수 없게 되는 경우 재활용됩니다. 실패한 노드에서 실행된 VM에서 다음에 수행되는 작업은 일련의 조건에 따라 다릅니다. 잠재적 결과 및 RunStrategies가 결과에 미치는 영향에 대한 자세한 내용은 가상 머신 의 RunStrategies 정보를 참조하십시오.

  • OpenShift Container Platform 클러스터에서 Node Health Check Operator 를 사용하여 IPI 및 비IPI에 대한 자동 고가용성을 사용하여 NodeHealthCheck 컨트롤러를 배포할 수 있습니다. 컨트롤러는 비정상적인 노드를 식별하고 Self Node Remediation Operator를 사용하여 비정상 노드를 수정합니다.

    중요

    Node Health Check Operator는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

    Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

  • 모니터링 시스템 또는 자격을 갖춘 사람이 노드 가용성을 모니터링하는 모든 플랫폼에 대한 고가용성을 사용할 수 있습니다. 노드가 손실되면 노드를 종료하고 oc delete node <lost_node>를 실행합니다.

    참고

    외부 모니터링 시스템 또는 인증된 사용자 모니터링 노드 상태가 없으면 가상 머신의 가용성이 저하됩니다.

5.2. OpenShift Virtualization 구성 요소를 위한 노드 지정

노드 배치 규칙을 구성하여 OpenShift Virtualization Operator, 워크로드 및 컨트롤러를 배포할 노드를 지정합니다.

참고

OpenShift Virtualization을 설치한 후에는 일부 구성 요소에 대한 노드 배치를 구성할 수 있지만, 워크로드에 대한 노드 배치를 구성하려면 가상 머신이 없어야 합니다.

5.2.1. 가상화 구성 요소를 위한 노드 배치 정보

다음이 수행되도록 OpenShift Virtualization이 구성 요소를 배포하는 위치를 사용자 지정하는 것이 좋습니다.

  • 가상 머신은 가상화 워크로드를 위한 노드에만 배포됩니다.
  • Operator는 인프라 노드에만 배포됩니다.
  • 특정 노드는 OpenShift Virtualization의 영향을 받지 않습니다. 예를 들어, 클러스터에서 실행되는 가상화와 관련이 없는 워크로드가 있으며 해당 워크로드가 OpenShift Virtualization과 격리되기를 원하는 경우가 이에 해당합니다.
5.2.1.1. 가상화 구성 요소에 노드 배치 규칙을 적용하는 방법

해당 오브젝트를 직접 편집하거나 웹 콘솔을 사용하여 구성 요소의 노드 배치 규칙을 지정할 수 있습니다.

  • OLM(Operator Lifecycle Manager)이 배포하는 OpenShift Virtualization Operator의 경우, OLM 서브스크립션 오브젝트를 직접 편집합니다. 현재는 웹 콘솔을 사용하여 서브스크립션 오브젝트에 대한 노드 배치 규칙을 구성할 수 없습니다.
  • OpenShift Virtualization Operator가 배포하는 구성 요소의 경우, OpenShift Virtualization 설치 중에 웹 콘솔을 사용하여 HyperConverged 오브젝트를 직접 편집하거나 구성합니다.
  • hostpath 프로비전 프로그램의 경우, HostPathProvisioner 오브젝트를 직접 편집하거나 웹 콘솔을 사용하여 이를 구성합니다.

    주의

    hostpath 프로비전 프로그램과 가상화 구성 요소를 동일한 노드에 예약해야 합니다. 예약하지 않으면 hostpath 프로비전 프로그램을 사용하는 가상화 Pod를 실행할 수 없습니다.

오브젝트에 따라, 다음 규칙 유형 중 하나 이상을 사용할 수 있습니다.

nodeSelector
이 필드에서 지정하는 키-값 쌍으로 라벨이 지정된 노드에 Pod를 예약할 수 있습니다. 노드에는 나열된 모든 쌍과 정확히 일치하는 라벨이 있어야 합니다.
유사성
더 많은 표현 구문을 사용하여 노드와 Pod의 일치 규칙을 설정할 수 있습니다. 유사성을 사용하면 규칙 적용 방법을 보다 자세하게 설정할 수 있습니다. 예를 들어, 규칙을 엄격한 요구 사항이 아닌 기본 설정으로 지정할 수 있으므로 규칙이 충족되지 않은 경우에도 Pod를 예약할 수 있습니다.
허용 오차
일치하는 테인트가 있는 노드에 Pod를 예약할 수 있습니다. 테인트가 노드에 적용되는 경우, 해당 노드는 테인트를 허용하는 Pod만 허용합니다.
5.2.1.2. OLM 서브스크립션 오브젝트에서의 노드 배치

OLM이 OpenShift Virtualization Operator를 배포하는 노드를 지정하려면, OpenShift Virtualization 설치 중에 서브스크립션 오브젝트를 편집합니다. 다음 예와 같이 spec.config 필드에 노드 배치 규칙을 추가할 수 있습니다.

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: hco-operatorhub
  namespace: openshift-cnv
spec:
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  name: kubevirt-hyperconverged
  startingCSV: kubevirt-hyperconverged-operator.v4.11.8
  channel: "stable"
  config: 1
1
config 필드는 nodeSelector허용 오차를 지원하지만 유사성은 지원되지 않습니다.
5.2.1.3. HyperConverged 오브젝트에서의 노드 배치

OpenShift Virtualization이 해당 구성 요소를 배포하는 노드를 지정하려면 OpenShift Virtualization을 설치하는 동안 생성한 HyperConverged Cluster 사용자 정의 리소스(CR) 파일에 nodePlacement 개체를 포함할 수 있습니다. 다음 예와 같이 spec.infraspec.workloads 필드에 nodePlacement를 추가할 수 있습니다.

apiVersion: hco.kubevirt.io/v1beta1
kind: HyperConverged
metadata:
  name: kubevirt-hyperconverged
  namespace: openshift-cnv
spec:
  infra:
    nodePlacement: 1
    ...
  workloads:
    nodePlacement:
    ...
1
The nodePlacement 필드는 nodeSelector,affinitytolerations 필드를 지원합니다.
5.2.1.4. HostPathProvisioner 오브젝트에서의 노드 배치

hostpath 프로비전 프로그램을 설치할 때 생성할 HostPathProvisioner 오브젝트의 spec.workload 필드에 노드 배치 규칙을 구성할 수 있습니다.

apiVersion: hostpathprovisioner.kubevirt.io/v1beta1
kind: HostPathProvisioner
metadata:
  name: hostpath-provisioner
spec:
  imagePullPolicy: IfNotPresent
  pathConfig:
    path: "</path/to/backing/directory>"
    useNamingPrefix: false
  workload: 1
1
워크로드 필드는 nodeSelector, 유사성허용 오차 필드를 지원합니다.
5.2.1.5. 추가 리소스

5.2.2. 예시 매니페스트

다음 예시 YAML 파일은 nodePlacement, affinitytolerations 오브젝트를 사용하여 OpenShift Virtualization 구성 요소를 위한 노드 배치를 사용자 지정합니다.

5.2.2.1. Operator Lifecycle Manager 서브스크립션 오브젝트
5.2.2.1.1. 예: OLM 서브스크립션 오브젝트에서 nodeSelector를 사용한 노드 배치

이 예에서는 example.io/example-infra-key = example-infra-value로 라벨이 지정된 노드에 OLM이 OpenShift Virtualization Operator를 배치하도록 nodeSelector를 구성합니다.

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: hco-operatorhub
  namespace: openshift-cnv
spec:
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  name: kubevirt-hyperconverged
  startingCSV: kubevirt-hyperconverged-operator.v4.11.8
  channel: "stable"
  config:
    nodeSelector:
      example.io/example-infra-key: example-infra-value
5.2.2.1.2. 예: OLM 서브스크립션 오브젝트에서 허용 오차를 사용한 노드 배치

이 예에서는 OpenShift Virtualization Operator를 배포하기 위해 OLM에 예약된 노드가 key=virtualization:NoSchedule 테인트로 라벨이 지정됩니다. 허용 오차가 일치하는 Pod만 이러한 노드에 예약됩니다.

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: hco-operatorhub
  namespace: openshift-cnv
spec:
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  name: kubevirt-hyperconverged
  startingCSV: kubevirt-hyperconverged-operator.v4.11.8
  channel: "stable"
  config:
    tolerations:
    - key: "key"
      operator: "Equal"
      value: "virtualization"
      effect: "NoSchedule"
5.2.2.2. HyperConverged 오브젝트
5.2.2.2.1. 예: HyperConverged Cluster CR에서 nodeSelector를 사용한 노드 배치

이 예에서는 인프라 리소스가 example.io/example-infra-key = example-infra-value로 라벨이 지정된 노드에 배치되고 워크로드가 example.io/example-workloads-key = example-workloads-value로 라벨이 지정된 노드에 배치되도록 nodeSelector가 구성됩니다.

apiVersion: hco.kubevirt.io/v1beta1
kind: HyperConverged
metadata:
  name: kubevirt-hyperconverged
  namespace: openshift-cnv
spec:
  infra:
    nodePlacement:
      nodeSelector:
        example.io/example-infra-key: example-infra-value
  workloads:
    nodePlacement:
      nodeSelector:
        example.io/example-workloads-key: example-workloads-value
5.2.2.2.2. 예: HyperConverged Cluster CR에서 유사성을 사용한 노드 배치

이 예에서는 인프라 리소스가 example.io/example-infra-key = example-value로 라벨이 지정된 노드에 배치되고 워크로드가 example.io/example-workloads-key = example-workloads-value로 라벨이 지정된 노드에 배치되도록 유사성이 구성됩니다. 워크로드에 9개 이상의 CPU를 사용하는 것이 좋지만, 사용할 수 없는 경우에도 Pod가 예약됩니다.

apiVersion: hco.kubevirt.io/v1beta1
kind: HyperConverged
metadata:
  name: kubevirt-hyperconverged
  namespace: openshift-cnv
spec:
  infra:
    nodePlacement:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: example.io/example-infra-key
                operator: In
                values:
                - example-infra-value
  workloads:
    nodePlacement:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: example.io/example-workloads-key
                operator: In
                values:
                - example-workloads-value
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 1
            preference:
              matchExpressions:
              - key: example.io/num-cpus
                operator: Gt
                values:
                - 8
5.2.2.2.3. 예: HyperConverged Cluster CR에서 허용 오차를 사용한 노드 배치

이 예에서는 OpenShift Virtualization 구성 요소를 위해 예약된 노드가 key=virtualization:NoSchedule 테인트로 라벨이 지정됩니다. 허용 오차가 일치하는 Pod만 이러한 노드에 예약됩니다.

apiVersion: hco.kubevirt.io/v1beta1
kind: HyperConverged
metadata:
  name: kubevirt-hyperconverged
  namespace: openshift-cnv
spec:
  workloads:
    nodePlacement:
      tolerations:
      - key: "key"
        operator: "Equal"
        value: "virtualization"
        effect: "NoSchedule"
5.2.2.3. HostPathProvisioner 오브젝트
5.2.2.3.1. 예: HostPathProvisioner 오브젝트에서 nodeSelector를 사용한 노드 배치

이 예에서는 라벨이 example.io/example-workloads-key = example-workloads-value로 지정된 노드에 워크로드가 배치되도록 nodeSelector가 구성됩니다.

apiVersion: hostpathprovisioner.kubevirt.io/v1beta1
kind: HostPathProvisioner
metadata:
  name: hostpath-provisioner
spec:
  imagePullPolicy: IfNotPresent
  pathConfig:
    path: "</path/to/backing/directory>"
    useNamingPrefix: false
  workload:
    nodeSelector:
      example.io/example-workloads-key: example-workloads-value

5.3. 웹 콘솔을 사용한 OpenShift Virtualization 설치

OpenShift Virtualization을 설치하여 OpenShift Container Platform 클러스터에 가상화 기능을 추가합니다.

OpenShift Container Platform 4.11 웹 콘솔 을 사용하여 OpenShift Virtualization Operator를 구독하고 배포할 수 있습니다.

5.3.1. OpenShift Virtualization Operator 설치

OpenShift Virtualization Operator는 OpenShift Container Platform 웹 콘솔을 사용하여 설치할 수 있습니다.

사전 요구 사항

  • 클러스터에 OpenShift Container Platform 4.11을 설치합니다.
  • OpenShift Container Platform 웹 콘솔에 cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

  1. 관리자OperatorOperatorHub를 클릭합니다.
  2. 키워드로 필터링 필드에 가상화를 입력합니다.
  3. Red Hat 소스 라벨을 사용하여 {CNVOperator CryostatName} 타일을 선택합니다.
  4. Operator에 대한 정보를 확인하고 Install을 클릭합니다.
  5. Operator 설치 페이지에서 다음을 수행합니다.

    1. 사용 가능한 업데이트 채널 옵션 목록에서 stable을 선택합니다. 이렇게 하면 OpenShift Container Platform 버전과 호환되는 OpenShift Virtualization 버전을 설치할 수 있습니다.
    2. 설치된 네임스페이스의 경우 Operator 권장 네임스페이스 옵션이 선택되어 있는지 확인합니다. 그러면 필수 openshift-cnv 네임스페이스에 Operator가 설치되고, 해당 네임스페이스가 존재하지 않는 경우 자동으로 생성됩니다.

      주의

      openshift-cnv 이외의 네임스페이스에 OpenShift Virtualization Operator를 설치하려고 하면 설치가 실패합니다.

    3. 승인 전략의 경우 기본값인 자동을 선택하여 OpenShift Virtualization이 안정적인 업데이트 채널에서 새 버전을 사용할 수 있을 때 자동으로 업데이트되도록 하는 것이 좋습니다.

      수동 승인 전략을 선택할 수 있지만 클러스터의 지원 가능성 및 기능에 미칠 위험이 높기 때문에 이 방법은 권장할 수 없습니다. 이러한 위험을 완전히 이해하고 자동을 사용할 수 없는 경우에만 수동을 선택합니다.

      주의

      해당 OpenShift Container Platform 버전과 함께 사용할 때만 OpenShift Virtualization을 지원하므로 누락된 OpenShift Virtualization 업데이트가 없으면 클러스터가 지원되지 않을 수 있습니다.

  6. openshift-cnv 네임스페이스에서 Operator를 사용할 수 있도록 설치를 클릭합니다.
  7. Operator가 설치되면 HyperConverged 생성을 클릭합니다.
  8. 선택 사항: OpenShift Virtualization 구성 요소에 대한 Infra워크로드 노드 배치 옵션을 구성합니다.
  9. 생성을 클릭하여 OpenShift Virtualization을 시작합니다.

검증

  • 워크로드Pods 페이지로 이동하여 모두 실행 중 상태가 될 때까지 OpenShift Virtualization Pod를 모니터링합니다. 모든 Pod에 실행 중 상태가 표시되면 OpenShift Virtualization을 사용할 수 있습니다.

5.3.2. 다음 단계

다음 구성 요소를 추가로 구성하는 것이 좋습니다.

  • hostpath 프로비전 프로그램은 OpenShift Virtualization용으로 설계된 로컬 스토리지 프로비전 프로그램입니다. 가상 머신의 로컬 스토리지를 구성하려면 먼저 hostpath 프로비전 프로그램을 활성화해야 합니다.

5.4. CLI를 사용한 OpenShift Virtualization 설치

OpenShift Virtualization을 설치하여 OpenShift Container Platform 클러스터에 가상화 기능을 추가합니다. 명령줄을 사용하여 OpenShift Virtualization Operator를 구독하고 배포하여 클러스터에 매니페스트를 적용할 수 있습니다.

참고

OpenShift Virtualization에서 구성 요소를 설치할 노드를 지정하려면 노드 배치 규칙을 구성합니다.

5.4.1. 사전 요구 사항

  • 클러스터에 OpenShift Container Platform 4.11을 설치합니다.
  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

5.4.2. CLI를 사용하여 OpenShift Virtualization 카탈로그 구독

OpenShift Virtualization을 설치하기 전에 OpenShift Virtualization 카탈로그를 구독해야 합니다. 구독하면 openshift-cnv 네임스페이스에서 OpenShift Virtualization Operator에 액세스할 수 있습니다.

구독하려면 클러스터에 단일 매니페스트를 적용하여 Namespace, OperatorGroup, Subscription 오브젝트를 구성합니다.

절차

  1. 다음 매니페스트를 포함하는 YAML 파일을 만듭니다.

    apiVersion: v1
    kind: Namespace
    metadata:
      name: openshift-cnv
    ---
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: kubevirt-hyperconverged-group
      namespace: openshift-cnv
    spec:
      targetNamespaces:
        - openshift-cnv
    ---
    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: hco-operatorhub
      namespace: openshift-cnv
    spec:
      source: redhat-operators
      sourceNamespace: openshift-marketplace
      name: kubevirt-hyperconverged
      startingCSV: kubevirt-hyperconverged-operator.v4.11.8
      channel: "stable" 1
    1
    stable 채널을 사용하면 OpenShift Container Platform 버전과 호환되는 OpenShift Virtualization 버전을 설치할 수 있습니다.
  2. 다음 명령을 실행하여 OpenShift Virtualization에 필요한 Namespace, OperatorGroupSubscription 오브젝트를 생성합니다.

    $ oc apply -f <file name>.yaml
참고

YAML 파일에서 인증서 교체 매개 변수를 구성 할 수 있습니다.

5.4.3. CLI를 사용하여 OpenShift Virtualization Operator 배포

oc CLI를 사용하여 OpenShift Virtualization Operator를 배포할 수 있습니다.

사전 요구 사항

  • openshift-cnv 네임스페이스의 OpenShift Virtualization 카탈로그에 대한 구독이 활성 상태여야 합니다.

절차

  1. 다음 매니페스트를 포함하는 YAML 파일을 만듭니다.

    apiVersion: hco.kubevirt.io/v1beta1
    kind: HyperConverged
    metadata:
      name: kubevirt-hyperconverged
      namespace: openshift-cnv
    spec:
  2. 다음 명령을 실행하여 OpenShift Virtualization Operator를 배포합니다.

    $ oc apply -f <file_name>.yaml

검증

  • openshift-cnv 네임스페이스에서 CSV(클러스터 서비스 버전)의 PHASE를 확인하여 OpenShift Virtualization이 성공적으로 배포되었는지 확인합니다. 다음 명령을 실행합니다.

    $ watch oc get csv -n openshift-cnv

    배포에 성공하면 다음 출력이 표시됩니다.

    출력 예

    NAME                                      DISPLAY                    VERSION   REPLACES   PHASE
    kubevirt-hyperconverged-operator.v4.11.8   OpenShift Virtualization   4.11.8                Succeeded

5.4.4. 다음 단계

다음 구성 요소를 추가로 구성하는 것이 좋습니다.

  • hostpath 프로비전 프로그램은 OpenShift Virtualization용으로 설계된 로컬 스토리지 프로비전 프로그램입니다. 가상 머신의 로컬 스토리지를 구성하려면 먼저 hostpath 프로비전 프로그램을 활성화해야 합니다.

5.5. virtctl 클라이언트 활성화

virtctl 클라이언트는 OpenShift Virtualization 리소스를 관리하는 명령줄 유틸리티입니다. Linux, macOS, Windows 배포에 사용할 수 있습니다.

5.5.1. virtctl 클라이언트 다운로드 및 설치

5.5.1.1. virtctl 클라이언트 다운로드

ConsoleCLIDownload CR(사용자 정의 리소스)에 있는 링크를 사용하여 virtctl 클라이언트를 다운로드합니다.

절차

  1. 다음 명령을 실행하여 ConsoleCLIDownload 오브젝트를 확인합니다.

    $ oc get ConsoleCLIDownload virtctl-clidownloads-kubevirt-hyperconverged -o yaml
  2. 배포에 나열된 링크를 사용하여 virtctl 클라이언트를 다운로드합니다.
5.5.1.2. virtctl 클라이언트 설치

운영 체제의 적절한 위치에서 다운로드한 후 virtctl 클라이언트를 추출하고 설치합니다.

사전 요구 사항

  • virtctl 클라이언트를 다운로드해야 합니다.

절차

  • Linux의 경우:

    1. tarball을 추출합니다. 다음 CLI 명령은 tarball과 동일한 디렉터리에 압축을 풉니다.

      $ tar -xvf <virtctl-version-distribution.arch>.tar.gz
    2. 추출된 폴더 계층 구조로 이동하여 다음 명령을 실행하여 virtctl 바이너리를 실행할 수 있도록 합니다.

      $ chmod +x <virtctl-file-name>
    3. virtctl 바이너리를 PATH 환경 변수의 디렉터리로 이동합니다.
    4. 경로를 확인하려면 다음 명령을 실행합니다.

      $ echo $PATH
  • Windows 사용자의 경우:

    1. 아카이브의 압축을 해제하고 압축을 풉니다.
    2. 추출된 폴더 계층 구조로 이동하고 virtctl 실행 파일을 두 번 클릭하여 클라이언트를 설치합니다.
    3. virtctl 바이너리를 PATH 환경 변수의 디렉터리로 이동합니다.
    4. 경로를 확인하려면 다음 명령을 실행합니다.

      C:\> path
  • macOS 사용자의 경우:

    1. 아카이브의 압축을 해제하고 압축을 풉니다.
    2. virtctl 바이너리를 PATH 환경 변수의 디렉터리로 이동합니다.
    3. 경로를 확인하려면 다음 명령을 실행합니다.

      echo $PATH

5.5.2. virtctl RPM 패키지 설치

OpenShift Virtualization 리포지토리를 활성화한 후 virtctl 클라이언트를 RPM으로 설치할 수 있습니다.

5.5.2.1. OpenShift Virtualization 리포지토리 활성화

RHEL(Red Hat Enterprise Linux) 버전에 대해 OpenShift Virtualization 리포지토리를 활성화합니다.

사전 요구 사항

  • "Red Hat Container Native Virtualization" 인타이틀먼트에 대한 활성 서브스크립션이 있는 Red Hat 계정에 시스템이 등록됩니다.

절차

  • subscription-manager CLI 툴을 사용하여 운영 체제에 적합한 OpenShift Virtualization 리포지토리를 활성화합니다.

    • RHEL 8용 리포지토리를 활성화하려면 다음을 실행합니다.

      # subscription-manager repos --enable cnv-4.11-for-rhel-8-x86_64-rpms
    • RHEL 7용 리포지토리를 활성화하려면 다음을 실행합니다.

      # subscription-manager repos --enable rhel-7-server-cnv-4.11-rpms
5.5.2.2. yum 유틸리티를 사용하여 virtctl 클라이언트 설치

kubevirt-virtctl 패키지에서 virtctl 클라이언트를 설치합니다.

사전 요구 사항

  • RHEL(Red Hat Enterprise Linux) 시스템에서 OpenShift Virtualization 리포지토리를 활성화했습니다.

절차

  • kubevirt-virtctl 패키지를 설치합니다.

    # yum install kubevirt-virtctl

5.5.3. 추가 리소스

5.6. OpenShift Virtualization 설치 제거

웹 콘솔 또는 CLI(명령줄 인터페이스)를 사용하여 OpenShift Virtualization을 설치 제거하여 OpenShift Virtualization 워크로드, Operator 및 해당 리소스를 삭제합니다.

5.6.1. 웹 콘솔을 사용하여 OpenShift Virtualization 설치 제거

웹 콘솔을 사용하여 다음 작업을 수행하여 OpenShift Virtualization을 설치 제거합니다.

중요

먼저 모든 가상 머신 ,가상 머신 인스턴스데이터 볼륨을 삭제해야 합니다.

워크로드가 클러스터에 남아 있는 동안 OpenShift Virtualization을 설치 제거할 수 없습니다.

5.6.1.1. HyperConverged 사용자 정의 리소스 삭제

OpenShift Virtualization을 설치 제거하려면 먼저 HyperConverged CR(사용자 정의 리소스)을 삭제합니다.

사전 요구 사항

  • cluster-admin 권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터에 액세스할 수 있습니다.

절차

  1. Operator설치된 Operator 페이지로 이동합니다.
  2. OpenShift Virtualization Operator를 선택합니다.
  3. OpenShift Virtualization 배포 탭을 클릭합니다.
  4. kubevirt-hyperconverged 옆에 있는 옵션 메뉴 kebab 를 클릭하고 HyperConverged 삭제 를 선택합니다.
  5. 확인 창에서 삭제를 클릭합니다.
5.6.1.2. 웹 콘솔을 사용하여 클러스터에서 Operator 삭제

클러스터 관리자는 웹 콘솔을 사용하여 선택한 네임스페이스에서 설치된 Operator를 삭제할 수 있습니다.

사전 요구 사항

  • cluster-admin 권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터 웹 콘솔에 액세스할 수 있습니다.

절차

  1. Operator설치된 Operator 페이지로 이동합니다.
  2. 제거하려는 Operator를 찾으려면 이름으로 필터링 필드에 키워드를 스크롤하거나 입력합니다. 그런 다음 해당 Operator를 클릭합니다.
  3. Operator 세부 정보 페이지 오른쪽에 있는 작업 목록에서 Operator 설치 제거를 선택합니다.

    Operator를 설치 제거하시겠습니까? 대화 상자가 표시됩니다.

  4. 설치 제거를 선택하여 Operator, Operator 배포 및 Pod를 제거합니다. 이 작업 후에 Operator는 실행을 중지하고 더 이상 업데이트가 수신되지 않습니다.

    참고

    이 작업은 CRD(사용자 정의 리소스 정의) 및 CR(사용자 정의 리소스)을 포함하여 Operator에서 관리하는 리소스를 제거하지 않습니다. 웹 콘솔에서 활성화된 대시보드 및 탐색 항목과 계속 실행되는 클러스터 외부 리소스는 수동 정리가 필요할 수 있습니다. Operator를 설치 제거한 후 해당 항목을 제거하려면 Operator CRD를 수동으로 삭제해야 할 수 있습니다.

5.6.1.3. 웹 콘솔을 사용하여 네임스페이스 삭제

OpenShift Container Platform 웹 콘솔을 사용하여 네임스페이스를 삭제할 수 있습니다.

사전 요구 사항

  • cluster-admin 권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터에 액세스할 수 있습니다.

절차

  1. 관리네임스페이스로 이동합니다.
  2. 네임스페이스 목록에서 삭제하려는 네임스페이스를 찾습니다.
  3. 네임스페이스 목록 맨 오른쪽에 있는 옵션 메뉴 kebab 에서 네임스페이스 삭제 를 선택합니다.
  4. 네임스페이스 삭제 창이 열리면 삭제할 네임스페이스 이름을 필드에 입력합니다.
  5. 삭제를 클릭합니다.
5.6.1.4. OpenShift Virtualization 사용자 정의 리소스 정의 삭제

웹 콘솔을 사용하여 OpenShift Virtualization CRD(사용자 정의 리소스 정의)를 삭제할 수 있습니다.

사전 요구 사항

  • cluster-admin 권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터에 액세스할 수 있습니다.

절차

  1. AdministrationCustomResourceDefinitions 로 이동합니다.
  2. Label 필터를 선택하고 검색 필드에 operators.coreos.com/kubevirt-hyperconverged.openshift-cnv 를 입력하여 OpenShift Virtualization CRD를 표시합니다.
  3. 각 CRD 옆에 있는 옵션 메뉴 kebab 를 클릭하고 CustomResourceDefinition 삭제 를 선택합니다.

5.6.2. CLI를 사용하여 OpenShift Virtualization 설치 제거

CLI(명령줄 인터페이스) 를 사용하여 OpenShift Virtualization을 설치 제거할 수 있습니다.

사전 요구 사항

  • cluster-admin 권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터에 액세스할 수 있습니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.
  • 가상 머신,가상 머신 인스턴스, 데이터 볼륨을 모두 삭제했습니다. 워크로드가 클러스터에 남아 있는 동안 OpenShift Virtualization을 설치 제거할 수 없습니다.

절차

  1. HyperConverged 사용자 정의 리소스를 삭제합니다.

    $ oc delete HyperConverged kubevirt-hyperconverged -n openshift-cnv
  2. OpenShift Virtualization Operator 서브스크립션을 삭제합니다.

    $ oc delete subscription kubevirt-hyperconverged -n openshift-cnv
  3. OpenShift Virtualization ClusterServiceVersion 리소스를 삭제합니다.

    $ oc delete csv -n openshift-cnv -l operators.coreos.com/kubevirt-hyperconverged.openshift-cnv
  4. OpenShift Virtualization 네임스페이스를 삭제합니다.

    $ oc delete namespace openshift-cnv
  5. 시험 실행 옵션을 사용하여 oc delete crd 명령을 실행하여 OpenShift Virtualization CRD(사용자 정의 리소스 정의) 를 나열합니다.

    $ oc delete crd --dry-run=client -l operators.coreos.com/kubevirt-hyperconverged.openshift-cnv

    출력 예

    customresourcedefinition.apiextensions.k8s.io "cdis.cdi.kubevirt.io" deleted (dry run)
    customresourcedefinition.apiextensions.k8s.io "hostpathprovisioners.hostpathprovisioner.kubevirt.io" deleted (dry run)
    customresourcedefinition.apiextensions.k8s.io "hyperconvergeds.hco.kubevirt.io" deleted (dry run)
    customresourcedefinition.apiextensions.k8s.io "kubevirts.kubevirt.io" deleted (dry run)
    customresourcedefinition.apiextensions.k8s.io "networkaddonsconfigs.networkaddonsoperator.network.kubevirt.io" deleted (dry run)
    customresourcedefinition.apiextensions.k8s.io "ssps.ssp.kubevirt.io" deleted (dry run)
    customresourcedefinition.apiextensions.k8s.io "tektontasks.tektontasks.kubevirt.io" deleted (dry run)

  6. dry-run 옵션 없이 oc delete crd 명령을 실행하여 CRD를 삭제합니다.

    $ oc delete crd -l operators.coreos.com/kubevirt-hyperconverged.openshift-cnv

6장. OpenShift Virtualization 업데이트

OLM(Operator Lifecycle Manager)에서 OpenShift Virtualization에 z-stream 및 마이너 버전 업데이트를 제공하는 방법을 알아봅니다.

참고
  • Node Maintenance Operator (NMO)는 더 이상 OpenShift Virtualization과 함께 제공되지 않습니다. OpenShift Container Platform 웹 콘솔 OperatorHub 에서 NMO를 설치하거나 OpenShift CLI(oc)를 사용하여 NMO를 설치할 수 있습니다.

    OpenShift Virtualization 4.10.2 이상 릴리스에서 OpenShift Virtualization 4.11로 업데이트하기 전에 다음 작업 중 하나를 수행해야 합니다.

    • 모든 노드를 유지보수 모드에서 이동합니다.
    • 독립 실행형 NMO를 설치하고 nodemaintenances.nodemaintenance.kubevirt.io CR(사용자 정의 리소스)을 nodemaintenances.nodemaintenance.medik8s.io CR로 교체합니다.

6.1. OpenShift Virtualization 업데이트 정보

  • OLM(Operator Lifecycle Manager)은 OpenShift Virtualization Operator의 라이프사이클을 관리합니다. OpenShift Container Platform 설치 중에 배포되는 Marketplace Operator는 클러스터에서 외부 Operator를 사용할 수 있도록 합니다.
  • OLM은 OpenShift Virtualization에 z-stream 및 마이너 버전 업데이트를 제공합니다. OpenShift Container Platform을 다음 마이너 버전으로 업데이트할 때 마이너 버전 업데이트를 사용할 수 있습니다. 먼저 OpenShift Container Platform을 업데이트하지 않고 OpenShift Virtualization을 다음 마이너 버전으로 업데이트할 수 없습니다.
  • OpenShift Virtualization 서브스크립션은 stable 이라는 단일 업데이트 채널을 사용합니다. stable 채널을 사용하면 OpenShift Virtualization 및 OpenShift Container Platform 버전이 호환됩니다.
  • 서브스크립션의 승인 전략이 자동으로 설정된 경우 stable 채널에서 새 버전의 Operator를 사용할 수 있는 즉시 업데이트 프로세스가 시작됩니다. 자동 승인 전략을 사용하여 지원 가능한 환경을 유지하는 것이 좋습니다. OpenShift Virtualization의 각 부 버전은 해당 OpenShift Container Platform 버전을 실행하는 경우에만 지원됩니다. 예를 들어 OpenShift Container Platform 4.11에서 OpenShift Virtualization 4.11을 실행해야 합니다.

    • 수동 승인 전략을 선택할 수 있지만 클러스터의 지원 가능성과 기능에 미칠 위험이 높기 때문에 이 방법은 권장되지 않는 것이 좋습니다. 수동 승인 전략을 사용하면 보류 중인 모든 업데이트를 수동으로 승인해야 합니다. OpenShift Container Platform 및 OpenShift Virtualization 업데이트가 동기화되지 않으면 클러스터가 지원되지 않습니다.
  • 업데이트를 완료하는 데 걸리는 시간은 네트워크 연결에 따라 달라집니다. 대부분의 자동 업데이트는 15분 이내에 완료됩니다.
  • OpenShift Virtualization을 업데이트해도 네트워크 연결이 중단되지 않습니다.
  • 데이터 볼륨 및 관련 영구 볼륨 클레임은 업데이트 중에 유지됩니다.
중요

hostpath 프로비저너 스토리지를 사용하는 가상 머신이 실행 중인 경우 실시간 마이그레이션할 수 없으며 OpenShift Container Platform 클러스터 업데이트를 차단할 수 있습니다.

이 문제를 해결하려면 클러스터를 업데이트하는 동안 전원이 자동으로 꺼지도록 가상 머신을 재구성할 수 있습니다. evictionStrategy: LiveMigrate 필드를 제거하고 runStrategy 필드를 Always로 설정합니다.

6.2. 자동 워크로드 업데이트 구성

6.2.1. 워크로드 업데이트 정보

libvirt,virt-launcher, qemu 를 포함한 OpenShift Virtualization, 가상 머신 워크로드를 업데이트하면 실시간 마이그레이션을 지원하는 경우 자동으로 업데이트됩니다.

참고

각 가상 머신에는 VMI(가상 머신 인스턴스)를 실행하는 virt-launcher Pod가 있습니다. virt-launcher Pod는 libvirt 인스턴스를 실행합니다. 이 인스턴스는 VM(가상 머신) 프로세스를 관리하는 데 사용됩니다.

HyperConverged CR (사용자 정의 리소스)의 spec.workloadUpdateStrategy 스탠자를 편집하여 워크로드가 업데이트되는 방법을 구성할 수 있습니다. 사용 가능한 워크로드 업데이트 방법에는 LiveMigrateEvict 의 두 가지 방법이 있습니다.

Evict 메서드는 VMI Pod를 종료하므로 기본적으로 LiveMigrate 업데이트 전략만 활성화됩니다.

LiveMigrate 가 유일한 업데이트 전략이 활성화된 경우:

  • 실시간 마이그레이션을 지원하는 VMI는 업데이트 프로세스 중에 마이그레이션됩니다. VM 게스트는 업데이트된 구성 요소가 활성화된 새 Pod로 이동합니다.
  • 실시간 마이그레이션을 지원하지 않는 VMI는 중단되거나 업데이트되지 않습니다.

    • VMI에 LiveMigrate 제거 전략이 있지만 실시간 마이그레이션을 지원하지 않는 경우 업데이트되지 않습니다.

LiveMigrateEvict 를 모두 활성화하는 경우 다음을 수행합니다.

  • 실시간 마이그레이션을 지원하는 VMI는 LiveMigrate 업데이트 전략을 사용합니다.
  • 실시간 마이그레이션을 지원하지 않는 VMI는 Evict update 전략을 사용합니다. 항상 runStrategy 값이 있는 VirtualMachine 오브젝트로 VMI를 제어하는 경우 업데이트된 구성 요소가 있는 새 Pod에 새 VMI가 생성됩니다.
마이그레이션 시도 및 타임아웃

워크로드를 업데이트할 때 다음 기간 동안 Pod가 Pending 상태인 경우 실시간 마이그레이션이 실패합니다.

5분
Pod가 예약 불가 때문에 보류 중인 경우
15분
Pod가 어떤 이유로 보류 중 상태인 경우.

VMI가 마이그레이션에 실패하면 virt-controller 에서 다시 마이그레이션을 시도합니다. 모든 migratable VMI가 새 virt-launcher Pod에서 실행될 때까지 이 프로세스를 반복합니다. 그러나 VMI가 부적절하게 구성된 경우 이러한 시도를 무기한 반복할 수 있습니다.

참고

각 시도는 마이그레이션 오브젝트에 해당합니다. 가장 최근의 5개의 시도만 버퍼에 저장됩니다. 이렇게 하면 디버깅 정보를 유지하면서 마이그레이션 오브젝트가 시스템에 누적되지 않습니다.

6.2.2. 워크로드 업데이트 방법 구성

HyperConverged CR(사용자 정의 리소스)을 편집하여 워크로드 업데이트 방법을 구성할 수 있습니다.

사전 요구 사항

  • 실시간 마이그레이션을 업데이트 방법으로 사용하려면 먼저 클러스터에서 실시간 마이그레이션을 활성화해야 합니다.

    참고

    VirtualMachineInstance CR에 evictionStrategy: LiveMigrate 가 포함되어 있고 VMI(가상 머신 인스턴스)가 실시간 마이그레이션을 지원하지 않는 경우 VMI는 업데이트되지 않습니다.

절차

  1. 기본 편집기에서 HyperConverged CR을 열려면 다음 명령을 실행합니다.

    $ oc edit hco -n openshift-cnv kubevirt-hyperconverged
  2. HyperConverged CR의 workloadUpdateStrategy 스탠자를 편집합니다. 예를 들어 다음과 같습니다.

    apiVersion: hco.kubevirt.io/v1beta1
    kind: HyperConverged
    metadata:
      name: kubevirt-hyperconverged
    spec:
      workloadUpdateStrategy:
        workloadUpdateMethods: 1
        - LiveMigrate 2
        - Evict 3
        batchEvictionSize: 10 4
        batchEvictionInterval: "1m0s" 5
    ...
    1
    자동화된 워크로드 업데이트를 수행하는 데 사용할 수 있는 방법입니다. 사용 가능한 값은 LiveMigrateEvict 입니다. 이 예에 표시된 대로 두 옵션을 모두 활성화하면 업데이트에서 실시간 마이그레이션을 지원하지 않는 VMI에 실시간 마이그레이션 및 Evict를 지원하는 VMI에 LiveMigrate를 사용합니다. 자동 워크로드 업데이트를 비활성화하려면 workloadUpdateStrategy 스탠자를 제거하거나 workloadUpdateMethods: [] 를 설정하여 배열을 비워 둘 수 있습니다.
    2
    중단이 적은 업데이트 방법입니다. VMI(가상 머신) 게스트를 업데이트된 구성 요소가 활성화된 새 Pod로 마이그레이션하여 실시간 마이그레이션을 지원하는 VMI가 업데이트됩니다. LiveMigrate가 나열된 유일한 워크로드 업데이트 방법인 경우 실시간 마이그레이션을 지원하지 않는 VMI는 중단되거나 업데이트되지 않습니다.
    3
    업그레이드 중 VMI Pod를 종료하는 중단 방법입니다. Evict는 클러스터에서 실시간 마이그레이션이 활성화되지 않은 경우 사용 가능한 유일한 업데이트 방법입니다. runStrategy: always 구성된 VirtualMachine 오브젝트에서 VMI를 제어하는 경우 업데이트된 구성 요소가 있는 새 VMI가 새 Pod에 생성됩니다.
    4
    Evict 방법을 사용하여 한 번에 업데이트할 수 있는 VMI 수입니다. 이는 LiveMigrate 방법에는 적용되지 않습니다.
    5
    다음 워크로드 배치를 제거하기 전에 대기하는 간격입니다. 이는 LiveMigrate 방법에는 적용되지 않습니다.
    참고

    HyperConverged CR의 spec.liveMigrationConfig 스탠자를 편집하여 실시간 마이그레이션 제한 및 타임아웃을 구성할 수 있습니다.

  3. 변경 사항을 적용하려면 편집기를 저장하고 종료합니다.

6.3. 보류 중인 Operator 업데이트 승인

6.3.1. 보류 중인 Operator 업데이트 수동 승인

설치된 Operator의 서브스크립션에 있는 승인 전략이 수동으로 설정된 경우 새 업데이트가 현재 업데이트 채널에 릴리스될 때 업데이트를 수동으로 승인해야 설치가 시작됩니다.

사전 요구 사항

  • OLM(Operator Lifecycle Manager)을 사용하여 이전에 설치한 Operator입니다.

절차

  1. OpenShift Container Platform 웹 콘솔의 관리자 관점에서 Operator → 설치된 Operator로 이동합니다.
  2. 보류 중인 업데이트가 있는 Operator에 업그레이드 사용 가능 상태가 표시됩니다. 업데이트할 Operator 이름을 클릭합니다.
  3. 서브스크립션 탭을 클릭합니다. 승인이 필요한 업데이트는 업그레이드 상태 옆에 표시됩니다. 예를 들어 1 승인 필요가 표시될 수 있습니다.
  4. 1 승인 필요를 클릭한 다음 설치 계획 프리뷰를 클릭합니다.
  5. 업데이트에 사용할 수 있는 것으로 나열된 리소스를 검토합니다. 문제가 없는 경우 승인을 클릭합니다.
  6. Operator → 설치된 Operator 페이지로 다시 이동하여 업데이트 진행 상황을 모니터링합니다. 완료되면 상태가 성공최신으로 변경됩니다.

6.4. 업데이트 상태 모니터링

6.4.1. OpenShift Virtualization 업그레이드 상태 모니터링

OpenShift Virtualization Operator 업그레이드 상태를 모니터링하려면 CSV(클러스터 서비스 버전) PHASE를 확인합니다. 웹 콘솔에서 또는 여기에 제공된 명령을 실행하여 CSV 조건을 모니터링할 수도 있습니다.

참고

PHASE 및 조건 값은 사용 가능한 정보를 기반으로 한 근사치입니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 로그인합니다.
  • OpenShift CLI(oc)를 설치합니다.

절차

  1. 다음 명령을 실행합니다.

    $ oc get csv -n openshift-cnv
  2. PHASE 필드를 확인하여 출력을 검토합니다. 예를 들면 다음과 같습니다.

    출력 예

    VERSION  REPLACES                                        PHASE
    4.9.0    kubevirt-hyperconverged-operator.v4.8.2         Installing
    4.9.0    kubevirt-hyperconverged-operator.v4.9.0         Replacing

  3. 선택 사항: 다음 명령을 실행하여 모든 OpenShift Virtualization 구성 요소 조건을 집계한 상태를 모니터링합니다.

    $ oc get hco -n openshift-cnv kubevirt-hyperconverged \
    -o=jsonpath='{range .status.conditions[*]}{.type}{"\t"}{.status}{"\t"}{.message}{"\n"}{end}'

    업그레이드가 완료되면 다음과 같은 결과가 나타납니다.

    출력 예

    ReconcileComplete  True  Reconcile completed successfully
    Available          True  Reconcile completed successfully
    Progressing        False Reconcile completed successfully
    Degraded           False Reconcile completed successfully
    Upgradeable        True  Reconcile completed successfully

6.4.2. 오래된 OpenShift Virtualization 워크로드 보기

CLI를 사용하여 오래된 워크로드 목록을 볼 수 있습니다.

참고

클러스터에 오래된 가상화 Pod가 있는 경우 OutdatedVirtualMachineInstanceWorkloads 경고가 실행됩니다.

절차

  • 오래된 VMI(가상 머신 인스턴스) 목록을 보려면 다음 명령을 실행합니다.

    $ oc get vmi -l kubevirt.io/outdatedLauncherImage --all-namespaces
참고

6.5. 추가 리소스

7장. 보안 정책

VM(가상 머신) 워크로드는 권한이 없는 Pod로 실행됩니다. VM에서 OpenShift Virtualization 기능을 사용할 수 있도록 일부 포드에는 다른 Pod 소유자가 사용할 수 없는 사용자 정의 보안 정책이 부여됩니다.

  • 확장된 container_t SELinux 정책은 virt-launcher Pod에 적용됩니다.
  • kubevirt-controller 서비스 계정에 대해 SCC( 보안 컨텍스트 제약 조건 )가 정의됩니다.

7.1. 워크로드 보안 정보

기본적으로 VM(가상 머신) 워크로드는 OpenShift Virtualization에서 루트 권한으로 실행되지 않습니다.

virt-launcher Pod는 각 VM에 대해 세션 모드에서 libvirt 인스턴스를 실행하여 VM 프로세스를 관리합니다. 세션 모드에서 libvirt 데몬은 루트가 아닌 사용자 계정으로 실행되며 동일한 사용자 식별자(UID)에서 실행 중인 클라이언트의 연결만 허용합니다. 따라서 VM은 권한이 없는 Pod로 실행되며 최소 권한의 보안 원칙을 준수합니다.

루트 권한이 필요한 OpenShift Virtualization 기능은 지원되지 않습니다. 기능에 root가 필요한 경우 OpenShift Virtualization에서 사용할 수 없습니다.

7.2. virt-launcher Pod에 대해 확장된 SELinux 정책

virt-launcher Pod에 대한 container_t SELinux 정책은 OpenShift Virtualization의 필수 기능을 사용하도록 확장됩니다.

  • 네트워크 멀티 큐에는 다음 정책이 필요하므로 사용 가능한 vCPU 수가 증가함에 따라 네트워크 성능을 확장할 수 있습니다.

    • allow process self (tun_socket (relabelfrom relabelto attach_queue))
  • 다음 정책을 통해 virt-launcher/proc/cpuinfo/proc / uptime 을 포함하여 /proc 디렉토리 아래에 있는 파일을 읽을 수 있습니다.

    • allow process proc_type (file (getattr open read))
  • 다음 정책을 사용하면 libvirtd 가 네트워크 관련 디버그 메시지를 중계할 수 있습니다.

    • allow process self (netlink_audit_socket (nlmsg_relay))

      참고

      이 정책이 없으면 네트워크 디버그 메시지를 릴레이하는 시도가 차단됩니다. 이렇게 하면 노드의 감사 로그를 SELinux 거부로 채울 수 있습니다.

  • 다음 정책을 사용하면 libvirtd 가 대규모 페이지를 지원하는 데 필요한 hugetblfs 에 액세스할 수 있습니다.

    • allow process hugetlbfs_t (dir (add_name create write remove_name rmdir setattr))
    • allow process hugetlbfs_t (file (create unlink))
  • 다음 정책을 통해 virtiofs 가 파일 시스템을 마운트하고 NFS에 액세스할 수 있습니다.

    • allow process nfs_t(dir(mounton))
    • allow process proc_t (dir) (mounton)
    • allow process proc_t (filesystem (mount unmount))

7.3. kubevirt-controller 서비스 계정에 대한 추가 OpenShift Container Platform 보안 컨텍스트 제약 조건 및 Linux 기능

SCC(보안 컨텍스트 제약 조건)는 Pod에 대한 권한을 제어합니다. 이러한 권한에는 컨테이너 모음인 Pod에서 수행할 수 있는 작업과 액세스할 수 있는 리소스가 포함됩니다. Pod가 시스템에 수용되려면 일련의 조건을 함께 실행해야 하는데, SCC를 사용하여 이러한 조건을 정의할 수 있습니다.

virt-controller 는 클러스터의 가상 머신에 대해 virt-launcher Pod를 생성하는 클러스터 컨트롤러입니다. 이러한 Pod에는 kubevirt-controller 서비스 계정에서 권한이 부여됩니다.

kubevirt-controller 서비스 계정에는 적절한 권한으로 virt-launcher Pod를 생성할 수 있도록 추가 SCC 및 Linux 기능이 부여됩니다. 이러한 확장된 권한을 통해 가상 머신에서 일반적인 Pod의 범위를 벗어나는 OpenShift Virtualization 기능을 사용할 수 있습니다.

kubevirt-controller 서비스 계정에는 다음 SCC가 부여됩니다.

  • scc.AllowHostDirVolumePlugin = true
    이를 통해 가상 머신에서 hostpath 볼륨 플러그인을 사용할 수 있습니다.
  • scc.AllowPrivilegedContainer = false
    virt-launcher Pod가 권한 있는 컨테이너로 실행되지 않습니다.
  • scc.AllowedCapabilities = []corev1.Capability{"SYS_NICE", "NET_BIND_SERVICE", "SYS_PTRACE"}

    • SYS_NICE 를 사용하면 CPU 선호도를 설정할 수 있습니다.
    • NET_BIND_SERVICE 를 사용하면 DHCP 및 Slirp 작업을 수행할 수 있습니다.
    • SYS_PTRACE 를 사용하면 특정 버전의 libvirt 가 소프트웨어 TPM(Trusted Platform Module) 에뮬레이터인 swtpm 의 PID(프로세스 ID)를 찾을 수 있습니다.

7.3.1. kubevirt-controller에 대한 SCC 및 RBAC 정의 보기

oc 툴을 사용하여 kubevirt-controller에 대한 SecurityContextConstraints 정의를 볼 수 있습니다.

$ oc get scc kubevirt-controller -o yaml

oc 툴을 사용하여 kubevirt-controller clusterrole에 대한 RBAC 정의를 볼 수 있습니다.

$ oc get clusterrole kubevirt-controller -o yaml

7.4. 추가 리소스

8장. CLI 툴 사용

다음은 클러스터에서 리소스를 관리하는 데 사용되는 두 가지 기본 CLI 툴입니다.

  • OpenShift Virtualization virtctl 클라이언트
  • OpenShift Container Platform oc 클라이언트

8.1. 사전 요구 사항

8.2. OpenShift Container Platform 클라이언트 명령

OpenShift Container Platform oc 클라이언트는 VirtualMachine(vm) 및 VirtualMachineInstance(vmi) 오브젝트 유형을 포함하여 OpenShift Container Platform 리소스를 관리하는 명령줄 유틸리티입니다.

참고

-n <namespace> 플래그를 사용하여 다른 프로젝트를 지정할 수 있습니다.

표 8.1. oc 명령
명령설명

oc login -u <user_name>

OpenShift Container Platform 클러스터에 <user_name>으로 로그인합니다.

oc get <object_type>

현재 프로젝트에서 지정된 오브젝트 유형의 오브젝트 목록을 표시합니다.

oc describe <object_type> <resource_name>

현재 프로젝트의 특정 리소스에 대한 세부 정보를 표시합니다.

oc create -f <object_config>

파일 이름 또는 stdin에서 현재 프로젝트에 리소스를 만듭니다.

oc edit <object_type> <resource_name>

현재 프로젝트의 리소스를 편집합니다.

oc delete <object_type> <resource_name>

현재 프로젝트의 리소스를 삭제합니다.

oc 클라이언트 명령에 대한 자세한 내용은 OpenShift Container Platform CLI 툴 설명서를 참조하십시오.

8.3. Virtctl 클라이언트 명령

virtctl 클라이언트는 OpenShift Virtualization 리소스를 관리하는 명령줄 유틸리티입니다.

virtctl 명령 목록을 보려면 다음 명령을 실행합니다.

$ virtctl help

특정 명령과 함께 사용할 수 있는 옵션 목록을 보려면 -h 또는 --help 플래그와 함께 실행하십시오. 예를 들어 다음과 같습니다.

$ virtctl image-upload -h

virtctl 명령과 함께 사용할 수 있는 글로벌 명령 옵션 목록을 보려면 다음 명령을 실행합니다.

$ virtctl options

다음 표에는 OpenShift Virtualization 설명서 전체에서 사용되는 virtctl 명령이 포함되어 있습니다.

표 8.2. virtctl 클라이언트 명령
명령설명

virtctl start <vm_name>

가상 머신을 시작합니다.

virtctl start --paused <vm_name>

일시 중지된 상태에서 가상 머신을 시작합니다. 이 옵션을 사용하면 VNC 콘솔에서 부팅 프로세스를 중단할 수 있습니다.

virtctl stop <vm_name>

가상 머신을 중지합니다.

virtctl stop <vm_name> --grace-period 0 --force

가상 머신을 강제 중지합니다. 이 옵션을 사용하면 데이터 불일치 또는 데이터 손실이 발생할 수 있습니다.

virtctl pause vm|vmi <object_name>

가상 머신 또는 가상 머신 인스턴스를 일시 정지합니다. 머신 상태는 메모리에 유지됩니다.

virtctl unpause vm|vmi <object_name>

가상 머신 또는 가상 머신 인스턴스의 일시 정지를 해제합니다.

virtctl migrate <vm_name>

가상 머신을 마이그레이션합니다.

virtctl restart <vm_name>

가상 머신을 재시작합니다.

virtctl expose <vm_name>

가상 머신 또는 가상 머신 인스턴스의 지정된 포트를 전달하고 서비스를 노드의 지정된 포트에 노출하는 서비스를 생성합니다.

virtctl console <vmi_name>

가상 머신 인스턴스의 직렬 콘솔에 연결합니다.

virtctl vnc --kubeconfig=$KUBECONFIG <vmi_name>

가상 머신 인스턴스에 대한 VNC(Virtual Network Client) 연결을 엽니다. 로컬 시스템에 원격 뷰어가 필요한 VNC를 통해 가상 머신 인스턴스의 그래픽 콘솔에 액세스합니다.

virtctl vnc --kubeconfig=$KUBECONFIG --proxy-only=true <vmi-name>

포트 번호를 표시하고 VNC 연결을 통해 뷰어를 사용하여 가상 머신 인스턴스에 수동으로 연결합니다.

virtctl vnc --kubeconfig=$KUBECONFIG --port=<port-number> <vmi-name>

해당 포트를 사용할 수 있는 경우 지정된 포트에서 프록시를 실행할 포트 번호를 지정합니다. 포트 번호를 지정하지 않으면 프록시는 임의의 포트에서 실행됩니다.

virtctl image-upload dv <datavolume_name> --image-path=</path/to/image> --no-create

이미 존재하는 데이터 볼륨에 가상 머신 이미지를 업로드합니다.

virtctl image-upload dv <datavolume_name> --size=<datavolume_size> --image-path=</path/to/image>

가상 머신 이미지를 새 데이터 볼륨에 업로드합니다.

virtctl version

클라이언트 및 서버 버전 정보를 표시합니다.

virtctl fslist <vmi_name>

게스트 머신에서 사용 가능한 전체 파일 시스템 목록을 반환합니다.

virtctl guestosinfo <vmi_name>

운영 체제에 대한 게스트 에이전트 정보를 반환합니다.

virtctl userlist <vmi_name>

게스트 머신에 로그인한 전체 사용자 목록을 반환합니다.

8.4. virtctl guestfs를 사용하여 컨테이너 생성

virtctl guestfs 명령을 사용하여 libguestfs-tools 및 연결된 PVC(영구 볼륨 클레임)를 사용하여 대화형 컨테이너를 배포할 수 있습니다.

절차

  • libguestfs-tools를 사용하여 컨테이너를 배포하려면 PVC를 마운트하고 쉘을 연결하려면 다음 명령을 실행합니다.

    $ virtctl guestfs -n <namespace> <pvc_name> 1
    1
    PVC 이름은 필수 인수입니다. 이를 포함하지 않으면 오류 메시지가 표시됩니다.

8.5. libguestfs 툴 및 virtctl guestfs

Libguestfs 툴을 사용하면 VM(가상 머신) 디스크 이미지에 액세스하고 수정할 수 있습니다. libguestfs 툴을 사용하여 게스트의 파일을 보고 편집하고, 가상 시스템을 복제 및 빌드하며, 디스크를 포맷하고 크기를 조정할 수 있습니다.

virtctl guestfs 명령과 해당 하위 명령을 사용하여 PVC에서 VM 디스크를 수정, 검사 및 디버깅할 수도 있습니다. 가능한 하위 명령의 전체 목록을 보려면 명령줄에 virt- 을 입력하고 Tab 키를 누릅니다. 예를 들어 다음과 같습니다.

명령설명

virt-edit -a /dev/vda /etc/motd

터미널에서 파일을 대화식으로 편집합니다.

virt-customize -a /dev/vda --ssh-inject root:string:<public key example>

ssh 키를 게스트에 삽입하고 로그인을 만듭니다.

virt-df -a /dev/vda -h

VM에서 사용하는 디스크 공간 크기를 확인하십시오.

virt-customize -a /dev/vda --run-command 'rpm -qa > /rpm-list'

전체 목록이 포함된 출력 파일을 생성하여 게스트에 설치된 모든 RPM의 전체 목록을 확인하십시오.

virt-cat -a /dev/vda /rpm-list

터미널에서 virt-customize -a /dev/vda --run-command 'rpm -qa > /rpm-list' 명령을 사용하여 생성된 모든 RPM의 출력 파일 목록을 표시합니다.

virt-sysprep -a /dev/vda

템플릿으로 사용할 가상 시스템 디스크 이미지를 봉인합니다.

기본적으로 virtctl guestfs 는 VM 디스크를 관리하는 데 필요한 모든 내용으로 세션을 생성합니다. 그러나 이 명령은 동작을 사용자 지정하려는 경우 여러 플래그 옵션도 지원합니다.

플래그 옵션설명

--h 또는 --help

guestfs에 대한 도움말을 제공합니다.

<pvc_name> 인수가 있는 -n <namespace> 옵션

특정 네임스페이스에서 PVC를 사용하려면 다음을 수행합니다.

-n <namespace> 옵션을 사용하지 않는 경우 현재 프로젝트가 사용됩니다. 프로젝트를 변경하려면 oc project <namespace>를 사용합니다.

<pvc_name> 인수를 포함하지 않으면 오류 메시지가 표시됩니다.

--image string

libguestfs-tools 컨테이너 이미지를 나열합니다.

--image 옵션을 사용하여 사용자 지정 이미지를 사용하도록 컨테이너를 구성할 수 있습니다.

--kvm

libguestfs-tools 컨테이너에서 kvm이 사용됨을 나타냅니다.

기본적으로 virtctl guestfs는 대화형 컨테이너에 대해 kvm을 설정하므로 QEMU를 사용하기 때문에 libguest-tools 실행 속도가 훨씬 빨라집니다.

클러스터에 kvm 지원 노드가 없는 경우 --kvm=false 옵션을 설정하여 kvm을 비활성화해야 합니다.

설정되지 않은 경우 libguestfs-tools Pod는 모든 노드에서 예약할 수 없으므로 보류 중으로 유지됩니다.

--pull-policy string

libguestfs 이미지의 가져오기 정책을 표시합니다.

pull-policy 옵션을 설정하여 이미지의 가져오기 정책을 덮어쓸 수도 있습니다.

또한 명령은 다른 pod에서 PVC를 사용 중인지 확인합니다. 이 경우 오류 메시지가 표시됩니다. 그러나 libguestfs-tools 프로세스가 시작되면 동일한 PVC를 사용하는 새 Pod를 방지할 수 없습니다. 동일한 PVC에 액세스하는 VM을 시작하기 전에 활성 virtctl guestfs Pod가 없는지 확인해야 합니다.

참고

virtctl guestfs 명령은 대화형 Pod에 연결된 단일 PVC만 허용합니다.

8.6. 추가 리소스

9장. 가상 머신

9.1. 가상 머신 생성

가상 머신을 생성하려면 다음 절차 중 하나를 사용하십시오.

  • 빠른 시작 기능 둘러보기
  • 카탈로그에서빠른 생성
  • 가상 머신 마법사를 사용하여 사전 구성된 YAML 파일 붙여넣기
  • CLI 사용
주의

openshift-* 네임스페이스에 가상 머신을 생성하지 마십시오. 대신 새 네임스페이스를 만들거나 openshift 접두사 없이 기존 네임스페이스를 사용하십시오.

웹 콘솔에서 가상 머신을 생성하는 경우 부팅 소스로 구성된 가상 머신 템플릿을 선택합니다. 부팅 소스가 있는 가상 머신 템플릿은 사용 가능한 부팅 소스로 라벨이 지정되거나 사용자 지정된 라벨 텍스트가 표시됩니다. 사용 가능한 부팅 소스와 함께 템플릿을 사용하면 가상 머신 생성 프로세스가 활성화됩니다.

부팅 소스가 없는 템플릿은 부팅 소스 필요로 라벨이 지정됩니다. 가상 머신에 부팅 소스를 추가하는 단계를 완료하면 이러한 템플릿을 사용할 수 있습니다.

중요

스토리지 동작의 차이로 인해 일부 가상 머신 템플릿은 단일 노드 OpenShift와 호환되지 않습니다. 호환성을 보장하기 위해 데이터 볼륨 또는 스토리지 프로필을 사용하는 템플릿 또는 가상 머신의 evictionStrategy 필드를 설정하지 마십시오.

9.1.1. 빠른 시작을 사용한 가상 머신 생성

웹 콘솔은 가상 머신을 생성하기 위한 명령 기능 둘러보기가 포함된 빠른 시작을 제공합니다. 관리자로 도움말 메뉴를 선택하여 빠른 시작 카탈로그에 액세스할 수 있습니다. 빠른 시작 타일을 클릭하고 둘러보기를 시작할 때 시스템이 프로세스를 안내합니다.

빠른 시작의 작업은 Red Hat 템플릿을 선택하면 시작됩니다. 그런 다음 부팅 소스를 추가하고 운영 체제 이미지를 가져올 수 있습니다. 마지막으로 사용자 지정 템플릿을 저장하고 가상 머신을 생성할 수 있습니다.

사전 요구 사항

  • 운영 체제 이미지의 URL 링크를 다운로드할 수 있는 웹 사이트에 액세스합니다.

절차

  1. 웹 콘솔의 도움말 메뉴에서 빠른 시작을 선택합니다.
  2. 빠른 시작 카탈로그에서 타일을 클릭합니다. 예: Red Hat Linux Enterprise Linux 가상 머신 생성.
  3. 기능 둘러보기의 지침에 따라 운영 체제 이미지를 가져오고 가상 머신을 생성하는 작업을 완료합니다. 가상화VirtualMachines 페이지에 가상 머신이 표시됩니다.

9.1.2. 가상 머신 생성 빠른 생성

사용 가능한 부팅 소스와 함께 템플릿을 사용하여 VM(가상 머신)을 빠르게 생성할 수 있습니다.

절차

  1. 사이드 메뉴에서 가상화카탈로그 를 클릭합니다.
  2. 부팅 소스가 있는 템플릿을 필터링하려면 사용 가능한 부팅 소스를 클릭합니다.

    참고

    기본적으로 템플릿 목록은 기본 템플릿 만 표시합니다. 필터링 시 모든 항목을 클릭하여 선택한 필터에 사용 가능한 모든 템플릿을 확인합니다.

  3. 템플릿을 클릭하여 세부 정보를 확인합니다.
  4. 빠른 생성 VirtualMachine 를 클릭하여 템플릿에서 VM을 생성합니다.

    가상 머신 세부 정보 페이지가 배포 상태와 함께 표시됩니다.

검증

  1. 이벤트를 클릭하여 VM이 프로비저닝될 때 이벤트 스트림을 확인합니다.
  2. 콘솔을 클릭하여 VM이 성공적으로 부팅되었는지 확인합니다.

9.1.3. 사용자 지정된 템플릿에서 가상 머신 생성

일부 템플릿에는 추가 매개변수(예: 부팅 소스가 있는 PVC)가 필요합니다. 템플릿에서 선택한 매개변수를 사용자 지정하여 VM(가상 머신)을 생성할 수 있습니다.

절차

  1. 웹 콘솔에서 템플릿을 선택합니다.

    1. 사이드 메뉴에서 가상화카탈로그 를 클릭합니다.
    2. 선택 사항: 프로젝트, 키워드, 운영 체제 또는 워크로드 프로필로 템플릿을 필터링합니다.
    3. 사용자 지정할 템플릿을 클릭합니다.
  2. Customize VirtualMachine 를 클릭합니다.
  3. NameDisk 소스를 포함하여 VM의 매개변수를 지정합니다. 선택적으로 복제할 데이터 소스를 지정할 수 있습니다.

검증

  1. 이벤트를 클릭하여 VM이 프로비저닝될 때 이벤트 스트림을 확인합니다.
  2. 콘솔을 클릭하여 VM이 성공적으로 부팅되었는지 확인합니다.

웹 콘솔에서 VM을 생성할 때 가상 머신 필드 섹션을 참조하십시오.

9.1.3.1. 가상 머신 필드

다음 표에는 OpenShift Container Platform 웹 콘솔에서 편집할 수 있는 가상 머신 필드가 나열되어 있습니다.

표 9.1. 가상 머신 필드
필드 또는 기능

개요

  • 설명
  • CPU/Memory
  • 부팅 모드
  • GPU 장치
  • 호스트 장치

YAML

  • 사용자 정의 리소스를 보고 편집하거나 다운로드합니다.

스케줄링

  • 노드 선택기
  • 허용 오차
  • 유사성 규칙
  • 전용 리소스
  • 제거 전략
  • Descheduler 설정

환경

  • 구성 맵, 시크릿 또는 서비스 계정을 추가, 편집 또는 삭제합니다.

네트워크 인터페이스

  • 네트워크 인터페이스를 추가, 편집 또는 삭제합니다.

디스크

  • 디스크를 추가, 편집 또는 삭제합니다.

스크립트

  • cloud-init 설정
  • 인증된 SSH 키
  • sysprep 응답 파일

메타데이터

  • 라벨
  • 주석
9.1.3.1.1. 네트워킹 필드
이름설명

이름

네트워크 인터페이스 컨트롤러의 이름입니다.

모델

네트워크 인터페이스 컨트롤러의 모델을 나타냅니다. 지원되는 값은 e1000evirtio입니다.

네트워크

사용 가능한 네트워크 연결 정의 목록입니다.

유형

사용 가능한 바인딩 방법 목록입니다. 네트워크 인터페이스에 적합한 바인딩 방법을 선택합니다.

  • 기본 Pod 네트워크: masquerade
  • Linux 브리지 네트워크: 브리지
  • SR-IOV 네트워크: SR-IOV

MAC 주소

네트워크 인터페이스 컨트롤러의 MAC 주소입니다. MAC 주소를 지정하지 않으면 주소가 자동으로 할당됩니다.

9.1.3.2. 스토리지 필드
이름선택설명

소스

비어있음 (PVC 생성)

빈 디스크를 만듭니다.

URL을 통해 가져오기(PVC 생성)

URL(HTTP 또는 HTTPS 끝점)을 통해 콘텐츠를 가져옵니다.

기존 PVC 사용

클러스터에서 이미 사용 가능한 PVC를 사용합니다.

기존 PVC 복제 (PVC 생성)

클러스터에서 사용 가능한 기존 PVC를 선택하고 복제합니다.

레지스트리를 통해 가져오기(PVC 생성)

컨테이너 레지스트리를 통해 콘텐츠를 가져옵니다.

컨테이너 (임시)

클러스터에서 액세스할 수 있는 레지스트리에 있는 컨테이너에서 콘텐츠를 업로드합니다. 컨테이너 디스크는 CD-ROM 또는 임시 가상 머신과 같은 읽기 전용 파일 시스템에만 사용해야 합니다.

이름

 

디스크 이름입니다. 이름에는 소문자(a-z), 숫자(0-9), 하이픈(-), 마침표(.)가 최대 253자까지 포함될 수 있습니다. 첫 문자와 마지막 문자는 영숫자여야 합니다. 이름에는 대문자, 공백 또는 특수 문자가 포함되어서는 안 됩니다.

크기

 

디스크 크기(GiB)입니다.

유형

 

디스크의 유형입니다. 예: 디스크 또는 CD-ROM

인터페이스

 

디스크 장치의 유형입니다. 지원되는 인터페이스는 virtIO, SATA, SCSI입니다.

스토리지 클래스

 

디스크를 만드는 데 사용되는 스토리지 클래스입니다.

고급 스토리지 설정

다음 고급 스토리지 설정은 선택 사항이며 비어 있는 Blank,URL을 통해 가져오기, 기존 PVC 복제 디스크에 사용할 수 있습니다. OpenShift Virtualization 4.11 이전에는 이러한 매개변수를 지정하지 않으면 kubevirt-storage-class-defaults 구성 맵의 기본값이 사용됩니다. OpenShift Virtualization 4.11 이상에서는 시스템에서 스토리지 프로필 의 기본값을 사용합니다.

참고

OpenShift Virtualization용 스토리지를 프로비저닝할 때 스토리지 프로필을 사용하여 일관된 고급 스토리지 설정을 보장합니다.

볼륨 모드액세스 모드를 수동으로 지정하려면 기본적으로 최적화된 StorageProfile 설정 적용 확인란의 선택을 취소해야 합니다.

이름모드 설명매개변수매개변수 설명

볼륨 모드

영구 볼륨에서 포맷된 파일 시스템을 사용하는지 또는 원시 블록 상태를 사용하는지를 정의합니다. 기본값은 Filesystem입니다.

파일 시스템

파일 시스템 기반 볼륨에 가상 디스크를 저장합니다.

블록

가상 디스크를 블록 볼륨에 직접 저장합니다. 기본 스토리지에서 지원하는 경우에만 Block을 사용하십시오.

액세스 모드

영구 볼륨의 액세스 모드입니다.

ReadWriteOnce (RWO)

볼륨은 단일 노드에서 읽기-쓰기로 마운트할 수 있습니다.

ReadWriteMany (RWX)

볼륨은 한 번에 여러 노드에서 읽기-쓰기로 마운트할 수 있습니다.

참고

이는 가상 머신의 노드 간 실시간 마이그레이션 등 일부 기능에 필요합니다.

ReadOnlyMany (ROX)

볼륨은 여러 노드에서만 읽기로 마운트할 수 있습니다.

9.1.3.3. Cloud-init 필드
이름설명

호스트 이름

가상 머신의 특정 호스트 이름을 설정합니다.

승인된 SSH 키

가상 머신의 ~/.ssh/authorized_keys에 복사되는 사용자의 공개 키입니다.

사용자 정의 스크립트

기타 옵션을 사용자 정의 cloud-init 스크립트를 붙여넣는 필드로 교체합니다.

스토리지 클래스 기본값을 구성하려면 스토리지 프로필을 사용합니다. 자세한 내용은 스토리지 프로필 사용자 지정을 참조하십시오.

9.1.3.4. 사전 구성된 YAML 파일에 붙여넣어 가상 머신 생성

YAML 구성 파일을 쓰거나 붙여넣어 가상 머신을 생성합니다. YAML 편집 화면을 열 때마다 기본적으로 유효한 example 가상 머신 구성이 제공됩니다.

생성을 클릭할 때 YAML 구성이 유효하지 않으면 오류 메시지에 오류가 발생하는 매개변수가 표시됩니다. 한 번에 하나의 오류만 표시됩니다.

참고

편집하는 동안 YAML 화면을 벗어나면 구성 변경 사항이 취소됩니다.

절차

  1. 사이드 메뉴에서 가상화VirtualMachine를 클릭합니다.
  2. 생성을 클릭하고 YAML 사용 을 선택합니다.
  3. 편집 가능한 창에서 가상 머신 구성을 작성하거나 붙여넣습니다.

    1. 또는 YAML 화면에서 기본적으로 제공되는 example 가상 머신을 사용하십시오.
  4. 선택 사항: YAML 구성 파일을 현재 상태로 다운로드하려면 다운로드를 클릭합니다.
  5. 생성을 클릭하여 가상 머신을 생성합니다.

가상 머신이 VirtualMachines 페이지에 나열됩니다.

9.1.4. CLI를 사용하여 가상 머신 생성

virtualMachine 매니페스트에서 가상 머신을 생성할 수 있습니다.

절차

  1. VM의 VirtualMachine 매니페스트를 편집합니다. 예를 들어 다음 매니페스트에서는 RHEL(Red Hat Enterprise Linux) VM을 구성합니다.

    예 9.1. RHEL VM의 매니페스트 예

    apiVersion: kubevirt.io/v1
    kind: VirtualMachine
    metadata:
      labels:
        app: <vm_name> 1
      name: <vm_name>
    spec:
      dataVolumeTemplates:
      - apiVersion: cdi.kubevirt.io/v1beta1
        kind: DataVolume
        metadata:
          name: <vm_name>
        spec:
          sourceRef:
            kind: DataSource
            name: rhel9
            namespace: openshift-virtualization-os-images
          storage:
            resources:
              requests:
                storage: 30Gi
      running: false
      template:
        metadata:
          labels:
            kubevirt.io/domain: <vm_name>
        spec:
          domain:
            cpu:
              cores: 1
              sockets: 2
              threads: 1
            devices:
              disks:
              - disk:
                  bus: virtio
                name: rootdisk
              - disk:
                  bus: virtio
                name: cloudinitdisk
              interfaces:
              - masquerade: {}
                name: default
              rng: {}
            features:
              smm:
                enabled: true
            firmware:
              bootloader:
                efi: {}
            resources:
              requests:
                memory: 8Gi
          evictionStrategy: LiveMigrate
          networks:
          - name: default
            pod: {}
          volumes:
          - dataVolume:
              name: <vm_name>
            name: rootdisk
          - cloudInitNoCloud:
              userData: |-
                #cloud-config
                user: cloud-user
                password: '<password>' 2
                chpasswd: { expire: False }
            name: cloudinitdisk
    1
    가상 머신의 이름을 지정합니다.
    2
    cloud-user의 암호를 지정합니다.
  2. 매니페스트 파일을 사용하여 가상 머신을 생성합니다.

    $ oc create -f <vm_manifest_file>.yaml
  3. 선택 사항: 가상 머신을 시작합니다.

    $ virtctl start <vm_name>

9.1.5. 가상 머신 스토리지 볼륨 유형

스토리지 볼륨 유형설명

임시

네트워크 볼륨을 읽기 전용 백업 저장소로 사용하는 로컬 COW(기록 중 복사) 이미지입니다. 백업 볼륨은 PersistentVolumeClaim이어야 합니다. 임시 이미지는 가상 머신이 시작되고 모든 쓰기를 로컬로 저장할 때 생성됩니다. 임시 이미지는 가상 머신이 중지, 재시작 또는 삭제될 때 삭제됩니다. 백업 볼륨(PVC)은 어떤 식으로든 변경되지 않습니다.

persistentVolumeClaim

사용 가능한 PV를 가상 머신에 연결합니다. PV를 연결하면 세션이 바뀌어도 가상 머신 데이터가 지속됩니다.

기존 가상 머신을 OpenShift Container Platform으로 가져올 때는 CDI를 사용하여 기존 가상 머신 디스크를 PVC로 가져와서 PVC를 가상 머신 인스턴스에 연결하는 것이 좋습니다. PVC 내에서 디스크를 사용하려면 몇 가지 요구 사항이 있습니다.

dataVolume

데이터 볼륨은 가져오기, 복제 또는 업로드 작업을 통해 가상 머신 디스크를 준비하는 프로세스를 관리하여 PersistentVolumeClaim 디스크 유형에 빌드합니다. 이 볼륨 유형을 사용하는 VM은 볼륨이 준비된 후 시작할 수 있습니다.

type: dataVolume 또는 type: ""로 지정합니다. type에 다른 값(예: persistentVolumeClaim)을 지정하면 경고가 표시되고 가상 머신이 시작되지 않습니다.

cloudInitNoCloud

참조된 cloud-init NoCloud 데이터 소스가 포함된 디스크를 연결하여 가상 머신에 사용자 데이터 및 메타데이터를 제공합니다. 가상 머신 디스크 내부에 cloud-init을 설치해야 합니다.

containerDisk

컨테이너 이미지 레지스트리에 저장된 가상 머신 디스크와 같은 이미지를 참조합니다. 이 이미지는 가상 머신이 시작될 때 레지스트리에서 가져와서 가상 머신에 디스크로 연결됩니다.

containerDisk 볼륨은 단일 가상 머신에 국한되지 않으며, 영구 스토리지가 필요하지 않은 다수의 가상 머신 클론을 생성하는 데 유용합니다.

컨테이너 이미지 레지스트리에는 RAW 및 QCOW2 형식의 디스크 유형만 지원됩니다. 이미지 크기를 줄이기 위해 QCOW2를 사용하는 것이 좋습니다.

참고

containerDisk는 임시 볼륨입니다. 이 볼륨은 가상 머신이 중지, 재시작 또는 삭제될 때 삭제됩니다. containerDisk 볼륨은 CD-ROM과 같은 읽기 전용 파일 시스템이나 일회용 가상 머신에 유용합니다.

emptyDisk

가상 머신 인터페이스의 라이프사이클에 연결된 추가 스파스(sparse) QCOW2 디스크를 생성합니다. 해당 데이터는 가상 머신에서 게스트가 시작한 재부팅 후에는 유지되지만 가상 머신이 중지되거나 웹 콘솔에서 재시작되면 삭제됩니다. 빈 디스크는 임시 디스크의 제한된 임시 파일 시스템 크기를 초과하지 않도록 애플리케이션 종속성 및 데이터를 저장하는 데 사용됩니다.

디스크 용량 크기도 제공해야 합니다.

9.1.6. 가상 머신 RunStrategies 정보

가상 머신에 대한 RunStrategy는 일련의 조건에 따라 VMI(가상 머신 인스턴스)의 동작을 결정합니다. spec.runStrategy 설정은 spec.running 설정의 대안으로, 가상 머신 구성 프로세스 내에 있습니다. spec.runStrategy 설정을 사용하면 true 또는 false 응답만 있는 spec.running 설정과 달리 VMI를 만들고 관리하는 방법에 대한 유연성을 높일 수 있습니다. 그러나 두 설정은 함께 사용할 수 없습니다. spec.running 또는 spec.runStrategy 중 하나만 사용할 수 있습니다. 둘 다 사용하면 오류가 발생합니다.

RunStrategies는 다음과 같이 네 가지로 정의되어 있습니다.

Always
가상 머신이 생성될 때 VMI가 항상 존재합니다. 어떠한 이유로 원본이 중지되면 새 VMI가 생성되는데, 이러한 동작은 spec.running: true와 동일합니다.
RerunOnFailure
오류로 인해 이전 인스턴스가 실패하면 VMI가 다시 생성됩니다. 가상 머신이 종료될 때와 같이 성공적으로 중지되면 인스턴스가 다시 생성되지 않습니다.
Manual
start, stop, restart virtctl 클라이언트 명령을 사용하여 VMI의 상태 및 존재를 제어할 수 있습니다.
Halted
가상 머신이 생성될 때 VMI가 존재하지 않으며 이 동작은 spec.running: false와 동일합니다.

start, stop, restart virtctl 명령의 다양한 조합은 사용되는 RunStrategy에 영향을 미칩니다.

다음 표에는 다양한 상태에 따른 VM 전환이 표시되어 있습니다. 첫 번째 열에는 VM의 초기 RunStrategy가 표시되어 있습니다. 각 추가 열에는 virtctl 명령과 해당 명령이 실행된 후의 새 RunStrategy가 표시되어 있습니다.

초기 RunStrategy시작중지재시작

Always

-

Halted

Always

RerunOnFailure

-

Halted

RerunOnFailure

Manual

Manual

Manual

Manual

Halted

Always

-

-

참고

설치 관리자 프로비저닝 인프라를 사용하여 설치한 OpenShift Virtualization 클러스터에서 노드가 MachineHealthCheck에 실패하여 클러스터에서 노드를 사용할 수 없는 경우, 새 노드에 RunStrategy가 Always 또는 RerunOnFailure인 VM이 다시 예약됩니다.

apiVersion: kubevirt.io/v1
kind: VirtualMachine
spec:
  RunStrategy: Always 1
  template:
...
1
VMI의 현재 RunStrategy 설정입니다.

9.1.7. 추가 리소스

9.2. 가상 머신 편집

웹 콘솔의 YAML 편집기를 사용하거나 명령줄에서 OpenShift CLI를 사용하여 가상 머신 구성을 업데이트할 수 있습니다. 가상 머신 세부 정보에서 매개변수 서브 세트를 업데이트할 수도 있습니다.

9.2.1. 웹 콘솔에서 가상 머신 편집

관련 필드 옆에 있는 연필 아이콘을 클릭하여 웹 콘솔에서 가상 머신에 대해 선택된 값을 편집합니다. CLI를 사용하여 다른 값을 편집할 수 있습니다.

Red Hat에서 제공하는 템플릿을 포함하여 모든 템플릿의 레이블 및 주석을 편집할 수 있습니다. 사용자 사용자 지정 템플릿에 대해서만 다른 필드를 편집할 수 있습니다.

절차

  1. 사이드 메뉴에서 가상화VirtualMachine를 클릭합니다.
  2. 선택 사항: 필터 드롭다운 메뉴를 사용하여 상태, 템플릿, 노드 또는 운영 체제(OS)와 같은 속성별로 가상 머신 목록을 정렬합니다.
  3. 가상 머신을 선택하여 VirtualMachine 세부 정보 페이지를 엽니다.
  4. 필드를 편집할 수 있음을 나타내는 연필 아이콘이 있는 필드를 클릭합니다. 예를 들어 BIOS 또는 UEFI와 같은 현재 부팅 모드 설정을 클릭하여 부팅 모드 창을 열고 목록에서 옵션을 선택합니다.
  5. 관련 사항을 변경하고 저장을 클릭합니다.
참고

가상 머신이 실행 중인 경우 가상 머신을 재시작해야 Boot Order 또는 Flavor에 대한 변경 사항이 적용됩니다.

관련 필드의 오른쪽에서 보류 중인 변경 사항 보기를 클릭하여 보류 중인 변경 사항을 볼 수 있습니다. 페이지 상단의 보류 중인 변경 사항 배너에는 가상 머신이 재시작될 때 적용되는 모든 변경 사항 목록이 표시됩니다.

9.2.1.1. 가상 머신 필드

다음 표에는 OpenShift Container Platform 웹 콘솔에서 편집할 수 있는 가상 머신 필드가 나열되어 있습니다.

표 9.2. 가상 머신 필드
필드 또는 기능

세부 정보

  • 라벨
  • 주석
  • 설명
  • CPU/Memory
  • 부팅 모드
  • 부팅 순서
  • GPU 장치
  • 호스트 장치
  • SSH 액세스

YAML

  • 사용자 정의 리소스를 보고 편집하거나 다운로드합니다.

스케줄링

  • 노드 선택기
  • 허용 오차
  • 유사성 규칙
  • 전용 리소스
  • 제거 전략
  • Descheduler 설정

네트워크 인터페이스

  • 네트워크 인터페이스를 추가, 편집 또는 삭제합니다.

디스크

  • 디스크를 추가, 편집 또는 삭제합니다.

스크립트

  • cloud-init 설정

스냅샷

  • 가상 머신 스냅샷을 추가, 복원 또는 삭제합니다.

9.2.2. 웹 콘솔을 사용하여 가상 머신 YAML 구성 편집

웹 콘솔에서 가상 머신의 YAML 구성을 편집할 수 있습니다. 일부 매개변수는 수정할 수 없습니다. 구성이 유효하지 않은 상태에서 저장을 클릭하면 해당 매개변수를 변경할 수 없다는 오류 메시지가 표시됩니다.

참고

편집하는 동안 YAML 화면을 벗어나면 구성 변경 사항이 취소됩니다.

절차

  1. 사이드 메뉴에서 가상화VirtualMachine를 클릭합니다.
  2. 가상 머신을 선택합니다.
  3. YAML 탭을 클릭하여 편집 가능한 구성을 표시합니다.
  4. 선택 사항: 다운로드를 클릭하여 YAML 파일을 현재 상태에서 로컬로 다운로드할 수 있습니다.
  5. 파일을 편집하고 저장을 클릭합니다.

확인 메시지는 수정이 완료되었음을 나타내며 오브젝트의 업데이트된 버전 번호를 포함합니다.

9.2.3. CLI를 사용하여 가상 머신 YAML 구성 편집

CLI를 사용하여 가상 머신 YAML 구성을 편집하려면 다음 절차를 사용하십시오.

사전 요구 사항

  • YAML 오브젝트 구성 파일을 사용하여 가상 머신을 구성했습니다.
  • oc CLI를 설치했습니다.

절차

  1. 다음 명령을 실행하여 가상 머신 구성을 업데이트합니다.

    $ oc edit <object_type> <object_ID>
  2. 오브젝트 구성을 엽니다.
  3. YAML을 편집합니다.
  4. 실행 중인 가상 머신을 편집하는 경우 다음 중 하나를 수행해야 합니다.

    • 가상 머신을 재시작합니다.
    • 새 구성을 적용하려면 다음 명령을 실행합니다.

      $ oc apply <object_type> <object_ID>

9.2.4. 가상 머신에 가상 디스크 추가

가상 디스크를 가상 머신에 추가하려면 다음 절차를 사용하십시오.

절차

  1. 사이드 메뉴에서 가상화VirtualMachine를 클릭합니다.
  2. 가상 머신을 선택하여 VirtualMachine 세부 정보 화면을 엽니다.
  3. 디스크 탭을 클릭한 다음 디스크 추가를 클릭합니다.
  4. 디스크 추가 창에서 소스 ,이름 , 크기,유형,인터페이스스토리지 클래스를 지정합니다.

    1. 선택 사항: 빈 디스크 소스를 사용하고 데이터 볼륨을 생성할 때 최대 쓰기 성능이 필요한 경우 사전 할당을 활성화할 수 있습니다. 이를 수행하려면 사전 할당 활성화 확인란을 선택합니다.
    2. 선택 사항: 최적화된 StorageProfile 설정을 지워 지워 가상 디스크의 볼륨 모드액세스 모드 를 변경할 수 있습니다. 이러한 매개변수를 지정하지 않으면 kubevirt-storage-class-defaults 구성 맵의 기본값이 사용됩니다.
  5. 추가를 클릭합니다.
참고

가상 머신이 실행 중인 경우 새 디스크는 재시작 보류 상태에 있으며, 가상 머신을 재시작할 때까지 연결되지 않습니다.

페이지 상단의 보류 중인 변경 사항 배너에는 가상 머신이 재시작될 때 적용되는 모든 변경 사항 목록이 표시됩니다.

스토리지 클래스 기본값을 구성하려면 스토리지 프로필을 사용합니다. 자세한 내용은 스토리지 프로필 사용자 지정을 참조하십시오.

9.2.4.1. VirtualMachines의 CD-ROM 편집

가상 머신을 위한 CD-ROM을 편집하려면 다음 절차를 사용하십시오.

절차

  1. 사이드 메뉴에서 가상화VirtualMachine를 클릭합니다.
  2. 가상 머신을 선택하여 VirtualMachine 세부 정보 화면을 엽니다.
  3. 디스크 탭을 클릭합니다.
  4. 편집하려는 CD-ROM의 옵션 메뉴 kebab 를 클릭하고 편집을 선택합니다.
  5. CD-ROM 편집 창에서 소스, 영구 볼륨 클레임, 이름, 유형인터페이스 필드를 편집합니다.
  6. 저장을 클릭합니다.
9.2.4.2. 스토리지 필드
이름선택설명

소스

비어있음 (PVC 생성)

빈 디스크를 만듭니다.

URL을 통해 가져오기(PVC 생성)

URL(HTTP 또는 HTTPS 끝점)을 통해 콘텐츠를 가져옵니다.

기존 PVC 사용

클러스터에서 이미 사용 가능한 PVC를 사용합니다.

기존 PVC 복제 (PVC 생성)

클러스터에서 사용 가능한 기존 PVC를 선택하고 복제합니다.

레지스트리를 통해 가져오기(PVC 생성)

컨테이너 레지스트리를 통해 콘텐츠를 가져옵니다.

컨테이너 (임시)

클러스터에서 액세스할 수 있는 레지스트리에 있는 컨테이너에서 콘텐츠를 업로드합니다. 컨테이너 디스크는 CD-ROM 또는 임시 가상 머신과 같은 읽기 전용 파일 시스템에만 사용해야 합니다.

이름

 

디스크 이름입니다. 이름에는 소문자(a-z), 숫자(0-9), 하이픈(-), 마침표(.)가 최대 253자까지 포함될 수 있습니다. 첫 문자와 마지막 문자는 영숫자여야 합니다. 이름에는 대문자, 공백 또는 특수 문자가 포함되어서는 안 됩니다.

크기

 

디스크 크기(GiB)입니다.

유형

 

디스크의 유형입니다. 예: 디스크 또는 CD-ROM

인터페이스

 

디스크 장치의 유형입니다. 지원되는 인터페이스는 virtIO, SATA, SCSI입니다.

스토리지 클래스

 

디스크를 만드는 데 사용되는 스토리지 클래스입니다.

고급 스토리지 설정

다음 고급 스토리지 설정은 선택 사항이며 비어 있는 Blank,URL을 통해 가져오기, 기존 PVC 복제 디스크에 사용할 수 있습니다. OpenShift Virtualization 4.11 이전에는 이러한 매개변수를 지정하지 않으면 kubevirt-storage-class-defaults 구성 맵의 기본값이 사용됩니다. OpenShift Virtualization 4.11 이상에서는 시스템에서 스토리지 프로필 의 기본값을 사용합니다.

참고

OpenShift Virtualization용 스토리지를 프로비저닝할 때 스토리지 프로필을 사용하여 일관된 고급 스토리지 설정을 보장합니다.

볼륨 모드액세스 모드를 수동으로 지정하려면 기본적으로 최적화된 StorageProfile 설정 적용 확인란의 선택을 취소해야 합니다.

이름모드 설명매개변수매개변수 설명

볼륨 모드

영구 볼륨에서 포맷된 파일 시스템을 사용하는지 또는 원시 블록 상태를 사용하는지를 정의합니다. 기본값은 Filesystem입니다.

파일 시스템

파일 시스템 기반 볼륨에 가상 디스크를 저장합니다.

블록

가상 디스크를 블록 볼륨에 직접 저장합니다. 기본 스토리지에서 지원하는 경우에만 Block을 사용하십시오.

액세스 모드

영구 볼륨의 액세스 모드입니다.

ReadWriteOnce (RWO)

볼륨은 단일 노드에서 읽기-쓰기로 마운트할 수 있습니다.

ReadWriteMany (RWX)

볼륨은 한 번에 여러 노드에서 읽기-쓰기로 마운트할 수 있습니다.

참고

이는 가상 머신의 노드 간 실시간 마이그레이션 등 일부 기능에 필요합니다.

ReadOnlyMany (ROX)

볼륨은 여러 노드에서만 읽기로 마운트할 수 있습니다.

9.2.5. 가상 머신에 네트워크 인터페이스 추가

가상 머신에 네트워크 인터페이스를 추가하려면 다음 절차를 사용하십시오.

절차

  1. 사이드 메뉴에서 가상화VirtualMachine를 클릭합니다.
  2. 가상 머신을 선택하여 VirtualMachine 세부 정보 화면을 엽니다.
  3. 네트워크 인터페이스 탭을 클릭합니다.
  4. 네트워크 인터페이스 추가를 클릭합니다.
  5. 네트워크 인터페이스 추가 창에서 네트워크 인터페이스의 이름, 모델, 네트워크, 유형, MAC 주소를 지정합니다.
  6. 추가를 클릭합니다.
참고

가상 머신이 실행 중인 경우 새 네트워크 인터페이스는 재시작 보류 상태에 있으며, 가상 머신을 재시작할 때까지 변경 사항이 적용되지 않습니다.

페이지 상단의 보류 중인 변경 사항 배너에는 가상 머신이 재시작될 때 적용되는 모든 변경 사항 목록이 표시됩니다.

9.2.5.1. 네트워킹 필드
이름설명

이름

네트워크 인터페이스 컨트롤러의 이름입니다.

모델

네트워크 인터페이스 컨트롤러의 모델을 나타냅니다. 지원되는 값은 e1000evirtio입니다.

네트워크

사용 가능한 네트워크 연결 정의 목록입니다.

유형

사용 가능한 바인딩 방법 목록입니다. 네트워크 인터페이스에 적합한 바인딩 방법을 선택합니다.

  • 기본 Pod 네트워크: masquerade
  • Linux 브리지 네트워크: 브리지
  • SR-IOV 네트워크: SR-IOV

MAC 주소

네트워크 인터페이스 컨트롤러의 MAC 주소입니다. MAC 주소를 지정하지 않으면 주소가 자동으로 할당됩니다.

9.2.6. 추가 리소스

9.3. 부팅 순서 편집

웹 콘솔 또는 CLI를 사용하여 부팅 순서 목록 값을 업데이트할 수 있습니다.

가상 머신 개요 페이지의 부팅 순서를 사용하여 다음을 수행할 수 있습니다.

  • 디스크 또는 NIC(네트워크 인터페이스 컨트롤러)를 선택하고 부팅 순서 목록에 추가합니다.
  • 부팅 순서 목록에서 디스크 또는 NIC 순서를 편집합니다.
  • 부팅 순서 목록에서 디스크 또는 NIC를 제거하고 부팅 가능 소스 인벤토리로 반환합니다.

9.3.1. 웹 콘솔에서 부팅 순서 목록에 항목 추가

웹 콘솔을 사용하여 부팅 순서 목록에 항목을 추가합니다.

절차

  1. 사이드 메뉴에서 가상화VirtualMachine를 클릭합니다.
  2. 가상 머신을 선택하여 VirtualMachine 세부 정보 페이지를 엽니다.
  3. 세부 정보 탭을 클릭합니다.
  4. 부팅 순서 오른쪽에 있는 연필 아이콘을 클릭합니다. YAML 구성이 존재하지 않거나 처음으로 부팅 순서 목록을 생성하는 경우 다음 메시지가 표시됩니다. 선택된 리소스가 없습니다. VM은 YAML 파일에 나타나는 순서에 따라 디스크에서 부팅하려고 합니다.
  5. 소스 추가를 클릭하고 가상 시스템의 부팅 가능한 디스크 또는 NIC(네트워크 인터페이스 컨트롤러)를 선택합니다.
  6. 부팅 순서 목록에 추가 디스크 또는 NIC를 추가합니다.
  7. 저장을 클릭합니다.
참고

가상 머신이 실행 중인 경우 가상 머신을 재시작해야 Boot Order 변경 사항이 적용됩니다.

부팅 순서 필드 오른쪽에 있는 보류 중인 변경 사항 보기를 클릭하면 보류 중인 변경 사항을 볼 수 있습니다. 페이지 상단의 보류 중인 변경 사항 배너에는 가상 머신이 재시작될 때 적용되는 모든 변경 사항 목록이 표시됩니다.

9.3.2. 웹 콘솔에서 부팅 순서 목록 편집

웹 콘솔에서 부팅 순서 목록을 편집합니다.

절차

  1. 사이드 메뉴에서 가상화VirtualMachine를 클릭합니다.
  2. 가상 머신을 선택하여 VirtualMachine 세부 정보 페이지를 엽니다.
  3. 세부 정보 탭을 클릭합니다.
  4. 부팅 순서 오른쪽에 있는 연필 아이콘을 클릭합니다.
  5. 부팅 순서 목록에서 항목을 이동하는 적절한 방법을 선택합니다.

    • 화면 판독기를 사용하지 않는 경우 이동할 항목 옆에 있는 화살표 아이콘 위로 마우스를 가져가서 항목을 위 또는 아래로 끌어 원하는 위치에 놓습니다.
    • 화면 판독기를 사용하는 경우 위쪽 화살표 키 또는 아래쪽 화살표 키를 눌러 부팅 순서 목록에서 항목을 이동합니다. 그런 다음 Tab 키를 눌러 원하는 위치에 항목을 놓습니다.
  6. 저장을 클릭합니다.
참고

가상 머신이 실행중인 경우 가상 머신을 재시작해야 부팅 순서 목록의 변경 사항이 적용됩니다.

부팅 순서 필드 오른쪽에 있는 보류 중인 변경 사항 보기를 클릭하면 보류 중인 변경 사항을 볼 수 있습니다. 페이지 상단의 보류 중인 변경 사항 배너에는 가상 머신이 재시작될 때 적용되는 모든 변경 사항 목록이 표시됩니다.

9.3.3. YAML 구성 파일의 부팅 순서 목록 편집

CLI를 사용하여 YAML 구성 파일의 부팅 순서 목록을 편집합니다.

절차

  1. 다음 명령을 실행하여 가상 머신의 YAML 구성 파일을 엽니다.

    $ oc edit vm example
  2. YAML 파일을 편집하고 디스크 또는 NIC(네트워크 인터페이스 컨트롤러)와 연결된 부팅 순서 값을 수정합니다. 예를 들어 다음과 같습니다.

    disks:
      - bootOrder: 1 1
        disk:
          bus: virtio
        name: containerdisk
      - disk:
          bus: virtio
        name: cloudinitdisk
      - cdrom:
          bus: virtio
        name: cd-drive-1
    interfaces:
      - boot Order: 2 2
        macAddress: '02:96:c4:00:00'
        masquerade: {}
        name: default
    1
    디스크에 지정된 부팅 순서 값입니다.
    2
    네트워크 인터페이스 컨트롤러에 지정된 부팅 순서 값입니다.
  3. YAML 파일을 저장합니다.
  4. 컨텐츠 다시 로드를 클릭하여 YAML 파일의 업데이트된 부팅 순서 값을 웹 콘솔의 부팅 순서 목록에 적용합니다.

9.3.4. 웹 콘솔의 부팅 순서 목록에서 항목 제거

웹 콘솔을 사용하여 부팅 순서 목록에서 항목을 제거합니다.

절차

  1. 사이드 메뉴에서 가상화VirtualMachine를 클릭합니다.
  2. 가상 머신을 선택하여 VirtualMachine 세부 정보 페이지를 엽니다.
  3. 세부 정보 탭을 클릭합니다.
  4. 부팅 순서 오른쪽에 있는 연필 아이콘을 클릭합니다.
  5. 해당 항목 옆에 있는 제거 아이콘 delete 을 클릭합니다. 항목이 부팅 순서 목록에서 제거되고 사용 가능한 부팅 소스 목록에 저장됩니다. 부팅 순서 목록의 모든 항목을 제거하면 다음 메시지가 표시됩니다. 선택된 리소스가 없습니다. VM은 YAML 파일에 나타나는 순서에 따라 디스크에서 부팅하려고 합니다.
참고

가상 머신이 실행 중인 경우 가상 머신을 재시작해야 Boot Order 변경 사항이 적용됩니다.

부팅 순서 필드 오른쪽에 있는 보류 중인 변경 사항 보기를 클릭하면 보류 중인 변경 사항을 볼 수 있습니다. 페이지 상단의 보류 중인 변경 사항 배너에는 가상 머신이 재시작될 때 적용되는 모든 변경 사항 목록이 표시됩니다.

9.4. 가상 머신 삭제

웹 콘솔에서 또는 oc 명령줄 인터페이스를 사용하여 가상 머신을 삭제할 수 있습니다.

9.4.1. 웹 콘솔을 사용하여 가상 머신 삭제

가상 머신을 삭제하면 클러스터에서 가상 머신이 영구적으로 제거됩니다.

참고

가상 머신을 삭제하면 사용하는 데이터 볼륨이 자동으로 삭제됩니다.

절차

  1. OpenShift Container Platform 콘솔 의 사이드 메뉴에서 가상화 → VirtualMachine 를 클릭합니다.
  2. 삭제할 가상 머신의 옵션 메뉴 kebab 를 클릭하고 삭제 를 선택합니다.

    • 또는 가상 머신 이름을 클릭하여 VirtualMachine 세부 정보 페이지를 열고 작업삭제 를 클릭합니다.
  3. 확인 팝업 창에서 삭제를 클릭하여 가상 머신을 영구적으로 삭제합니다.

9.4.2. CLI를 사용하여 가상 머신 삭제

oc CLI(명령줄 인터페이스)를 사용하여 가상 머신을 삭제할 수 있습니다. oc 클라이언트를 사용하면 여러 가상 머신에서 작업을 수행할 수 있습니다.

참고

가상 머신을 삭제하면 사용하는 데이터 볼륨이 자동으로 삭제됩니다.

사전 요구 사항

  • 삭제할 가상 머신의 이름을 확인합니다.

절차

  • 다음 명령을 실행하여 가상 머신을 삭제합니다.

    $ oc delete vm <vm_name>
    참고

    이 명령은 현재 프로젝트에 존재하는 오브젝트만 삭제합니다. 삭제하려는 오브젝트가 다른 프로젝트 또는 네임스페이스에 있는 경우 -n <project_name> 옵션을 지정하십시오.

9.5. 가상 머신 인스턴스 관리

OpenShift Virtualization 환경 외부에서 독립적으로 생성된 독립 실행형 VMI(가상 머신 인스턴스)가 있는 경우 웹 콘솔을 사용하거나 CLI(명령줄 인터페이스)에서 oc 또는 virtctl 명령을 사용하여 이를 관리할 수 있습니다.

virtctl 명령은 oc 명령보다 많은 가상화 옵션을 제공합니다. 예를 들어 virtctl 을 사용하여 VM을 일시 중지하거나 포트를 노출할 수 있습니다.

9.5.1. 가상 머신 인스턴스 정보

VMI(가상 머신 인스턴스)는 실행 중인 VM(가상 머신)을 나타냅니다. VMI가 VM 또는 다른 오브젝트에 속하는 경우, 웹 콘솔의 해당 소유자를 통해 또는 oc CLI(명령줄 인터페이스)를 사용하여 VMI를 관리합니다.

독립 실행형 VMI는 스크립트, 자동화 또는 CLI의 다른 방법을 통해 독립적으로 생성 및 시작됩니다. OpenShift Virtualization 환경 외부에서 개발 및 시작된 독립 실행형 VMI가 사용자 환경에 있을 수 있습니다. CLI를 사용하여 이러한 독립 실행형 VMI를 계속 관리할 수 있습니다. 다음과 같이 독립 실행형 VMI와 관련된 특정 작업에 웹 콘솔을 사용할 수도 있습니다.

  • 독립 실행형 VMI 및 세부 정보를 나열합니다.
  • 독립 실행형 VMI의 라벨 및 주석을 편집합니다.
  • 독립 실행형 VMI를 삭제합니다.

VM을 삭제하면 관련 VMI가 자동으로 삭제됩니다. 독립 실행형 VMI는 VM 또는 다른 오브젝트에 속하지 않기 때문에 직접 삭제합니다.

참고

OpenShift Virtualization을 설치 제거하기 전에 CLI 또는 웹 콘솔을 사용하여 독립 실행형 VMI를 나열하고 확인하십시오. 그런 다음 처리 중인 VMI를 삭제합니다.

9.5.2. CLI를 사용하여 모든 가상 머신 인스턴스 나열

oc CLI(명령줄 인터페이스)를 사용하면 독립 실행형 VMI(가상 머신 인스턴스) 및 가상 머신에 속하는 VMI를 포함하여 클러스터의 모든 VMI를 나열할 수 있습니다.

절차

  • 다음 명령을 실행하여 VMI를 모두 나열합니다.

    $ oc get vmis -A

9.5.3. 웹 콘솔을 사용하여 독립 실행형 가상 머신 인스턴스 나열

웹 콘솔을 사용하면 VM(가상 머신)에 속하지 않는 클러스터의 독립 실행형 VMI(가상 머신 인스턴스)를 나열하고 확인할 수 있습니다.

참고

VM 또는 다른 오브젝트에 속하는 VMI는 웹 콘솔에 표시되지 않습니다. 웹 콘솔에는 독립 실행형 VMI만 표시됩니다. 클러스터의 모든 VMI를 나열하려면 CLI를 사용해야 합니다.

절차

  • 사이드 메뉴에서 가상화VirtualMachine를 클릭합니다.

    이름 옆에 있는 다크색 배지로 독립 실행형 VMI를 확인할 수 있습니다.

9.5.4. 웹 콘솔을 사용하여 독립 실행형 가상 머신 인스턴스 편집

웹 콘솔을 사용하여 독립 실행형 VMI(가상 머신 인스턴스)의 주석 및 레이블을 편집할 수 있습니다. 다른 필드는 편집할 수 없습니다.

절차

  1. OpenShift Container Platform 콘솔 의 사이드 메뉴에서 가상화 → VirtualMachine 를 클릭합니다.
  2. VirtualMachineInstance 세부 정보 페이지를 열 수 있도록 독립 실행형 VMI를 선택합니다.
  3. 세부 정보 탭에서 주석 또는 라벨 옆에 있는 연필 아이콘을 클릭합니다.
  4. 관련 사항을 변경하고 저장을 클릭합니다.

9.5.5. CLI를 사용하여 독립 실행형 가상 머신 인스턴스 삭제

oc CLI(명령줄 인터페이스)를 사용하여 독립 실행형 VMI(가상 머신 인스턴스)를 삭제할 수 있습니다.

사전 요구 사항

  • 삭제할 VMI의 이름을 확인합니다.

절차

  • 다음 명령을 실행하여 VMI를 삭제합니다.

    $ oc delete vmi <vmi_name>

9.5.6. 웹 콘솔을 사용하여 독립 실행형 가상 머신 인스턴스 삭제

웹 콘솔에서 독립 실행형 VMI(가상 머신 인스턴스)를 삭제합니다.

절차

  1. OpenShift Container Platform 웹 콘솔 의 사이드 메뉴에서 가상화 → VirtualMachine 를 클릭합니다.
  2. 작업VirtualMachineInstance 삭제를 클릭합니다.
  3. 확인 팝업 창에서 삭제를 클릭하여 독립 실행형 VMI를 영구적으로 삭제합니다.

9.6. 가상 머신 상태 제어

웹 콘솔에서 가상 머신을 중지, 시작, 재시작, 일시 정지 해제할 수 있습니다.

virtctl 을 사용하여 가상 머신 상태를 관리하고 CLI에서 다른 작업을 수행할 수 있습니다. 예를 들어 virtctl 을 사용하여 VM을 강제로 중지하거나 포트를 노출할 수 있습니다.

9.6.1. 가상 머신 시작

웹 콘솔에서 가상 머신을 시작할 수 있습니다.

절차

  1. 사이드 메뉴에서 가상화VirtualMachine를 클릭합니다.
  2. 시작할 가상 머신이 포함된 행을 찾습니다.
  3. 사용 사례에 적합한 메뉴로 이동합니다.

    • 여러 가상 머신에서 작업을 수행할 수 있는 이 페이지를 유지하려면 다음을 수행하십시오.

      1. 행의 맨 오른쪽 끝에 있는 옵션 메뉴 kebab 를 클릭합니다.
    • 시작하기 전에 선택한 가상 머신에 대한 포괄적인 정보를 보려면 다음을 수행하십시오.

      1. 가상 머신의 이름을 클릭하여 VirtualMachine 세부 정보 페이지에 액세스합니다.
      2. 작업을 클릭합니다.
  4. 재시작 을 선택합니다.
  5. 확인 창에서 시작을 클릭하여 가상 머신을 시작합니다.
참고

URL 소스에서 프로비저닝된 가상 머신을 처음 시작하면 가상 머신의 상태가 가져오는 중이 되고 OpenShift Virtualization은 URL 끝점에서 컨테이너를 가져옵니다. 이미지 크기에 따라 이 프로세스에 몇 분이 걸릴 수 있습니다.

9.6.2. 가상 머신 재시작

웹 콘솔에서 실행 중인 가상 머신을 재시작할 수 있습니다.

중요

오류를 방지하려면 가져오는 중 상태의 가상 머신을 재시작하지 마십시오.

절차

  1. 사이드 메뉴에서 가상화VirtualMachine를 클릭합니다.
  2. 재시작할 가상 머신이 포함된 행을 찾습니다.
  3. 사용 사례에 적합한 메뉴로 이동합니다.

    • 여러 가상 머신에서 작업을 수행할 수 있는 이 페이지를 유지하려면 다음을 수행하십시오.

      1. 행의 맨 오른쪽 끝에 있는 옵션 메뉴 kebab 를 클릭합니다.
    • 재시작하기 전에 선택한 가상 머신에 대한 포괄적인 정보를 보려면 다음을 수행하십시오.

      1. 가상 머신의 이름을 클릭하여 VirtualMachine 세부 정보 페이지에 액세스합니다.
      2. 작업재시작 을 클릭합니다.
  4. 확인 창에서 재시작을 클릭하여 가상 머신을 재시작합니다.

9.6.3. 가상 머신 중지

웹 콘솔에서 가상 머신을 중지할 수 있습니다.

절차

  1. 사이드 메뉴에서 가상화VirtualMachine를 클릭합니다.
  2. 중지할 가상 머신이 포함된 행을 찾습니다.
  3. 사용 사례에 적합한 메뉴로 이동합니다.

    • 여러 가상 머신에서 작업을 수행할 수 있는 이 페이지를 유지하려면 다음을 수행하십시오.

      1. 행의 맨 오른쪽 끝에 있는 옵션 메뉴 kebab 를 클릭합니다.
    • 중지하기 전에 선택한 가상 머신에 대한 포괄적인 정보를 보려면 다음을 수행하십시오.

      1. 가상 머신의 이름을 클릭하여 VirtualMachine 세부 정보 페이지에 액세스합니다.
      2. 작업중지 를 클릭합니다.
  4. 확인 창에서 중지를 클릭하여 가상 머신을 중지합니다.

9.6.4. 가상 머신 정지 해제

웹 콘솔에서 일시 정지된 가상 머신의 일시 정지를 해제할 수 있습니다.

사전 요구 사항

  • 가상 머신 중 하나 이상의 상태가 일시 정지됨이어야 합니다.

    참고

    virtctl 클라이언트를 사용하여 가상 머신을 일시 정지할 수 있습니다.

절차

  1. 사이드 메뉴에서 가상화VirtualMachine를 클릭합니다.
  2. 일시 정지를 해제할 가상 머신이 포함된 행을 찾습니다.
  3. 사용 사례에 적합한 메뉴로 이동합니다.

    • 여러 가상 머신에서 작업을 수행할 수 있는 이 페이지를 유지하려면 다음을 수행하십시오.

      1. 상태 열에서 일시 정지됨을 클릭합니다.
    • 일시 정지하기 전에 선택한 가상 머신에 대한 포괄적인 정보를 보려면 다음을 수행하십시오.

      1. 가상 머신의 이름을 클릭하여 VirtualMachine 세부 정보 페이지에 액세스합니다.
      2. 상태 오른쪽에 있는 연필 아이콘을 클릭합니다.
  4. 확인 창에서 일시 정지 해제를 클릭하여 가상 머신의 일시 정지를 해제합니다.

9.7. 가상 머신 콘솔에 액세스

OpenShift Virtualization에서는 다양한 제품 작업을 수행할 수 있도록 여러 개의 가상 머신 콘솔을 제공합니다. OpenShift Container Platform 웹 콘솔과 CLI 명령을 사용하여 이러한 콘솔에 액세스할 수 있습니다.

참고

단일 가상 머신에 대한 동시 VNC 연결 실행은 현재 지원되지 않습니다.

9.7.1. OpenShift Container Platform 웹 콘솔에서 가상 머신 콘솔에 액세스

OpenShift Container Platform 웹 콘솔에서 직렬 콘솔 또는 VNC 콘솔을 사용하여 가상 머신에 연결할 수 있습니다.

OpenShift Container Platform 웹 콘솔에서 RDP(원격 데스크탑 프로토콜)를 사용하는 데스크탑 뷰어 콘솔을 사용하여 Windows 가상 머신에 연결할 수 있습니다.

9.7.1.1. 직렬 콘솔 연결

웹 콘솔의 VirtualMachine 세부 정보 페이지에 있는 콘솔 탭에서 실행 중인 가상 머신의 직렬 콘솔에 연결합니다.

절차

  1. OpenShift Container Platform 콘솔 의 사이드 메뉴에서 가상화 → VirtualMachine 를 클릭합니다.
  2. 가상 머신을 선택하여 VirtualMachine 세부 정보 페이지를 엽니다.
  3. 콘솔 탭을 클릭합니다. 기본적으로 VNC 콘솔이 열립니다.
  4. 연결 끊기 를 클릭하여 한 번에 하나의 콘솔 세션만 열려 있는지 확인합니다. 그렇지 않으면 VNC 콘솔 세션이 백그라운드에서 활성 상태로 유지됩니다.
  5. VNC 콘솔 드롭다운 목록을 클릭하고 직렬 콘솔을 선택합니다.
  6. 연결 끊기 를 클릭하여 콘솔 세션을 종료합니다.
  7. 선택 사항: 새 창에서 콘솔 열기를 클릭하여 직렬 콘솔을 별도의 창에서 엽니다.
9.7.1.2. VNC 콘솔에 연결

웹 콘솔의 VirtualMachine 세부 정보 페이지에 있는 콘솔 탭에서 실행 중인 가상 머신의 VNC 콘솔에 연결합니다.

절차

  1. OpenShift Container Platform 콘솔 의 사이드 메뉴에서 가상화 → VirtualMachine 를 클릭합니다.
  2. 가상 머신을 선택하여 VirtualMachine 세부 정보 페이지를 엽니다.
  3. 콘솔 탭을 클릭합니다. 기본적으로 VNC 콘솔이 열립니다.
  4. 선택 사항: 새 창에서 콘솔 열기를 클릭하여 VNC 콘솔을 별도의 창에서 엽니다.
  5. 선택 사항: 키 보내기를 클릭하여 키 조합을 가상 머신에 보냅니다.
  6. 콘솔 창 외부에서 클릭한 다음 연결 끊기 를 클릭하여 세션을 종료합니다.
9.7.1.3. RDP를 사용하여 Windows 가상 머신에 연결

RDP(Remote Desktop Protocol)를 사용하는 데스크탑 뷰어 콘솔은 Windows 가상 머신 연결을 위해 개선된 콘솔 환경을 제공합니다.

RDP를 사용하여 Windows 가상 머신에 연결하려면 웹 콘솔의 VirtualMachine 세부 정보 페이지에 있는 콘솔 탭에서 가상 머신의 console.rdp 파일을 다운로드하여 선호하는 RDP 클라이언트에 제공하십시오.

사전 요구 사항

  • Windows 가상 머신이 실행 중이고 QEMU 게스트 에이전트가 설치되어 있습니다. qemu-guest-agent는 VirtIO 드라이버에 포함되어 있습니다.
  • RDP 클라이언트가 Windows 가상 머신과 동일한 네트워크의 머신에 설치되어 있습니다.

절차

  1. OpenShift Container Platform 콘솔 의 사이드 메뉴에서 가상화 → VirtualMachine 를 클릭합니다.
  2. Windows 가상 머신을 클릭하여 VirtualMachine 세부 정보 페이지를 엽니다.
  3. 콘솔 탭을 클릭합니다.
  4. 콘솔 목록에서 데스크탑 뷰어를 선택합니다.
  5. 원격 데스크탑 시작을 클릭하여 console.rdp 파일을 다운로드합니다.
  6. 선호하는 RDP 클라이언트의 console.rdp 파일을 참조하여 Windows 가상 머신에 연결합니다.
9.7.1.4. 가상 머신 간 전환

Windows 가상 머신(VM)에 vGPU가 연결된 경우 웹 콘솔을 사용하여 기본 디스플레이와 vGPU 표시 간에 전환할 수 있습니다.

사전 요구 사항

  • 중재된 장치는 HyperConverged 사용자 정의 리소스에서 구성되며 VM에 할당됩니다.
  • VM이 실행 중입니다.

절차

  1. OpenShift Container Platform 콘솔에서 가상화VirtualMachine를클릭합니다.
  2. Windows 가상 머신을 선택하여 개요 화면을 엽니다.
  3. 콘솔 탭을 클릭합니다.
  4. 콘솔 목록에서 VNC 콘솔 을 선택합니다.
  5. Send Key 목록에서 적절한 키 조합을 선택합니다.

    1. 기본 VM 디스플레이에 액세스하려면 Ctl + Alt+ 1 을 선택합니다.
    2. vGPU 디스플레이에 액세스하려면 Ctl + Alt + 2 를 선택합니다.

추가 리소스

9.7.2. CLI 명령을 사용하여 가상 머신 콘솔에 액세스

9.7.2.1. virtctl을 사용하여 SSH를 통해 가상 머신에 액세스

virtctl ssh 명령을 사용하여 SSH 트래픽을 가상 머신(VM)으로 전달할 수 있습니다.

참고

컨트롤 플레인에서 SSH 트래픽이 많은 경우 API 서버의 속도가 느려질 수 있습니다. 많은 연결이 정기적으로 필요한 경우 전용 Kubernetes 서비스 오브젝트를 사용하여 가상 머신에 액세스합니다.

사전 요구 사항

  • cluster-admin 권한이 있는 OpenShift Container Platform 클러스터에 액세스할 수 있습니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.
  • virtctl 클라이언트가 설치되어 있어야 합니다.
  • 액세스하려는 가상 머신이 실행 중입니다.
  • VM과 동일한 프로젝트에 있습니다.

절차

  1. ssh-keygen 명령을 사용하여 SSH 공개 키 쌍을 생성합니다.

    $ ssh-keygen -f <key_file> 1
    1
    키를 저장할 파일을 지정합니다.
  2. VM에 액세스하기 위한 SSH 공개 키가 포함된 SSH 인증 보안을 생성합니다.

    $ oc create secret generic my-pub-key --from-file=key1=<key_file>.pub
  3. VirtualMachine 매니페스트의 보안에 대한 참조를 추가합니다. 예를 들어 다음과 같습니다.

    apiVersion: kubevirt.io/v1
    kind: VirtualMachine
    metadata:
      name: testvm
    spec:
      running: true
      template:
        spec:
          accessCredentials:
          - sshPublicKey:
              source:
                secret:
                  secretName: my-pub-key 1
              propagationMethod:
                configDrive: {} 2
    # ...
    1
    SSH 인증 보안 오브젝트에 대한 참조 입니다.
    2
    SSH 공개 키는 VM에 configDrive 공급자를 사용하여 cloud-init 메타데이터로 삽입됩니다.
  4. VM을 다시 시작하여 변경 사항을 적용합니다.
  5. 다음 명령을 실행하여 SSH를 통해 VM에 액세스합니다.

    $ virtctl ssh -i <key_file> <vm_username>@<vm_name>
  6. 선택 사항: VM으로 파일을 안전하게 전송하거나 VM에서 전송하려면 다음 명령을 사용합니다.

    시스템에서 VM으로 파일을 복사

    $ virtctl scp -i <key_file> <filename> <vm_username>@<vm_name>:

    VM에서 시스템으로 파일을 복사

    $ virtctl scp -i <key_file> <vm_username@<vm_name>:<filename> .

9.7.2.2. 가상 머신 인스턴스의 직렬 콘솔에 액세스

virtctl console 명령은 지정된 가상 머신 인스턴스에 대한 직렬 콘솔을 엽니다.

사전 요구 사항

  • virt-viewer 패키지가 설치되어 있어야 합니다.
  • 액세스하려는 가상 머신 인스턴스가 실행 중이어야 합니다.

절차

  • virtctl을 사용하여 직렬 콘솔에 연결합니다.

    $ virtctl console <VMI>
9.7.2.3. VNC를 사용하여 가상 머신 인스턴스의 그래픽 콘솔에 액세스

virtctl 클라이언트 유틸리티는 remote-viewer 기능을 사용하여 실행 중인 가상 머신 인스턴스에 대해 그래픽 콘솔을 열 수 있습니다. 이 기능은 virt-viewer 패키지에 포함되어 있습니다.

사전 요구 사항

  • virt-viewer 패키지가 설치되어 있어야 합니다.
  • 액세스하려는 가상 머신 인스턴스가 실행 중이어야 합니다.
참고

원격 머신에서 SSH를 통해 virtctl을 사용하는 경우 X 세션을 머신으로 전달해야 합니다.

절차

  1. virtctl 유틸리티를 사용하여 그래픽 인터페이스에 연결합니다.

    $ virtctl vnc <VMI>
  2. 명령이 실패하는 경우 -v 플래그를 사용하여 문제 해결 정보를 수집합니다.

    $ virtctl vnc <VMI> -v 4
9.7.2.4. RDP 콘솔을 사용하여 Windows 가상 머신에 연결

로컬 RDP(Remote Desktop Protocol) 클라이언트를 사용하여 Windows VM(가상 머신)에 연결할 Kubernetes 서비스 오브젝트를 생성합니다.

사전 요구 사항

  • Windows 가상 머신이 실행 중이고 QEMU 게스트 에이전트가 설치되어 있습니다. qemu-guest-agent 오브젝트는 VirtIO 드라이버에 포함되어 있습니다.
  • 로컬 머신에 RDP 클라이언트가 설치되어 있어야 합니다.

절차

  1. VirtualMachine 매니페스트를 편집하여 서비스 생성을 위한 라벨을 추가합니다.

    apiVersion: kubevirt.io/v1
    kind: VirtualMachine
    metadata:
      name: vm-ephemeral
      namespace: example-namespace
    spec:
      running: false
      template:
        metadata:
          labels:
            special: key 1
    # ...
    1
    spec.template.metadata.labels 섹션에 special: key 라벨을 추가합니다.
    참고

    가상 머신의 라벨은 Pod로 전달됩니다. special: key 레이블은 서비스 매니페스트의 spec.selector 특성의 레이블과 일치해야 합니다.

  2. VirtualMachine 매니페스트 파일을 저장하여 변경 사항을 적용합니다.
  3. VM을 노출할 서비스 매니페스트를 생성합니다.

    apiVersion: v1
    kind: Service
    metadata:
      name: rdpservice 1
      namespace: example-namespace 2
    spec:
      ports:
      - targetPort: 3389 3
        protocol: TCP
      selector:
        special: key 4
      type: NodePort 5
    # ...
    1
    Service 오브젝트의 이름입니다.
    2
    Service 오브젝트가 있는 네임스페이스입니다. 이는 VirtualMachine 매니페스트의 metadata.namespace 필드와 일치해야 합니다.
    3
    서비스에서 노출할 VM 포트입니다. 포트 목록이 VM 매니페스트에 정의된 경우 열려 있는 포트를 참조해야 합니다.
    4
    VirtualMachine 매니페스트의 spec.template.metadata.labels 스탠자에 추가한 라벨 참조입니다.
    5
    서비스 유형입니다.
  4. 서비스 매니페스트 파일을 저장합니다.
  5. 다음 명령을 실행하여 서비스를 생성합니다.

    $ oc create -f <service_name>.yaml
  6. VM을 시작합니다. VM이 이미 실행 중인 경우 다시 시작합니다.
  7. Service 오브젝트를 쿼리하여 사용할 수 있는지 확인합니다.

    $ oc get service -n example-namespace

    NodePort 서비스의 출력 예

    NAME        TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)            AGE
    rdpservice   NodePort    172.30.232.73   <none>       3389:30000/TCP    5m

  8. 다음 명령을 실행하여 노드의 IP 주소를 가져옵니다.

    $ oc get node <node_name> -o wide

    출력 예

    NAME    STATUS   ROLES   AGE    VERSION  INTERNAL-IP      EXTERNAL-IP
    node01  Ready    worker  6d22h  v1.24.0  192.168.55.101   <none>

  9. 원하는 RDP 클라이언트에 노드 IP 주소와 할당된 포트를 지정합니다.
  10. 사용자 이름과 암호를 입력하여 Windows 가상 머신에 연결합니다.

9.8. sysprep을 사용하여 Windows 설치 자동화

Microsoft DVD 이미지와 sysprep 을 사용하여 Windows 가상 머신의 설치, 설정 및 소프트웨어 프로비저닝을 자동화할 수 있습니다.

9.8.1. Windows DVD를 사용하여 VM 디스크 이미지 생성

Microsoft는 다운로드를 위한 디스크 이미지를 제공하지 않지만 Windows DVD를 사용하여 디스크 이미지를 만들 수 있습니다. 그러면 이 디스크 이미지를 사용하여 가상 머신을 생성할 수 있습니다.

절차

  1. OpenShift Virtualization 웹 콘솔에서 스토리지PersistentVolumeClaims데이터 업로드를 사용하여 PersistentVolumeClaim 생성 양식을 클릭합니다.
  2. 원하는 프로젝트를 선택합니다.
  3. 영구 볼륨 클레임 이름을 설정합니다.
  4. Windows DVD에서 VM 디스크 이미지를 업로드합니다. 이제 새 Windows VM을 생성하기 위해 이미지를 부팅 소스로 사용할 수 있습니다.

9.8.2. 디스크 이미지를 사용하여 Windows 설치

디스크 이미지를 사용하여 가상 머신에 Windows를 설치할 수 있습니다.

사전 요구 사항

절차

  1. OpenShift Container Platform 콘솔의 사이드 메뉴에서 가상화카탈로그 를 클릭합니다.
  2. Windows 템플릿을 선택하고 사용자 지정 VirtualMachine 를 클릭합니다.
  3. 디스크 소스 목록에서 Upload a new file to a PVC(새 파일을 PVC로 업로드) 를 선택하고 DVD 이미지로 이동합니다.
  4. 검토를 클릭하고 VirtualMachine를 생성합니다.
  5. 이 가상 머신에 사용 가능한 운영 체제의 명확한 복제.
  6. 생성 후 이 VirtualMachine 를 지웁니다.
  7. 스크립트 탭의 Sysprep 섹션에서 편집 을 클릭합니다.
  8. autountend.xml 응답 파일로 이동하여 저장을 클릭합니다.
  9. Create VirtualMachine 를 클릭합니다.
  10. YAML 탭에서 running:falserunStrategy: RerunOnFailure 로 교체하고 저장을 클릭합니다.

VM은 autounattend.xml 응답 파일이 포함된 sysprep 디스크로 시작합니다.

9.8.3. sysprep을 사용하여 Windows VM 일반화

이미지를 일반화하면 해당 이미지를 사용하여 가상 머신(VM)에 이미지가 배포될 때 모든 시스템별 구성 데이터를 제거할 수 있습니다.

VM을 일반화하기 전에 sysprep 툴에서 무인 Windows 설치 후 응답 파일을 감지할 수 없는지 확인해야 합니다.

절차

  1. OpenShift Container Platform 콘솔에서 가상화VirtualMachine를 클릭합니다.
  2. Windows VM을 선택하여 VirtualMachine 세부 정보 페이지를 엽니다.
  3. 디스크 탭을 클릭합니다.
  4. sysprep 디스크의 옵션 메뉴 kebab 를 클릭하고 분리를 선택합니다.
  5. Detach (분리)를 클릭합니다.
  6. sysprep 도구의 탐지를 방지하기 위해 C:\Windows\Panther\unattend.xml 의 이름을 변경합니다.
  7. 다음 명령을 실행하여 sysprep 프로그램을 시작합니다.

    %WINDIR%\System32\Sysprep\sysprep.exe /generalize /shutdown /oobe /mode:vm
  8. sysprep 툴이 완료되면 Windows VM이 종료됩니다. 이제 VM의 디스크 이미지를 Windows VM의 설치 이미지로 사용할 수 있습니다.

이제 VM을 전문으로 설정할 수 있습니다.

9.8.4. Windows 가상 머신 전문 설정

가상 머신(VM)을 전문으로 설정하면 일반 Windows 이미지에서 VM으로 컴퓨터 관련 정보를 구성합니다.

사전 요구 사항

절차

  1. OpenShift Container Platform 콘솔에서 가상화카탈로그 를 클릭합니다.
  2. Windows 템플릿을 선택하고 사용자 지정 VirtualMachine 를 클릭합니다.
  3. Disk 소스 목록에서 PVC(clone PVC) 를 선택합니다.
  4. 영구 볼륨 클레임 프로젝트 및 일반화된 Windows 이미지의 영구 볼륨 클레임 이름을 지정합니다.
  5. 검토를 클릭하고 VirtualMachine를 생성합니다.
  6. 스크립트 탭을 클릭합니다.
  7. Sysprep 섹션에서 편집 을 클릭하고 unattend.xml 응답 파일을 찾은 다음 저장을 클릭합니다.
  8. Create VirtualMachine 를 클릭합니다.

초기 부팅 중에 Windows는 unattend.xml 응답 파일을 사용하여 VM을 전문으로 설정합니다. 이제 VM을 사용할 준비가 되었습니다.

9.8.5. 추가 리소스

9.9. 실패한 노드를 해결하여 가상 머신 장애 조치 트리거

노드가 실패하고 머신 상태 점검 이 클러스터에 배포되지 않으면 RunStrategy: Always 가 구성된 VM(가상 머신)이 정상 노드에 자동으로 재배치되지 않습니다. VM 장애 조치를 트리거하려면 Node 오브젝트를 수동으로 삭제해야 합니다.

참고

설치 관리자 프로비저닝 인프라 를 사용하여 클러스터를 설치하고 머신 상태 점검을 올바르게 구성한 경우:

  • 실패한 노드는 자동으로 재활용됩니다.
  • RunStrategyAlways 또는 RerunOnFailure 로 설정된 가상 머신은 정상 노드에 자동으로 예약됩니다.

9.9.1. 사전 요구 사항

  • 가상 머신을 실행 중이던 노드에 NotReady 조건이 있습니다.
  • 실패한 노드에서 실행 중이던 가상 머신의 RunStrategyAlways로 설정되어 있습니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.

9.9.2. 베어 메탈 클러스터에서 노드 삭제

CLI를 사용하여 노드를 삭제하면 Kubernetes에서 노드 오브젝트가 삭제되지만 노드에 존재하는 Pod는 삭제되지 않습니다. 복제 컨트롤러에서 지원하지 않는 기본 Pod는 OpenShift Container Platform에 액세스할 수 없습니다. 복제 컨트롤러에서 지원하는 Pod는 사용 가능한 다른 노드로 다시 예약됩니다. 로컬 매니페스트 Pod를 삭제해야 합니다.

절차

다음 단계를 완료하여 베어 메탈에서 실행 중인 OpenShift Container Platform 클러스터에서 노드를 삭제합니다.

  1. 노드를 예약 불가능으로 표시합니다.

    $ oc adm cordon <node_name>
  2. 노드의 모든 Pod를 드레이닝합니다.

    $ oc adm drain <node_name> --force=true

    노드가 오프라인 상태이거나 응답하지 않는 경우 이 단계가 실패할 수 있습니다. 노드가 응답하지 않더라도 공유 스토리지에 쓰는 워크로드를 계속 실행되고 있을 수 있습니다. 데이터 손상을 방지하려면 계속하기 전에 물리적 하드웨어의 전원을 끕니다.

  3. 클러스터에서 노드를 삭제합니다.

    $ oc delete node <node_name>

    노드 오브젝트가 클러스터에서 삭제되어도 재부팅 후 또는 kubelet 서비스가 재시작되면 클러스터에 다시 참여할 수 있습니다. 노드와 노드의 모든 데이터를 영구적으로 삭제하려면 노드를 해제해야 합니다.

  4. 물리 하드웨어의 전원을 끈 경우 노드가 클러스터에 다시 참여할 수 있도록 해당 하드웨어를 다시 켭니다.

9.9.3. 가상 머신 장애 조치 확인

비정상 노드에서 모든 리소스가 종료되면 VM이 재배치될 때마다 정상 노드에 새 VMI(가상 머신 인스턴스)가 자동으로 생성됩니다. VMI가 생성되었는지 확인하려면 oc CLI를 사용하여 모든 VMI를 확인합니다.

9.9.3.1. CLI를 사용하여 모든 가상 머신 인스턴스 나열

oc CLI(명령줄 인터페이스)를 사용하면 독립 실행형 VMI(가상 머신 인스턴스) 및 가상 머신에 속하는 VMI를 포함하여 클러스터의 모든 VMI를 나열할 수 있습니다.

절차

  • 다음 명령을 실행하여 VMI를 모두 나열합니다.

    $ oc get vmis -A

9.10. 가상 머신에 QEMU 게스트 에이전트 설치

QEMU 게스트 에이전트는 가상 머신에서 실행되고 가상 머신, 사용자, 파일 시스템, 보조 네트워크에 대한 정보를 호스트에 전달하는 데몬입니다.

9.10.1. Linux 가상 머신에 QEMU 게스트 에이전트 설치

qemu-guest-agent는 광범위하게 사용되며, Red Hat 가상 머신에 기본적으로 제공됩니다. 에이전트를 설치하고 서비스를 시작합니다.

VM(가상 머신)에 QEMU 게스트 에이전트가 설치되어 실행되고 있는지 확인하려면 AgentConnected가 VM 사양에 나열되어 있는지 확인합니다.

참고

가장 높은 무결성을 가진 온라인(실행 상태) VM의 스냅샷을 생성하려면 QEMU 게스트 에이전트를 설치합니다.

QEMU 게스트 에이전트는 시스템 워크로드에 따라 VM의 파일 시스템을 가능한 한 많이 정지하여 일관된 스냅샷을 사용합니다. 이렇게 하면 스냅샷을 생성하기 전에 진행 중인 I/O가 디스크에 기록됩니다. 게스트 에이전트가 없으면 정지를 수행할 수 없으며 최상의 스냅샷을 생성합니다. 스냅샷이 수행된 조건은 웹 콘솔 또는 CLI에 표시되는 스냅샷 표시에 반영됩니다.

절차

  1. 콘솔 중 하나 또는 SSH를 통해 가상 머신 명령줄에 액세스합니다.
  2. 가상 머신에 QEMU 게스트 에이전트를 설치합니다.

    $ yum install -y qemu-guest-agent
  3. 서비스가 지속되는지 확인하고 다음을 시작합니다.

    $ systemctl enable --now qemu-guest-agent

9.10.2. Windows 가상 머신에 QEMU 게스트 에이전트 설치

Windows 가상 머신의 경우 QEMU 게스트 에이전트는 VirtIO 드라이버에 포함됩니다. 기존 또는 새 Windows 설치에 드라이버를 설치합니다.

VM(가상 머신)에 QEMU 게스트 에이전트가 설치되어 실행되고 있는지 확인하려면 AgentConnected가 VM 사양에 나열되어 있는지 확인합니다.

참고

가장 높은 무결성을 가진 온라인(실행 상태) VM의 스냅샷을 생성하려면 QEMU 게스트 에이전트를 설치합니다.

QEMU 게스트 에이전트는 시스템 워크로드에 따라 VM의 파일 시스템을 가능한 한 많이 정지하여 일관된 스냅샷을 사용합니다. 이렇게 하면 스냅샷을 생성하기 전에 진행 중인 I/O가 디스크에 기록됩니다. 게스트 에이전트가 없으면 정지를 수행할 수 없으며 최상의 스냅샷을 생성합니다. 스냅샷이 수행된 조건은 웹 콘솔 또는 CLI에 표시되는 스냅샷 표시에 반영됩니다.

9.10.2.1. 기존 Windows 가상 머신에 VirtIO 드라이버 설치

연결된 SATA CD 드라이브에서 기존 Windows 가상 머신에 VirtIO 드라이버를 설치합니다.

참고

다음 절차에서는 일반적인 방법을 사용하여 Windows에 드라이버를 추가합니다. 프로세스는 Windows 버전마다 약간 다를 수 있습니다. 특정 설치 단계는 사용 중인 Windows 버전의 설치 설명서를 참조하십시오.

절차

  1. 가상 머신을 시작하고 그래픽 콘솔에 연결합니다.
  2. Windows 사용자 세션에 로그인합니다.
  3. 장치 관리자를 열고 기타 장치를 확장하여 알 수 없는 장치를 나열합니다.

    1. Device Properties을 열어 알 수 없는 장치를 확인합니다. 장치를 마우스 오른쪽 버튼으로 클릭하고 속성을 선택합니다.
    2. 세부 정보 탭을 클릭하고 속성 목록에서 하드웨어 ID를 선택합니다.
    3. 하드웨어 ID을 지원되는 VirtIO 드라이버와 비교합니다.
  4. 장치를 마우스 오른쪽 단추로 클릭하고 드라이버 소프트웨어 업데이트를 선택합니다.
  5. 컴퓨터에서 드라이버 소프트웨어 찾아보기를 클릭하고 VirtIO 드라이버가 있는 연결된 SATA CD 드라이브를 찾습니다. 드라이버는 드라이버 유형, 운영 체제, CPU 아키텍처에 따라 계층적으로 정렬됩니다.
  6. 다음을 클릭하여 드라이버를 설치합니다.
  7. 필요한 모든 VirtIO 드라이버에 대해 이 과정을 반복합니다.
  8. 드라이버 설치 후 닫기를 클릭하여 창을 닫습니다.
  9. 가상 머신을 재부팅하여 드라이버 설치를 완료합니다.
9.10.2.2. Windows 설치 중 VirtIO 드라이버 설치

Windows를 설치하는 동안 연결된 SATA CD 드라이버에서 VirtIO 드라이버를 설치합니다.

참고

이 절차에서는 일반적인 Windows 설치 방법을 사용하며, 설치 방법은 Windows 버전마다 다를 수 있습니다. 설치 중인 Windows 버전에 대한 설명서를 참조하십시오.

절차

  1. 가상 머신을 시작하고 그래픽 콘솔에 연결합니다.
  2. Windows 설치 프로세스를 시작합니다.
  3. 고급 설치를 선택합니다.
  4. 저장 대상은 드라이버가 로드되어야 인식됩니다. Load driver를 클릭합니다.
  5. 드라이버는 SATA CD 드라이브로 연결되어 있습니다. 확인을 클릭하고 스토리지 드라이버를 로드할 CD 드라이브를 찾습니다. 드라이버는 드라이버 유형, 운영 체제, CPU 아키텍처에 따라 계층적으로 정렬됩니다.
  6. 필요한 모든 드라이버에 대해 위의 두 단계를 반복합니다.
  7. Windows 설치를 완료합니다.

9.11. 가상 머신에 대한 QEMU 게스트 에이전트 정보 보기

QEMU 게스트 에이전트가 가상 머신에서 실행되는 경우, 웹 콘솔을 사용하여 가상 머신, 사용자, 파일 시스템, 보조 네트워크에 대한 정보를 볼 수 있습니다.

9.11.1. 사전 요구 사항

9.11.2. 웹 콘솔의 QEMU 게스트 에이전트 정보

QEMU 게스트 에이전트가 설치되면 VirtualMachine 세부 정보 페이지의 개요 및 세부 정보 탭에 호스트 이름, 운영 체제, 시간대 및 로그인한 사용자에 대한 정보가 표시됩니다.

VirtualMachine 세부 정보 페이지에는 가상 머신에 설치된 게스트 운영 체제에 대한 정보가 표시됩니다. 세부 정보 탭에는 로그인한 사용자에 대한 정보가 포함된 테이블이 표시됩니다. 디스크 탭에는 파일 시스템에 대한 정보가 포함된 테이블이 표시됩니다.

참고

QEMU 게스트 에이전트가 설치되지 않은 경우 개요세부 정보 탭에 가상 머신이 생성될 때 지정된 운영 체제에 대한 정보가 표시됩니다.

9.11.3. 웹 콘솔에서 QEMU 게스트 에이전트 정보 보기

웹 콘솔을 사용하여 QEMU 게스트 에이전트에서 호스트로 전달하는 가상 머신에 대한 정보를 볼 수 있습니다.

절차

  1. 사이드 메뉴에서 가상화VirtualMachine를 클릭합니다.
  2. 가상 머신 이름을 선택하여 VirtualMachine 세부 정보 페이지를 엽니다.
  3. 세부 정보 탭을 클릭하여 활성 사용자를 확인합니다.
  4. 파일 시스템에 대한 정보를 보려면 디스크 탭을 클릭합니다.

9.12. 가상 머신에서 구성 맵, 시크릿, 서비스 계정 관리

시크릿, 구성 맵, 서비스 계정을 사용하여 구성 데이터를 가상 머신에 전달할 수 있습니다. 예를 들면 다음을 수행할 수 있습니다.

  • 가상 머신에 시크릿을 추가하여 자격 증명이 필요한 서비스에 대한 액세스 권한을 부여합니다.
  • Pod 또는 다른 오브젝트에서 데이터를 사용할 수 있도록 구성 맵에 기밀이 아닌 구성 데이터를 저장합니다.
  • 서비스 계정을 특정 구성 요소와 연결하여 해당 구성 요소가 API 서버에 액세스하도록 허용합니다.
참고

OpenShift Virtualization은 시크릿, 구성 맵, 서비스 계정을 가상 머신 디스크로 노출하므로 추가 오버헤드 없이 여러 플랫폼에서 사용할 수 있습니다.

9.12.1. 가상 머신에 시크릿, 구성 맵 또는 서비스 계정 추가

OpenShift Container Platform 웹 콘솔을 사용하여 가상 머신에 시크릿, 구성 맵 또는 서비스 계정을 추가합니다.

이러한 리소스는 가상 머신에 디스크로 추가됩니다. 그런 다음 다른 디스크를 마운트할 때와 같이 시크릿, 구성 맵 또는 서비스 계정을 마운트합니다.

가상 머신이 실행 중인 경우 가상 머신을 재시작해야 변경 사항이 적용됩니다. 새로 추가된 리소스는 페이지 상단 보류 중인 변경 사항 배너의 환경디스크 탭 모두에서 보류 중인 변경 사항으로 표시됩니다.

사전 요구 사항

  • 추가할 시크릿, 구성 맵 또는 서비스 계정은 대상 가상 머신과 동일한 네임스페이스에 있어야 합니다.

절차

  1. 사이드 메뉴에서 가상화VirtualMachine를 클릭합니다.
  2. 가상 머신을 선택하여 VirtualMachine 세부 정보 페이지를 엽니다.
  3. 환경 탭에서 구성 맵, 시크릿 또는 서비스 계정 추가를 클릭합니다.
  4. Select a resource 를 클릭하고 목록에서 리소스를 선택합니다. 선택한 리소스에 대해 6자리 일련 번호가 자동으로 생성됩니다.
  5. 선택 사항: 다시 로드 를 클릭하여 환경을 마지막 저장된 상태로 되돌립니다.
  6. 저장을 클릭합니다.

검증

  1. VirtualMachine 세부 정보 페이지에서 디스크 탭을 클릭하고 시크릿, 구성 맵 또는 서비스 계정이 디스크 목록에 포함되어 있는지 확인합니다.
  2. 작업 → 재시작을 클릭하여 가상 머신을 재시작합니다.

이제 다른 디스크를 마운트할 때와 같이 시크릿, 구성 맵 또는 서비스 계정을 마운트할 수 있습니다.

9.12.2. 가상 머신에서 시크릿, 구성 맵 또는 서비스 계정 제거

OpenShift Container Platform 웹 콘솔을 사용하여 가상 머신에서 시크릿, 구성 맵 또는 서비스 계정을 제거합니다.

사전 요구 사항

  • 하나 이상의 시크릿, 구성 맵 또는 서비스 계정이 가상 머신에 연결되어 있어야 합니다.

절차

  1. 사이드 메뉴에서 가상화VirtualMachine를 클릭합니다.
  2. 가상 머신을 선택하여 VirtualMachine 세부 정보 페이지를 엽니다.
  3. 환경 탭을 클릭합니다.
  4. 목록에서 삭제할 항목을 찾아 항목 오른쪽에 있는 delete 제거를 클릭합니다.
  5. 저장을 클릭합니다.
참고

다시 로드를 클릭하여 폼을 마지막 저장된 상태로 재설정할 수 있습니다.

검증

  1. VirtualMachine 세부 정보 페이지에서 디스크 탭을 클릭합니다.
  2. 제거한 시크릿, 구성 맵 또는 서비스 계정이 더 이상 디스크 목록에 포함되어 있지 않은지 확인합니다.

9.12.3. 추가 리소스

9.13. 기존 Windows 가상 머신에 VirtIO 드라이버 설치

9.13.1. VirtIO 드라이버 정보

VirtIO 드라이버는 Microsoft Windows 가상 머신을 OpenShift Virtualization에서 실행하는 데 필요한 준가상화 장치 드라이버입니다. 지원되는 드라이버는 Red Hat Ecosystem Catalogcontainer-native-virtualization/virtio-win 컨테이너 디스크에 있습니다.

드라이버 설치를 사용하려면 container-native-virtualization/virtio-win 컨테이너 디스크를 가상 머신에 SATA CD 드라이브로 연결해야 합니다. VirtIO 드라이버는 가상 머신에 Windows를 설치하는 동안 설치하거나 기존 Windows 설치에 추가할 수 있습니다.

드라이버를 설치하면 container-native-virtualization/virtio-win 컨테이너 디스크를 가상 머신에서 제거할 수 있습니다.

새 Windows 가상 머신에 Virtio 드라이버 설치 도 참조하십시오.

9.13.2. Microsoft Windows 가상 머신에 지원되는 VirtIO 드라이버

표 9.3. 지원되는 드라이버
드라이버 이름하드웨어 ID설명

viostor

VEN_1AF4&DEV_1001
VEN_1AF4&DEV_1042

블록 드라이버입니다. 기타 장치 그룹에 SCSI 컨트롤러로 표시되기도 합니다.

viorng

VEN_1AF4&DEV_1005
VEN_1AF4&DEV_1044

엔트로피 소스 드라이버입니다. 기타 장치 그룹에 PCI 장치로 표시되기도 합니다.

NetKVM

VEN_1AF4&DEV_1000
VEN_1AF4&DEV_1041

네트워크 드라이버입니다. 기타 장치 그룹에 이더넷 컨트롤러로 표시되기도 합니다. VirtIO NIC가 구성된 경우에만 사용할 수 있습니다.

9.13.3. 가상 머신에 VirtIO 드라이버 컨테이너 디스크 추가

OpenShift Virtualization에서는 Microsoft Windows용 VirtIO 드라이버를 컨테이너 디스크로 배포하며, Red Hat Ecosystem Catalog에서 사용할 수 있습니다. 이러한 드라이버를 Windows 가상 머신에 설치하려면 가상 머신 구성 파일에서 container-native-virtualization/virtio-win 컨테이너 디스크를 가상 머신에 SATA CD 드라이브로 연결하십시오.

사전 요구 사항

  • Red Hat Ecosystem Catalog에서 container-native-virtualization/virtio-win 컨테이너 디스크를 다운로드합니다. 이 작업은 컨테이너 디스크가 클러스터에 없는 경우 Red Hat 레지스트리에서 다운로드되므로 필수 사항은 아니지만, 설치 시간을 줄일 수 있습니다.

절차

  1. Windows 가상 머신 구성 파일에서 container-native-virtualization/virtio-win 컨테이너 디스크를 cdrom 디스크로 추가합니다. 컨테이너 디스크가 클러스터에 없는 경우 레지스트리에서 다운로드됩니다.

    spec:
      domain:
        devices:
          disks:
            - name: virtiocontainerdisk
              bootOrder: 2 1
              cdrom:
                bus: sata
    volumes:
      - containerDisk:
          image: container-native-virtualization/virtio-win
        name: virtiocontainerdisk
    1
    OpenShift Virtualization은 VirtualMachine 구성 파일에 정의된 순서대로 가상 머신 디스크를 부팅합니다. container-native-virtualization/virtio-win 컨테이너 디스크 전에 기타 디스크를 가상 머신에 정의하거나, 선택적 bootOrder 매개변수를 사용하여 가상 머신을 올바른 디스크에서 부팅할 수 있습니다. 디스크에 bootOrder를 지정하는 경우 구성의 모든 디스크에 지정해야 합니다.
  2. 가상 머신이 시작되면 디스크를 사용할 수 있습니다.

    • 실행 중인 가상 머신에 컨테이너 디스크를 추가할 때는 CLI에 oc apply -f <vm.yaml>을 사용하거나 가상 머신을 재부팅하여 변경 사항을 적용합니다.
    • 가상 머신이 실행 중이 아닌 경우에는 virtctl start <vm>을 사용합니다.

가상 머신이 시작되면 연결된 SATA CD 드라이브에서 VirtIO 드라이버를 설치할 수 있습니다.

9.13.4. 기존 Windows 가상 머신에 VirtIO 드라이버 설치

연결된 SATA CD 드라이브에서 기존 Windows 가상 머신에 VirtIO 드라이버를 설치합니다.

참고

다음 절차에서는 일반적인 방법을 사용하여 Windows에 드라이버를 추가합니다. 프로세스는 Windows 버전마다 약간 다를 수 있습니다. 특정 설치 단계는 사용 중인 Windows 버전의 설치 설명서를 참조하십시오.

절차

  1. 가상 머신을 시작하고 그래픽 콘솔에 연결합니다.
  2. Windows 사용자 세션에 로그인합니다.
  3. 장치 관리자를 열고 기타 장치를 확장하여 알 수 없는 장치를 나열합니다.

    1. Device Properties을 열어 알 수 없는 장치를 확인합니다. 장치를 마우스 오른쪽 버튼으로 클릭하고 속성을 선택합니다.
    2. 세부 정보 탭을 클릭하고 속성 목록에서 하드웨어 ID를 선택합니다.
    3. 하드웨어 ID을 지원되는 VirtIO 드라이버와 비교합니다.
  4. 장치를 마우스 오른쪽 단추로 클릭하고 드라이버 소프트웨어 업데이트를 선택합니다.
  5. 컴퓨터에서 드라이버 소프트웨어 찾아보기를 클릭하고 VirtIO 드라이버가 있는 연결된 SATA CD 드라이브를 찾습니다. 드라이버는 드라이버 유형, 운영 체제, CPU 아키텍처에 따라 계층적으로 정렬됩니다.
  6. 다음을 클릭하여 드라이버를 설치합니다.
  7. 필요한 모든 VirtIO 드라이버에 대해 이 과정을 반복합니다.
  8. 드라이버 설치 후 닫기를 클릭하여 창을 닫습니다.
  9. 가상 머신을 재부팅하여 드라이버 설치를 완료합니다.

9.13.5. 가상 머신에서 VirtIO 컨테이너 디스크 제거

필요한 모든 VirtIO 드라이버를 가상 머신에 설치한 후에는 container-native-virtualization/virtio-win 컨테이너 디스크를 더 이상 가상 머신에 연결할 필요가 없습니다. 가상 머신 구성 파일에서 container-native-virtualization/virtio-win 컨테이너 디스크를 제거하십시오.

절차

  1. 구성 파일을 편집하여 diskvolume을 제거합니다.

    $ oc edit vm <vm-name>
    spec:
      domain:
        devices:
          disks:
            - name: virtiocontainerdisk
              bootOrder: 2
              cdrom:
                bus: sata
    volumes:
      - containerDisk:
          image: container-native-virtualization/virtio-win
        name: virtiocontainerdisk
  2. 가상 머신을 재부팅하여 변경 사항을 적용합니다.

9.14. 새로운 Windows 가상 머신에 VirtIO 드라이버 설치

9.14.1. 사전 요구 사항

9.14.2. VirtIO 드라이버 정보

VirtIO 드라이버는 Microsoft Windows 가상 머신을 OpenShift Virtualization에서 실행하는 데 필요한 준가상화 장치 드라이버입니다. 지원되는 드라이버는 Red Hat Ecosystem Catalogcontainer-native-virtualization/virtio-win 컨테이너 디스크에 있습니다.

드라이버 설치를 사용하려면 container-native-virtualization/virtio-win 컨테이너 디스크를 가상 머신에 SATA CD 드라이브로 연결해야 합니다. VirtIO 드라이버는 가상 머신에 Windows를 설치하는 동안 설치하거나 기존 Windows 설치에 추가할 수 있습니다.

드라이버를 설치하면 container-native-virtualization/virtio-win 컨테이너 디스크를 가상 머신에서 제거할 수 있습니다.

기존 Windows 가상 머신에 VirtIO 드라이버 설치 도 참조하십시오.

9.14.3. Microsoft Windows 가상 머신에 지원되는 VirtIO 드라이버

표 9.4. 지원되는 드라이버
드라이버 이름하드웨어 ID설명

viostor

VEN_1AF4&DEV_1001
VEN_1AF4&DEV_1042

블록 드라이버입니다. 기타 장치 그룹에 SCSI 컨트롤러로 표시되기도 합니다.

viorng

VEN_1AF4&DEV_1005
VEN_1AF4&DEV_1044

엔트로피 소스 드라이버입니다. 기타 장치 그룹에 PCI 장치로 표시되기도 합니다.

NetKVM

VEN_1AF4&DEV_1000
VEN_1AF4&DEV_1041

네트워크 드라이버입니다. 기타 장치 그룹에 이더넷 컨트롤러로 표시되기도 합니다. VirtIO NIC가 구성된 경우에만 사용할 수 있습니다.

9.14.4. 가상 머신에 VirtIO 드라이버 컨테이너 디스크 추가

OpenShift Virtualization에서는 Microsoft Windows용 VirtIO 드라이버를 컨테이너 디스크로 배포하며, Red Hat Ecosystem Catalog에서 사용할 수 있습니다. 이러한 드라이버를 Windows 가상 머신에 설치하려면 가상 머신 구성 파일에서 container-native-virtualization/virtio-win 컨테이너 디스크를 가상 머신에 SATA CD 드라이브로 연결하십시오.

사전 요구 사항

  • Red Hat Ecosystem Catalog에서 container-native-virtualization/virtio-win 컨테이너 디스크를 다운로드합니다. 이 작업은 컨테이너 디스크가 클러스터에 없는 경우 Red Hat 레지스트리에서 다운로드되므로 필수 사항은 아니지만, 설치 시간을 줄일 수 있습니다.

절차

  1. Windows 가상 머신 구성 파일에서 container-native-virtualization/virtio-win 컨테이너 디스크를 cdrom 디스크로 추가합니다. 컨테이너 디스크가 클러스터에 없는 경우 레지스트리에서 다운로드됩니다.

    spec:
      domain:
        devices:
          disks:
            - name: virtiocontainerdisk
              bootOrder: 2 1
              cdrom:
                bus: sata
    volumes:
      - containerDisk:
          image: container-native-virtualization/virtio-win
        name: virtiocontainerdisk
    1
    OpenShift Virtualization은 VirtualMachine 구성 파일에 정의된 순서대로 가상 머신 디스크를 부팅합니다. container-native-virtualization/virtio-win 컨테이너 디스크 전에 기타 디스크를 가상 머신에 정의하거나, 선택적 bootOrder 매개변수를 사용하여 가상 머신을 올바른 디스크에서 부팅할 수 있습니다. 디스크에 bootOrder를 지정하는 경우 구성의 모든 디스크에 지정해야 합니다.
  2. 가상 머신이 시작되면 디스크를 사용할 수 있습니다.

    • 실행 중인 가상 머신에 컨테이너 디스크를 추가할 때는 CLI에 oc apply -f <vm.yaml>을 사용하거나 가상 머신을 재부팅하여 변경 사항을 적용합니다.
    • 가상 머신이 실행 중이 아닌 경우에는 virtctl start <vm>을 사용합니다.

가상 머신이 시작되면 연결된 SATA CD 드라이브에서 VirtIO 드라이버를 설치할 수 있습니다.

9.14.5. Windows 설치 중 VirtIO 드라이버 설치

Windows를 설치하는 동안 연결된 SATA CD 드라이버에서 VirtIO 드라이버를 설치합니다.

참고

이 절차에서는 일반적인 Windows 설치 방법을 사용하며, 설치 방법은 Windows 버전마다 다를 수 있습니다. 설치 중인 Windows 버전에 대한 설명서를 참조하십시오.

절차

  1. 가상 머신을 시작하고 그래픽 콘솔에 연결합니다.
  2. Windows 설치 프로세스를 시작합니다.
  3. 고급 설치를 선택합니다.
  4. 저장 대상은 드라이버가 로드되어야 인식됩니다. Load driver를 클릭합니다.
  5. 드라이버는 SATA CD 드라이브로 연결되어 있습니다. 확인을 클릭하고 스토리지 드라이버를 로드할 CD 드라이브를 찾습니다. 드라이버는 드라이버 유형, 운영 체제, CPU 아키텍처에 따라 계층적으로 정렬됩니다.
  6. 필요한 모든 드라이버에 대해 위의 두 단계를 반복합니다.
  7. Windows 설치를 완료합니다.

9.14.6. 가상 머신에서 VirtIO 컨테이너 디스크 제거

필요한 모든 VirtIO 드라이버를 가상 머신에 설치한 후에는 container-native-virtualization/virtio-win 컨테이너 디스크를 더 이상 가상 머신에 연결할 필요가 없습니다. 가상 머신 구성 파일에서 container-native-virtualization/virtio-win 컨테이너 디스크를 제거하십시오.

절차

  1. 구성 파일을 편집하여 diskvolume을 제거합니다.

    $ oc edit vm <vm-name>
    spec:
      domain:
        devices:
          disks:
            - name: virtiocontainerdisk
              bootOrder: 2
              cdrom:
                bus: sata
    volumes:
      - containerDisk:
          image: container-native-virtualization/virtio-win
        name: virtiocontainerdisk
  2. 가상 머신을 재부팅하여 변경 사항을 적용합니다.

9.15. 가상 신뢰할 수 있는 플랫폼 모듈 장치 사용

VirtualMachine (VM) 또는 VirtualMachine Instance (VM) 매니페스트를 편집하여 새 또는 기존 가상 머신에 가상 신뢰할 수 있는 플랫폼 모듈(vTPM) 장치를 추가합니다.

9.15.1. vTPM 장치 정보

물리적 신뢰할 수 있는 플랫폼 모듈 (TPM) 하드웨어 칩과 같은 가상 신뢰할 수있는 플랫폼 모듈 (vTPM) 장치 기능

모든 운영 체제와 함께 vTPM 장치를 사용할 수 있지만 Windows 11에서는 TPM 칩을 설치하거나 부팅해야 합니다. vTPM 장치를 사용하면 Windows 11 이미지에서 생성된 VM이 물리적 TPM 칩 없이 작동할 수 있습니다.

vTPM을 활성화하지 않으면 노드에 하나씩 있는 경우에도 VM에서 TPM 장치를 인식하지 못합니다.

vTPM 장치는 또한 물리적 하드웨어없이 시크릿을 임시로 저장하여 가상 머신을 보호합니다. 그러나 영구 보안 스토리지에 vTPM을 사용하는 것은 현재 지원되지 않습니다. VM이 종료된 후 vTPM은 저장된 시크릿을 삭제합니다.

9.15.2. 가상 머신에 vTPM 장치 추가

VM(가상 머신)에 가상 신뢰할 수 있는 플랫폼 모듈(vTPM) 장치를 추가하면 물리적 TPM 장치 없이 Windows 11 이미지에서 생성된 VM을 실행할 수 있습니다. vTPM 장치는 해당 VM의 비밀도 임시로 저장합니다.

절차

  1. 다음 명령을 실행하여 VM 구성을 업데이트합니다.

    $ oc edit vm <vm_name>
  2. tpm: {} 행이 포함되도록 VM 사양 을 편집합니다. 예를 들어 다음과 같습니다.

    apiVersion: kubevirt.io/v1
    kind: VirtualMachine
    metadata:
        name: example-vm
    spec:
      template:
        spec:
          domain:
            devices:
              tpm: {} 1
    ...
    1
    TPM 장치를 VM에 추가합니다.
  3. 변경 사항을 적용하려면 편집기를 저장하고 종료합니다.
  4. 선택 사항: 실행 중인 가상 머신을 편집한 경우 변경 사항을 적용하려면 가상 머신을 다시 시작해야 합니다.

9.16. 고급 가상 머신 관리

9.16.1. 가상 머신의 리소스 할당량 작업

가상 시스템의 리소스 할당량을 생성하고 관리합니다.

9.16.1.1. 가상 머신의 리소스 할당량 제한 설정

요청만 사용하는 리소스 할당량은 VM(가상 머신)에서 자동으로 작동합니다. 리소스 할당량이 제한을 사용하는 경우 VM에 리소스 제한을 수동으로 설정해야 합니다. 리소스 제한은 리소스 요청보다 100MiB 이상이어야 합니다.

절차

  1. VirtualMachine 매니페스트를 편집하여 VM에 대한 제한을 설정합니다. 예를 들어 다음과 같습니다.

    apiVersion: kubevirt.io/v1
    kind: VirtualMachine
    metadata:
      name: with-limits
    spec:
      running: false
      template:
        spec:
          domain:
    # ...
            resources:
              requests:
                memory: 128Mi
              limits:
                memory: 256Mi  1
    1
    limits.memory 값이 requests.memory 값보다 큰 100Mi 이상이므로 이 구성이 지원됩니다.
  2. VirtualMachine 매니페스트를 저장합니다.
9.16.1.2. 추가 리소스

9.16.2. 가상 머신용 노드 지정

노드 배치 규칙을 사용하여 특정 노드에 VM(가상 머신)을 배치할 수 있습니다.

9.16.2.1. 가상 머신의 노드 배치 정보

VM(가상 머신)이 적절한 노드에서 실행되도록 노드 배치 규칙을 구성할 수 있습니다. 다음과 같은 경우 이 작업을 수행할 수 있습니다.

  • 여러 개의 VM이 있습니다. 내결함성을 보장하기 위해 서로 다른 노드에서 실행하려고 합니다.
  • 두 개의 가상 머신이 있습니다. 중복 노드 간 라우팅을 방지하기 위해 VM을 동일한 노드에서 실행하려고 합니다.
  • VM에는 사용 가능한 모든 노드에 존재하지 않는 특정 하드웨어 기능이 필요합니다.
  • 노드에 기능을 추가하는 Pod가 있으며 해당 노드에 VM을 배치하여 해당 기능을 사용할 수 있습니다.
참고

가상 머신 배치는 워크로드에 대한 기존 노드 배치 규칙에 의존합니다. 워크로드가 구성 요소 수준의 특정 노드에서 제외되면 해당 노드에 가상 머신을 배치할 수 없습니다.

VirtualMachine 매니페스트의 spec 필드에 다음 규칙 유형을 사용할 수 있습니다.

nodeSelector
이 필드에서 지정하는 키-값 쌍으로 레이블이 지정된 노드에서 가상 머신을 예약할 수 있습니다. 노드에는 나열된 모든 쌍과 정확히 일치하는 라벨이 있어야 합니다.
유사성

더 많은 표현 구문을 사용하여 노드와 가상 머신의 일치 규칙을 설정할 수 있습니다. 예를 들어, 규칙을 엄격한 요구 사항이 아닌 기본 설정으로 지정할 수 있으므로 규칙이 충족되지 않은 경우에도 가상 머신을 예약할 수 있습니다. 가상 머신 배치에는 Pod 유사성, Pod 비유사성 및 노드 유사성이 지원됩니다. VirtualMachine 워크로드 유형이 Pod 오브젝트를 기반으로 하므로 Pod 유사성은 가상 머신에서 작동합니다.

참고

유사성 규칙은 스케줄링 중에만 적용됩니다. 제약 조건이 더 이상 충족되지 않는 경우 OpenShift Container Platform은 실행 중인 워크로드를 다시 예약하지 않습니다.

허용 오차
일치하는 테인트가 있는 노드에 가상 머신을 예약할 수 있습니다. 테인트가 노드에 적용되는 경우, 해당 노드는 테인트를 허용하는 가상 머신만 허용합니다.
9.16.2.2. 노드 배치의 예

다음 예시 YAML 파일 조각에서는 nodePlacement, affinitytolerations 필드를 사용하여 가상 머신의 노드 배치를 사용자 지정합니다.

9.16.2.2.1. 예: nodeSelector를 사용한 VM 노드 배치

이 예에서 가상 시스템에는 example-key-1 = example-value-1example-key-2 = example-value-2 레이블을 모두 포함하는 메타데이터가 있는 노드가 필요합니다.

주의

이 설명에 맞는 노드가 없으면 가상 머신이 예약되지 않습니다.

VM 매니페스트 예

metadata:
  name: example-vm-node-selector
apiVersion: kubevirt.io/v1
kind: VirtualMachine
spec:
  template:
    spec:
      nodeSelector:
        example-key-1: example-value-1
        example-key-2: example-value-2
...

9.16.2.2.2. 예: Pod 유사성 및 Pod 비유사성을 사용한 VM 노드 배치

이 예에서는 example-key-1 = example-value-1 레이블이 있는 실행 중인 pod가 있는 노드에 VM을 예약해야 합니다. 노드에 실행 중인 Pod가 없는 경우 VM은 예약되지 않습니다.

가능한 경우 example-key-2 = example-value-2 레이블이 있는 Pod가 있는 노드에 VM이 예약되지 않습니다. 그러나 모든 후보 노드에 이 레이블이 있는 Pod가 있는 경우 스케줄러는 이 제약 조건을 무시합니다.

VM 매니페스트 예

metadata:
  name: example-vm-pod-affinity
apiVersion: kubevirt.io/v1
kind: VirtualMachine
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution: 1
      - labelSelector:
          matchExpressions:
          - key: example-key-1
            operator: In
            values:
            - example-value-1
        topologyKey: kubernetes.io/hostname
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution: 2
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: example-key-2
              operator: In
              values:
              - example-value-2
          topologyKey: kubernetes.io/hostname
...

1
requiredDuringSchedulingIgnoredDuringExecution 규칙 유형을 사용하는 경우 제약 조건이 충족되지 않으면 VM이 예약되지 않습니다.
2
preferredDuringSchedulingIgnoredDuringExecution 규칙 유형을 사용하는 경우 필요한 모든 제약 조건이 충족되면 여전히 VM이 예약됩니다.
9.16.2.2.3. 예: 노드 선호도를 사용한 VM 노드 배치

이 예에서 VM은 example.io/example-key = example-value-1 레이블 또는 example.io/example-key = example-value-2 레이블이 있는 노드에 예약해야 합니다. 노드에 레이블 중 하나만 있는 경우 제약 조건이 충족됩니다. 레이블이 모두 없으면 VM이 예약되지 않습니다.

가능한 경우 스케줄러는 example-node-label-key = example-node-label-value 레이블이 있는 노드를 피합니다. 그러나 모든 후보 노드에 이 레이블이 있으면 스케줄러는 이 제약 조건을 무시합니다.

VM 매니페스트 예

metadata:
  name: example-vm-node-affinity
apiVersion: kubevirt.io/v1
kind: VirtualMachine
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution: 1
        nodeSelectorTerms:
        - matchExpressions:
          - key: example.io/example-key
            operator: In
            values:
            - example-value-1
            - example-value-2
      preferredDuringSchedulingIgnoredDuringExecution: 2
      - weight: 1
        preference:
          matchExpressions:
          - key: example-node-label-key
            operator: In
            values:
            - example-node-label-value
...

1
requiredDuringSchedulingIgnoredDuringExecution 규칙 유형을 사용하는 경우 제약 조건이 충족되지 않으면 VM이 예약되지 않습니다.
2
preferredDuringSchedulingIgnoredDuringExecution 규칙 유형을 사용하는 경우 필요한 모든 제약 조건이 충족되면 여전히 VM이 예약됩니다.
9.16.2.2.4. 예: 허용 오차를 사용한 VM 노드 배치

이 예에서는 가상 머신에 예약된 노드가 key=virtualization:NoSchedule 테인트로 레이블이 지정됩니다. 이 가상 머신에는 tolerations가 일치하므로 테인트된 노드에 예약할 수 있습니다.

참고

해당 테인트가 있는 노드에 스케줄링하는 데 테인트를 허용하는 가상 머신은 필요하지 않습니다.

VM 매니페스트 예

metadata:
  name: example-vm-tolerations
apiVersion: kubevirt.io/v1
kind: VirtualMachine
spec:
  tolerations:
  - key: "key"
    operator: "Equal"
    value: "virtualization"
    effect: "NoSchedule"
...

9.16.2.3. 추가 리소스

9.16.3. 인증서 교체 구성

기존 인증서를 교체하도록 인증서 교체 매개 변수를 구성합니다.

9.16.3.1. 인증서 교체 구성

웹 콘솔에서 또는 HyperConverged CR(사용자 정의 리소스)에 설치 후 OpenShift Virtualization을 설치하는 동안 이 작업을 수행할 수 있습니다.

절차

  1. 다음 명령을 실행하여 HyperConverged CR을 엽니다.

    $ oc edit hco -n openshift-cnv kubevirt-hyperconverged
  2. 다음 예와 같이 spec.certConfig 필드를 편집합니다. 시스템 과부하를 방지하려면 모든 값이 10분 이상인지 확인합니다. golang ParseDuration 형식을 준수하는 문자열로 모든 값을 표현합니다.

    apiVersion: hco.kubevirt.io/v1beta1
    kind: HyperConverged
    metadata:
     name: kubevirt-hyperconverged
     namespace: openshift-cnv
    spec:
      certConfig:
        ca:
          duration: 48h0m0s
          renewBefore: 24h0m0s 1
        server:
          duration: 24h0m0s  2
          renewBefore: 12h0m0s  3
    1
    ca.renewBefore의 값은 ca.duration 값보다 작거나 같아야 합니다.
    2
    server.duration의 값은 ca.duration 값보다 작거나 같아야 합니다.
    3
    server.renewBefore의 값은 server.duration 값보다 작거나 같아야 합니다.
  3. YAML 파일을 클러스터에 적용합니다.
9.16.3.2. 인증서 교체 매개변수 문제 해결

기본값이 다음 조건 중 하나와 충돌하지 않는 한 하나 이상의 certConfig 값을 삭제하면 기본값으로 되돌아갑니다.

  • ca.renewBefore의 값은 ca.duration 값보다 작거나 같아야 합니다.
  • server.duration의 값은 ca.duration 값보다 작거나 같아야 합니다.
  • server.renewBefore의 값은 server.duration 값보다 작거나 같아야 합니다.

기본값이 이러한 조건과 충돌하면 오류가 발생합니다.

다음 예제에서 server.duration 값을 제거하는 경우 기본값 24h0m0sca.duration 값보다 크므로 지정된 조건과 충돌합니다.

certConfig:
   ca:
     duration: 4h0m0s
     renewBefore: 1h0m0s
   server:
     duration: 4h0m0s
     renewBefore: 4h0m0s

이 경우 다음과 같은 오류 메시지가 표시됩니다.

error: hyperconvergeds.hco.kubevirt.io "kubevirt-hyperconverged" could not be patched: admission webhook "validate-hco.kubevirt.io" denied the request: spec.certConfig: ca.duration is smaller than server.duration

오류 메시지는 첫 번째 충돌만 표시합니다. 진행하기 전에 모든 certConfig 값을 검토합니다.

9.16.4. 가상 머신에 UEFI 모드 사용

UEFI(Unified Extensible Firmware Interface) 모드에서 VM(가상 머신)을 부팅할 수 있습니다.

9.16.4.1. 가상 머신의 UEFI 모드 정보

레거시 BIOS와 같은 UEFI(Unified Extensible Firmware Interface)는 컴퓨터가 시작될 때 하드웨어 구성 요소 및 운영 체제 이미지 파일을 초기화합니다. UEFI는 BIOS보다 최신 기능 및 사용자 정의 옵션을 지원하므로 부팅 시간이 단축됩니다.

ESP(EFI System Partition)라는 특수 파티션에 저장된 .efi 확장자로 파일에 초기화 및 시작에 대한 모든 정보를 저장합니다. ESP에는 컴퓨터에 설치된 운영 체제용 부트 로더 프로그램도 포함되어 있습니다.

9.16.4.2. UEFI 모드에서 가상 머신 부팅

VirtualMachine 매니페스트를 편집하여 UEFI 모드에서 부팅하도록 가상 머신을 구성할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.

절차

  1. VirtualMachine 매니페스트 파일을 편집하거나 생성합니다. spec.firmware.bootloader 스탠자를 사용하여 UEFI 모드를 설정합니다.

    보안 부팅이 활성화된 UEFI 모드에서 부팅

    apiversion: kubevirt.io/v1
    kind: VirtualMachine
    metadata:
      labels:
        special: vm-secureboot
      name: vm-secureboot
    spec:
      template:
        metadata:
          labels:
            special: vm-secureboot
        spec:
          domain:
            devices:
              disks:
              - disk:
                  bus: virtio
                name: containerdisk
            features:
              acpi: {}
              smm:
                enabled: true 1
            firmware:
              bootloader:
                efi:
                  secureBoot: true 2
    ...

    1
    OpenShift Virtualization에서는 UEFI 모드에서 Secure Boot를 사용하려면SMM(시스템 관리 모드)을 활성화해야 합니다.
    2
    OpenShift Virtualization에서는 UEFI 모드를 사용할 때 Secure Boot가 있거나 없는 VM을 지원합니다. Secure Boot가 활성화된 경우 UEFI 모드가 필요합니다. 그러나 Secure Boot를 사용하지 않고 UEFI 모드를 활성화할 수 있습니다.
  2. 다음 명령을 실행하여 클러스터에 매니페스트를 적용합니다.

    $ oc create -f <file_name>.yaml

9.16.5. 가상 머신에 대한 PXE 부팅 구성

OpenShift Virtualization에서는 PXE 부팅 또는 네트워크 부팅을 사용할 수 있습니다. 네트워크 부팅의 경우 로컬로 연결된 스토리지 장치 없이 컴퓨터에서 운영 체제 또는 기타 프로그램을 부팅 및 로드할 수 있습니다. 예를 들어, 새 호스트를 배포할 때 PXE 서버에서 원하는 OS 이미지를 선택할 수 있습니다.

9.16.5.1. 사전 요구 사항
  • Linux 브리지가 연결되어 있어야 합니다.
  • PXE 서버는 브리지와 동일한 VLAN에 연결되어 있어야 합니다.
9.16.5.2. 지정된 MAC 주소로 PXE 부팅

관리자는 PXE 네트워크에 대한 NetworkAttachmentDefinition 오브젝트를 생성한 후 네트워크를 통해 클라이언트를 부팅할 수 있습니다. 그런 다음 가상 머신 인스턴스 구성 파일에서 네트워크 연결 정의를 참조한 후 가상 머신 인스턴스를 시작할 수 있습니다. PXE 서버에 필요한 경우 가상 머신 인스턴스 구성 파일에 MAC 주소를 지정할 수도 있습니다.

사전 요구 사항

  • Linux 브리지가 연결되어 있어야 합니다.
  • PXE 서버는 브리지와 동일한 VLAN에 연결되어 있어야 합니다.

절차

  1. 클러스터에서 PXE 네트워크를 구성합니다.

    1. PXE 네트워크 pxe-net-conf에 대한 네트워크 연결 정의 파일을 만듭니다.

      apiVersion: "k8s.cni.cncf.io/v1"
      kind: NetworkAttachmentDefinition
      metadata:
        name: pxe-net-conf
      spec:
        config: '{
          "cniVersion": "0.3.1",
          "name": "pxe-net-conf",
          "plugins": [
            {
              "type": "cnv-bridge",
              "bridge": "br1",
              "vlan": 1 1
            },
            {
              "type": "cnv-tuning" 2
            }
          ]
        }'
      1
      선택 사항: VLAN 태그.
      2
      cnv-tuning 플러그인은 사용자 정의 MAC 주소를 지원합니다.
      참고

      VLAN이 요청된 액세스 포트를 통해 가상 머신 인스턴스가 브리지 br1에 연결됩니다.

  2. 이전 단계에서 만든 파일을 사용하여 네트워크 연결 정의를 생성합니다.

    $ oc create -f pxe-net-conf.yaml
  3. 인터페이스 및 네트워크에 대한 세부 정보를 포함하도록 가상 머신 인스턴스 구성 파일을 편집합니다.

    1. PXE 서버에 필요한 경우 네트워크 및 MAC 주소를 지정합니다. MAC 주소를 지정하지 않으면 값이 자동으로 할당됩니다.

      인터페이스가 먼저 부팅되도록 bootOrder1로 설정되어 있는지 확인하십시오. 이 예에서는 인터페이스가 <pxe-net>이라는 네트워크에 연결되어 있습니다.

      interfaces:
      - masquerade: {}
        name: default
      - bridge: {}
        name: pxe-net
        macAddress: de:00:00:00:00:de
        bootOrder: 1
      참고

      부팅 순서는 인터페이스 및 디스크에 대해 전역적입니다.

    2. 운영 체제가 프로비저닝되면 올바르게 부팅되도록 부팅 장치 번호를 디스크에 할당합니다.

      디스크의 bootOrder 값을 2로 설정합니다.

      devices:
        disks:
        - disk:
            bus: virtio
          name: containerdisk
          bootOrder: 2
    3. 네트워크를 이전에 생성한 네트워크 연결 정의에 연결하도록 지정합니다. 이 시나리오에서 <pxe-net><pxe-net-conf>라는 네트워크 연결 정의에 연결됩니다.

      networks:
      - name: default
        pod: {}
      - name: pxe-net
        multus:
          networkName: pxe-net-conf
  4. 가상 머신 인스턴스를 생성합니다.

    $ oc create -f vmi-pxe-boot.yaml

출력 예

  virtualmachineinstance.kubevirt.io "vmi-pxe-boot" created

  1. 가상 머신 인스턴스가 실행될 때까지 기다립니다.

    $ oc get vmi vmi-pxe-boot -o yaml | grep -i phase
      phase: Running
  2. VNC를 사용하여 가상 머신 인스턴스를 확인합니다.

    $ virtctl vnc vmi-pxe-boot
  3. 부팅 화면에서 PXE 부팅에 성공했는지 확인합니다.
  4. 가상 머신 인스턴스에 로그인합니다.

    $ virtctl console vmi-pxe-boot
  5. 가상 머신의 인터페이스 및 MAC 주소를 확인하고, 브릿지에 연결된 인터페이스에 MAC 주소가 지정되었는지 확인합니다. 이 예제에서는 IP 주소 없이 PXE 부팅에 eth1을 사용했습니다. 다른 인터페이스인 eth0은 OpenShift Container Platform에서 IP 주소를 가져왔습니다.

    $ ip addr

출력 예

...
3. eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
   link/ether de:00:00:00:00:de brd ff:ff:ff:ff:ff:ff

9.16.5.3. OpenShift Virtualization 네트워킹 용어집

OpenShift Virtualization은 사용자 정의 리소스 및 플러그인을 사용하여 고급 네트워킹 기능을 제공합니다.

다음 용어는 OpenShift Virtualization 설명서 전체에서 사용됩니다.

CNI(컨테이너 네트워크 인터페이스(Container Network Interface))
컨테이너 네트워크 연결에 중점을 둔 Cloud Native Computing Foundation 프로젝트입니다. OpenShift Virtualization에서는 CNI 플러그인을 사용하여 기본 Kubernetes 네트워킹 기능을 기반으로 빌드합니다.
Multus
Pod 또는 가상 머신에서 필요한 인터페이스를 사용할 수 있도록 여러 CNI가 존재할 수 있는 "메타" CNI 플러그인입니다.
CRD(사용자 정의 리소스 정의(Custom Resource Definition))
사용자 정의 리소스를 정의할 수 있는 Kubernetes API 리소스 또는 CRD API 리소스를 사용하여 정의한 오브젝트입니다.
네트워크 연결 정의 (NAD)
Pod, 가상 머신, 가상 머신 인스턴스를 하나 이상의 네트워크에 연결할 수 있는 Multus 프로젝트에서 도입한 CRD입니다.
노드 네트워크 구성 정책(NNCP)
노드에서 요청된 네트워크 구성에 대한 설명입니다. NodeNetworkConfigurationPolicy 매니페스트를 클러스터에 적용하는 방식으로 인터페이스 추가 및 제거를 포함하여 노드 네트워크 구성을 업데이트합니다.
PXE(Preboot eXecution Environment)
관리자가 네트워크를 통해 서버에서 클라이언트 머신을 부팅할 수 있는 인터페이스입니다. 네트워크 부팅을 통해 운영 체제 및 기타 소프트웨어를 클라이언트에 원격으로 로드할 수 있습니다.

9.16.6. 가상 머신에서 대규모 페이지 사용

대규모 페이지를 클러스터의 가상 머신 백업 메모리로 사용할 수 있습니다.

9.16.6.1. 사전 요구 사항
9.16.6.2. 대규모 페이지의 기능

메모리는 페이지라는 블록으로 관리됩니다. 대부분의 시스템에서 한 페이지는 4Ki입니다. 1Mi 메모리는 256페이지와 같고 1Gi 메모리는 256,000페이지에 해당합니다. CPU에는 하드웨어에서 이러한 페이지 목록을 관리하는 내장 메모리 관리 장치가 있습니다. TLB(Translation Lookaside Buffer)는 가상-물리적 페이지 매핑에 대한 소규모 하드웨어 캐시입니다. TLB에 하드웨어 명령어로 전달된 가상 주소가 있으면 매핑을 신속하게 확인할 수 있습니다. 가상 주소가 없으면 TLB 누락이 발생하고 시스템에서 소프트웨어 기반 주소 변환 속도가 느려져 성능 문제가 발생합니다. TLB 크기는 고정되어 있으므로 TLB 누락 가능성을 줄이는 유일한 방법은 페이지 크기를 늘리는 것입니다.

대규모 페이지는 4Ki보다 큰 메모리 페이지입니다. x86_64 아키텍처에서 일반적인 대규모 페이지 크기는 2Mi와 1Gi입니다. 다른 아키텍처에서는 크기가 달라집니다. 대규모 페이지를 사용하려면 애플리케이션이 인식할 수 있도록 코드를 작성해야 합니다. THP(투명한 대규모 페이지)에서는 애플리케이션 지식 없이 대규모 페이지 관리를 자동화하려고 하지만 한계가 있습니다. 특히 페이지 크기 2Mi로 제한됩니다. THP에서는 THP 조각 모음 작업으로 인해 메모리 사용률이 높아지거나 조각화가 발생하여 노드에서 성능이 저하될 수 있으며 이로 인해 메모리 페이지가 잠길 수 있습니다. 이러한 이유로 일부 애플리케이션은 THP 대신 사전 할당된 대규모 페이지를 사용하도록 설계(또는 권장)할 수 있습니다.

OpenShift Virtualization에서는 사전 할당된 대규모 페이지를 사용하도록 가상 머신을 구성할 수 있습니다.

9.16.6.3. 가상 머신용 대규모 페이지 구성

가상 머신 구성에 memory.hugepages.pageSizeresources.requests.memory 매개변수를 포함하여 사전 할당된 대규모 페이지를 사용하도록 가상 머신을 구성할 수 있습니다.

메모리 요청은 페이지 크기로 나눌 수 있어야합니다. 예를 들면 페이지 크기가 1Gi500Mi의 메모리는 요청할 수 없습니다.

참고

호스트와 게스트 OS의 메모리 레이아웃은 관련이 없습니다. 가상 머신 매니페스트에서 요청된 대규모 페이지가 QEMU에 적용됩니다. 게스트 내부의 대규모 페이지는 사용 가능한 가상 머신 인스턴스 메모리 양을 기준으로만 구성할 수 있습니다.

실행 중인 가상 머신을 편집하는 경우 변경 사항을 적용하려면 가상 머신을 재부팅해야 합니다.

사전 요구 사항

  • 노드에 사전 할당된 대규모 페이지가 구성되어 있어야 합니다.

절차

  1. 가상 머신 구성에서 spec.domainresources.requests.memorymemory.hugepages.pageSize 매개변수를 추가합니다. 다음 구성 스니펫에서는 가상 머신에서 각 페이지 크기가 1Gi인 총 4Gi의 메모리를 요청합니다.

    kind: VirtualMachine
    ...
    spec:
      domain:
        resources:
          requests:
            memory: "4Gi" 1
        memory:
          hugepages:
            pageSize: "1Gi" 2
    ...
    1
    가상 머신에 대해 요청된 총 메모리 양입니다. 이 값은 페이지 크기로 나눌 수 있어야 합니다.
    2
    각 대규모 페이지의 크기입니다. x86_64 아키텍처에 유효한 값은 1Gi2Mi입니다. 페이지 크기는 요청된 메모리보다 작아야 합니다.
  2. 가상 머신 구성을 적용합니다.

    $ oc apply -f <virtual_machine>.yaml

9.16.7. 가상 머신 전용 리소스 사용

성능 향상을 위해 CPU와 같은 노드 리소스를 가상 머신에 전용으로 지정할 수 있습니다.

9.16.7.1. 전용 리소스 정보

가상 머신에 전용 리소스를 사용하면 가상 머신의 워크로드가 다른 프로세스에서 사용하지 않는 CPU에 예약됩니다. 전용 리소스를 사용하면 가상 머신의 성능과 대기 시간 예측 정확도를 개선할 수 있습니다.

9.16.7.2. 사전 요구 사항
  • 노드에 CPU 관리자를 구성해야 합니다. 가상 머신 워크로드를 예약하기 전에 노드에 cpumanager = true 라벨이 있는지 확인하십시오.
  • 가상 머신의 전원을 꺼야 합니다.
9.16.7.3. 가상 머신 전용 리소스 활성화

세부 정보 탭에서 가상 머신 전용 리소스를 활성화합니다. Red Hat 템플릿에서 생성된 가상 머신은 전용 리소스로 구성할 수 있습니다.

절차

  1. OpenShift Container Platform 콘솔 의 사이드 메뉴에서 가상화 → VirtualMachine 를 클릭합니다.
  2. 가상 머신을 선택하여 VirtualMachine 세부 정보 페이지를 엽니다.
  3. Scheduling 탭에서 전용 리소스 옆에 있는 연필 아이콘을 클릭합니다.
  4. 전용 리소스(보장된 정책)를 사용하여 이 워크로드 예약을 선택합니다.
  5. 저장을 클릭합니다.

9.16.8. 가상 머신 예약

호환성을 위해 VM의 CPU 모델과 정책 특성이 노드에서 지원하는 CPU 모델 및 정책 특성과 일치하도록 하면 노드에 VM(가상 머신)을 예약할 수 있습니다.

9.16.8.1. 정책 특성

VM(가상 머신)을 노드에 예약할 때 호환성을 위해 일치하는 정책 특성과 CPU 기능을 지정하면 VM을 예약할 수 있습니다. VM에 지정되는 정책 특성에 따라 VM이 노드에서 예약되는 방식이 결정됩니다.

정책 특성설명

force

VM이 노드에 강제로 예약됩니다. 호스트 CPU에서 VM CPU를 지원하지 않는 경우에도 마찬가지입니다.

require

VM이 특정 CPU 모델 및 기능 사양으로 구성되지 않은 경우 VM에 적용되는 기본 정책입니다. 이 기본 정책 특성 또는 다른 정책 특성 중 하나를 사용하여 CPU 노드 검색을 지원하도록 노드를 구성하지 않으면 해당 노드에 VM이 예약되지 않습니다. 호스트 CPU가 VM의 CPU를 지원하거나 하이퍼바이저가 지원되는 CPU 모델을 에뮬레이션할 수 있어야 합니다.

optional

호스트의 물리적 머신 CPU에서 VM을 지원하는 경우 해당 VM이 노드에 추가됩니다.

disable

CPU 노드 검색을 통해 VM을 예약할 수 없습니다.

forbid

호스트 CPU에서 기능을 지원하고 CPU 노드 검색을 사용할 수 있는 경우에도 VM을 예약할 수 없습니다.

9.16.8.2. 정책 특성 및 CPU 기능 설정

각 VM(가상 머신)에 대한 정책 특성 및 CPU 기능을 설정하면 정책 및 기능에 따라 노드에 VM을 예약할 수 있습니다. 설정한 CPU 기능은 호스트 CPU의 지원 여부 또는 하이퍼바이저의 에뮬레이션 여부를 확인하기 위해 검증됩니다.

절차

  • VM 구성 파일의 domain 사양을 편집합니다. 다음 예제에서는 VM(가상 머신)에 대한 CPU 기능 및 require 정책을 설정합니다.

    apiVersion: kubevirt.io/v1
    kind: VirtualMachine
    metadata:
      name: myvm
    spec:
      template:
        spec:
          domain:
            cpu:
              features:
                - name: apic 1
                  policy: require 2
    1
    VM의 CPU 기능 이름입니다.
    2
    VM의 정책 특성입니다.
9.16.8.3. 지원되는 CPU 모델을 사용하여 가상 머신 예약

VM(가상 머신)의 CPU 모델을 구성하여 해당 CPU 모델이 지원되는 노드에 예약할 수 있습니다.

절차

  • 가상 머신 구성 파일의 domain 사양을 편집합니다. 다음 예는 VM에 대해 정의된 특정 CPU 모델을 보여줍니다.

    apiVersion: kubevirt.io/v1
    kind: VirtualMachine
    metadata:
      name: myvm
    spec:
      template:
        spec:
          domain:
            cpu:
              model: Conroe 1
    1
    VM의 CPU 모델입니다.
9.16.8.4. 호스트 모델을 사용하여 가상 머신 예약

VM(가상 머신)의 CPU 모델이 host-model로 설정되어 있으면 VM은 예약된 노드의 CPU 모델을 상속합니다.

절차

  • VM 구성 파일의 domain 사양을 편집합니다. 다음 예제에서는 가상 머신에 지정된 host-model을 보여줍니다.

    apiVersion: kubevirt/v1alpha3
    kind: VirtualMachine
    metadata:
      name: myvm
    spec:
      template:
        spec:
          domain:
            cpu:
              model: host-model 1
    1
    예약된 노드의 CPU 모델을 상속하는 VM입니다.

9.16.9. PCI 패스스루 구성

PCI(Peripheral Component Interconnect) 패스스루 기능을 사용하면 가상 머신에서 하드웨어 장치에 액세스하고 관리할 수 있습니다. PCI 패스스루가 구성되면 PCI 장치는 게스트 운영 체제에 물리적으로 연결된 것처럼 작동합니다.

클러스터 관리자는 oc CLI(명령줄 인터페이스)를 사용하여 클러스터에서 사용할 수 있는 호스트 장치를 노출하고 관리할 수 있습니다.

9.16.9.1. PCI 패스스루를 위한 호스트 장치 준비 정보

CLI를 사용하여 PCI 패스스루를 위한 호스트 장치를 준비하려면 MachineConfig 오브젝트를 생성하고 커널 인수를 추가하여 IOMMU(Input-Output Memory Management Unit)를 활성화합니다. PCI 장치를 VFIO(가상 기능 I/O) 드라이버에 연결한 다음 HyperConverged CR(사용자 정의 리소스)의 allowedHostDevices 필드를 편집하여 클러스터에 노출합니다. OpenShift Virtualization Operator를 처음 설치할 때 permittedHostDevices 목록이 비어 있습니다.

CLI를 사용하여 클러스터에서 PCI 호스트 장치를 제거하려면 HyperConverged CR에서 PCI 장치 정보를 삭제합니다.

9.16.9.1.1. IOMMU 드라이버를 활성화하려면 커널 인수 추가

커널에서 IOMMU(Input-Output Memory Management Unit) 드라이버를 활성화하려면 MachineConfig 개체를 생성하고 커널 인수를 추가합니다.

사전 요구 사항

  • OpenShift Container Platform 클러스터에 대한 관리자 권한을 보유하고 있어야 합니다.
  • Intel 또는 AMD CPU 하드웨어.
  • BIOS의 Directed I/O 확장용 Intel Virtualization Technology 또는 AMD IOMMU(Basic Input/Output System)가 활성화되어 있습니다.

절차

  1. 커널 인수를 식별하는 MachineConfig 오브젝트를 만듭니다. 다음 예제에서는 Intel CPU에 대한 커널 인수를 보여줍니다.

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: worker 1
      name: 100-worker-iommu 2
    spec:
      config:
        ignition:
          version: 3.2.0
      kernelArguments:
          - intel_iommu=on 3
    ...
    1
    새 커널 인수를 작업자 노드에만 적용합니다.
    2
    name은 머신 구성 및 그 용도 중 이 커널 인수의 순위(100)를 나타냅니다. AMD CPU가 있는 경우 커널 인수를 amd_iommu=on으로 지정합니다.
    3
    Intel CPU의 커널 인수를 intel_iommu로 식별합니다.
  2. MachineConfig 오브젝트를 만듭니다.

    $ oc create -f 100-worker-kernel-arg-iommu.yaml

검증

  • MachineConfig 오브젝트가 추가되었는지 확인합니다.

    $ oc get MachineConfig
9.16.9.1.2. VFIO 드라이버에 PCI 장치 바인딩

PCI 장치를 VFIO(Virtual Function I/O) 드라이버에 바인딩하려면 각 장치에서 vendor-IDdevice-ID 값을 가져오고 값으로 목록을 생성합니다. MachineConfig 오브젝트에 이 목록을 추가합니다. MachineConfig Operator는 PCI 장치가 있는 노드에 /etc/modprobe.d/vfio.conf를 생성하고 PCI 장치를 VFIO 드라이버에 바인딩합니다.

사전 요구 사항

  • CPU에 IOMMU를 사용하도록 커널 인수를 추가했습니다.

절차

  1. lspci 명령을 실행하여 PCI 장치의 vendor-IDdevice-ID를 가져옵니다.

    $ lspci -nnv | grep -i nvidia

    출력 예

    02:01.0 3D controller [0302]: NVIDIA Corporation GV100GL [Tesla V100 PCIe 32GB] [10de:1eb8] (rev a1)

  2. Virtual config 파일 100-worker-vfiopci.bu를 생성하여 PCI 장치를 VFIO 드라이버에 바인딩합니다.

    참고

    Butane에 대한 자세한 내용은 “Butane 을 사용하여 머신 구성 생성”을 참조하십시오.

    variant: openshift
    version: 4.11.0
    metadata:
      name: 100-worker-vfiopci
      labels:
        machineconfiguration.openshift.io/role: worker 1
    storage:
      files:
      - path: /etc/modprobe.d/vfio.conf
        mode: 0644
        overwrite: true
        contents:
          inline: |
            options vfio-pci ids=10de:1eb8 2
      - path: /etc/modules-load.d/vfio-pci.conf 3
        mode: 0644
        overwrite: true
        contents:
          inline: vfio-pci

    1
    새 커널 인수를 작업자 노드에만 적용합니다.
    2
    단일 장치를 VFIO 드라이버에 바인딩하려면 이전에 결정한 vendor-ID 값 (10de) 및 device-ID 값 (1eb8) 을 지정합니다. 공급업체 및 장치 정보를 사용하여 여러 장치 목록을 추가할 수 있습니다.
    3
    작업자 노드에서 vfio-pci 커널 모듈을 로드하는 파일입니다.
  3. Butane을 사용하여 작업자 노드로 전달할 구성이 포함된 MachineConfig 오브젝트 파일 100-worker-vfiopci.yaml을 생성합니다.

    $ butane 100-worker-vfiopci.bu -o 100-worker-vfiopci.yaml
  4. 작업자 노드에 MachineConfig 오브젝트를 적용합니다.

    $ oc apply -f 100-worker-vfiopci.yaml
  5. MachineConfig 오브젝트가 추가되었는지 확인합니다.

    $ oc get MachineConfig

    출력 예

    NAME                             GENERATEDBYCONTROLLER                      IGNITIONVERSION  AGE
    00-master                        d3da910bfa9f4b599af4ed7f5ac270d55950a3a1   3.2.0            25h
    00-worker                        d3da910bfa9f4b599af4ed7f5ac270d55950a3a1   3.2.0            25h
    01-master-container-runtime      d3da910bfa9f4b599af4ed7f5ac270d55950a3a1   3.2.0            25h
    01-master-kubelet                d3da910bfa9f4b599af4ed7f5ac270d55950a3a1   3.2.0            25h
    01-worker-container-runtime      d3da910bfa9f4b599af4ed7f5ac270d55950a3a1   3.2.0            25h
    01-worker-kubelet                d3da910bfa9f4b599af4ed7f5ac270d55950a3a1   3.2.0            25h
    100-worker-iommu                                                            3.2.0            30s
    100-worker-vfiopci-configuration                                            3.2.0            30s

검증

  • VFIO 드라이버가 로드되었는지 확인합니다.

    $ lspci -nnk -d 10de:

    출력은 VFIO 드라이버가 사용 중인지 확인합니다.

    출력 예

    04:00.0 3D controller [0302]: NVIDIA Corporation GP102GL [Tesla P40] [10de:1eb8] (rev a1)
            Subsystem: NVIDIA Corporation Device [10de:1eb8]
            Kernel driver in use: vfio-pci
            Kernel modules: nouveau

9.16.9.1.3. CLI를 사용하여 클러스터에 PCI 호스트 장치 노출

클러스터에 PCI 호스트 장치를 노출하려면 PCI 장치에 대한 세부 정보를 HyperConverged CR(사용자 정의 리소스)의 spec.permittedHostDevices 배열에 추가합니다.

절차

  1. 다음 명령을 실행하여 기본 편집기에서 HyperConverged CR을 편집합니다.

    $ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
  2. spec.permittedHostDevices.pciHostDevices 어레이에 PCI 장치 정보를 추가합니다. 예를 들어 다음과 같습니다.

    설정 파일 예

    apiVersion: hco.kubevirt.io/v1
    kind: HyperConverged
    metadata:
      name: kubevirt-hyperconverged
      namespace: openshift-cnv
    spec:
      permittedHostDevices: 1
        pciHostDevices: 2
        - pciDeviceSelector: "10DE:1DB6" 3
          resourceName: "nvidia.com/GV100GL_Tesla_V100" 4
        - pciDeviceSelector: "10DE:1EB8"
          resourceName: "nvidia.com/TU104GL_Tesla_T4"
        - pciDeviceSelector: "8086:6F54"
          resourceName: "intel.com/qat"
          externalResourceProvider: true 5
    ...

    1
    클러스터에서 사용할 수 있는 호스트 장치입니다.
    2
    노드에서 사용할 수 있는 PCI 장치 목록입니다.
    3
    vendor-IDdevice-ID는 PCI 장치를 식별해야 합니다.
    4
    PCI 호스트 장치의 이름입니다.
    5
    선택 사항: 이 필드를 true 로 설정하면 리소스가 외부 장치 플러그인에서 제공되었음을 나타냅니다. OpenShift Virtualization에서는 클러스터에서 이 장치를 사용할 수 있지만 할당 및 모니터링은 외부 장치 플러그인에 그대로 둡니다.
    참고

    위의 예제 스니펫은 이름이 nvidia.com/GV100GL_Tesla_V100이고 nvidia.com/TU104GL_Tesla_T4HyperConverged CR에서 허용된 호스트 장치 목록에 추가된 두 개의 PCI 호스트 장치를 보여줍니다. 이러한 장치는 OpenShift Virtualization에서 작동하도록 테스트 및 검증되었습니다.

  3. 변경 사항을 저장하고 편집기를 종료합니다.

검증

  • 다음 명령을 실행하여 PCI 호스트 장치가 노드에 추가되었는지 확인합니다. 예제 출력에서는 각각nvidia.com/GV100GL_Tesla_V100, nvidia.com/TU104GL_Tesla_T4, intel.com/qat 리소스 이름과 연결된 하나의 장치가 있음을 보여줍니다.

    $ oc describe node <node_name>

    출력 예

    Capacity:
      cpu:                            64
      devices.kubevirt.io/kvm:        110
      devices.kubevirt.io/tun:        110
      devices.kubevirt.io/vhost-net:  110
      ephemeral-storage:              915128Mi
      hugepages-1Gi:                  0
      hugepages-2Mi:                  0
      memory:                         131395264Ki
      nvidia.com/GV100GL_Tesla_V100   1
      nvidia.com/TU104GL_Tesla_T4     1
      intel.com/qat:                  1
      pods:                           250
    Allocatable:
      cpu:                            63500m
      devices.kubevirt.io/kvm:        110
      devices.kubevirt.io/tun:        110
      devices.kubevirt.io/vhost-net:  110
      ephemeral-storage:              863623130526
      hugepages-1Gi:                  0
      hugepages-2Mi:                  0
      memory:                         130244288Ki
      nvidia.com/GV100GL_Tesla_V100   1
      nvidia.com/TU104GL_Tesla_T4     1
      intel.com/qat:                  1
      pods:                           250

9.16.9.1.4. CLI를 사용하여 클러스터에서 PCI 호스트 장치 제거

클러스터에서 PCI 호스트 장치를 제거하려면 HyperConverged CR(사용자 정의 리소스)에서 해당 장치의 정보를 삭제합니다.

절차

  1. 다음 명령을 실행하여 기본 편집기에서 HyperConverged CR을 편집합니다.

    $ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
  2. 적절한 장치의 pciDeviceSelector,resourceNameexternalResourceProvider (해당되는 경우) 필드를 삭제하여 spec.permittedHostDevices.pciHostDevices 어레이에서 PCI 장치 정보를 제거합니다. 이 예에서는 intel.com/qat 리소스가 삭제되었습니다.

    설정 파일 예

    apiVersion: hco.kubevirt.io/v1
    kind: HyperConverged
    metadata:
      name: kubevirt-hyperconverged
      namespace: openshift-cnv
    spec:
      permittedHostDevices:
        pciHostDevices:
        - pciDeviceSelector: "10DE:1DB6"
          resourceName: "nvidia.com/GV100GL_Tesla_V100"
        - pciDeviceSelector: "10DE:1EB8"
          resourceName: "nvidia.com/TU104GL_Tesla_T4"
    ...

  3. 변경 사항을 저장하고 편집기를 종료합니다.

검증

  • 다음 명령을 실행하여 PCI 호스트 장치가 노드에서 제거되었는지 확인합니다. 예제 출력에서는 intel.com/qat 리소스 이름과 연결된 장치가 0개 있음을 보여줍니다.

    $ oc describe node <node_name>

    출력 예

    Capacity:
      cpu:                            64
      devices.kubevirt.io/kvm:        110
      devices.kubevirt.io/tun:        110
      devices.kubevirt.io/vhost-net:  110
      ephemeral-storage:              915128Mi
      hugepages-1Gi:                  0
      hugepages-2Mi:                  0
      memory:                         131395264Ki
      nvidia.com/GV100GL_Tesla_V100   1
      nvidia.com/TU104GL_Tesla_T4     1
      intel.com/qat:                  0
      pods:                           250
    Allocatable:
      cpu:                            63500m
      devices.kubevirt.io/kvm:        110
      devices.kubevirt.io/tun:        110
      devices.kubevirt.io/vhost-net:  110
      ephemeral-storage:              863623130526
      hugepages-1Gi:                  0
      hugepages-2Mi:                  0
      memory:                         130244288Ki
      nvidia.com/GV100GL_Tesla_V100   1
      nvidia.com/TU104GL_Tesla_T4     1
      intel.com/qat:                  0
      pods:                           250

9.16.9.2. PCI 패스스루의 가상 머신 구성

PCI 장치를 클러스터에 추가하고 나면 가상 머신에 할당할 수 있습니다. 이제 PCI 장치를 가상 머신에 물리적으로 연결된 것처럼 사용할 수 있습니다.

9.16.9.2.1. 가상 머신에 PCI 장치 할당

PCI 장치를 클러스터에서 사용할 수 있는 경우 가상 머신에 할당하고 PCI 패스스루를 활성화할 수 있습니다.

절차

  • 가상 시스템에 PCI 장치를 호스트 장치로 할당합니다.

    apiVersion: kubevirt.io/v1
    kind: VirtualMachine
    spec:
      domain:
        devices:
          hostDevices:
          - deviceName: nvidia.com/TU104GL_Tesla_T4 1
            name: hostdevices1

    1
    호스트 장치로 클러스터에서 허용되는 PCI 장치의 이름입니다. 가상 시스템은 이 호스트 장치에 액세스할 수 있습니다.

검증

  • 다음 명령을 사용하여 가상 시스템에서 호스트 장치를 사용할 수 있는지 확인합니다.

    $ lspci -nnk | grep NVIDIA

    출력 예

    $ 02:01.0 3D controller [0302]: NVIDIA Corporation GV100GL [Tesla V100 PCIe 32GB] [10de:1eb8] (rev a1)

9.16.9.3. 추가 리소스

9.16.10. vGPU 패스스루 구성

가상 머신은 가상 GPU(vGPU) 하드웨어에 액세스할 수 있습니다. 가상 머신에 vGPU를 할당하면 다음을 수행할 수 있습니다.

  • 기본 하드웨어 GPU의 일부에 액세스하여 가상 머신에서 높은 성능의 이점을 얻을 수 있습니다.
  • 리소스 집약적 I/O 작업 간소화.
중요

vGPU 패스스루는 베어 메탈 환경에서 실행되는 클러스터에 연결된 장치에만 할당할 수 있습니다.

9.16.10.1. 가상 머신에 vGPU 패스스루 장치 할당

OpenShift Container Platform 웹 콘솔을 사용하여 가상 머신에 vGPU 패스스루 장치를 할당합니다.

사전 요구 사항

  • 가상 머신을 중지해야 합니다.

절차

  1. OpenShift Container Platform 웹 콘솔 의 사이드 메뉴에서 가상화 → VirtualMachine 를 클릭합니다.
  2. 장치를 할당할 가상 머신을 선택합니다.
  3. 세부 정보 탭에서 GPU 장치를 클릭합니다.

    vGPU 장치를 호스트 장치로 추가하는 경우 VNC 콘솔을 사용하여 장치에 액세스할 수 없습니다.

  4. GPU 장치 추가를 클릭하고 Name 을 입력하고 장치 이름 목록에서 장치를 선택합니다.
  5. 저장을 클릭합니다.
  6. YAML 탭을 클릭하여 새 장치가 hostDevices 섹션의 클러스터 구성에 추가되었는지 확인합니다.
참고

사용자 지정 템플릿 또는 YAML 파일에서 생성된 가상 머신에 하드웨어 장치를 추가할 수 있습니다. Windows 10 또는 RHEL 7과 같은 특정 운영 체제에 대해 사전 제공 부팅 소스 템플릿에 장치를 추가할 수 없습니다.

클러스터에 연결된 리소스를 표시하려면 사이드 메뉴에서 컴퓨팅 → 하드웨어 장치를 클릭합니다.

9.16.10.2. 추가 리소스

9.16.11. 중재된 장치 구성

OpenShift Virtualization은 HyperConverged CR(사용자 정의 리소스)에 장치 목록을 제공하는 경우 가상 GPU(vGPU)와 같은 중재된 장치를 자동으로 생성합니다.

중요

중재된 장치의 선언적 구성은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

9.16.11.1. NVIDIA GPU Operator 사용 정보

NVIDIA GPU Operator는 OpenShift Container Platform 클러스터에서 NVIDIA GPU 리소스를 관리하고 부트스트랩 GPU 노드와 관련된 작업을 자동화합니다. GPU는 클러스터의 특수 리소스이므로 애플리케이션 워크로드를 GPU에 배포하기 전에 일부 구성 요소를 설치해야 합니다. 이러한 구성 요소에는 컴퓨팅 통합 장치 아키텍처(ECDHEDA), Kubernetes 장치 플러그인, 컨테이너 런타임 등을 활성화하는 NVIDIA 드라이버(자동 노드 레이블링, 모니터링 등)가 포함됩니다.

참고

NVIDIA GPU Operator는 NVIDIA에서만 지원됩니다. NVIDIA에서 지원을 얻는 방법에 대한 자세한 내용은 NVIDIA에서 지원을 참조하십시오.

OpenShift Container Platform OpenShift Virtualization에서 GPU를 활성화하는 방법에는 여기에 설명된 OpenShift Container Platform 네이티브 방법과 NVIDIA GPU Operator를 사용하는 두 가지 방법이 있습니다.

NVIDIA GPU Operator는 OpenShift Container Platform OpenShift Virtualization이 OpenShift Container Platform에서 실행되는 가상화된 워크로드에 GPU를 노출할 수 있는 Kubernetes Operator입니다. 사용자는 GPU 지원 가상 머신을 쉽게 프로비저닝 및 관리할 수 있으므로 다른 워크로드와 동일한 플랫폼에서 복잡한 AI/머신 학습(AI/ML) 워크로드를 실행할 수 있습니다. 또한 인프라의 GPU 용량을 쉽게 확장할 수 있어 GPU 기반 워크로드를 빠르게 확장할 수 있습니다.

NVIDIA GPU Operator를 사용하여 GPU 가속 VM을 실행하기 위한 작업자 노드를 프로비저닝하는 방법에 대한 자세한 내용은 OpenShift Virtualization을 사용하는 NVIDIA GPU Operator를 참조하십시오.

9.16.11.2. OpenShift Virtualization에서 가상 GPU 사용 정보

일부 GPU(그래픽 처리 장치) 카드에서는 가상 GPU(vGPU) 생성을 지원합니다. 관리자가 HyperConverged CR(사용자 정의 리소스)에서 구성 세부 정보를 제공하는 경우 OpenShift Virtualization에서 vGPU 및 기타 중재 장치를 자동으로 생성할 수 있습니다. 이 자동화는 대규모 클러스터에 특히 유용합니다.

참고

기능 및 지원 세부 사항은 하드웨어 벤더의 설명서를 참조하십시오.

중재된 장치
하나 이상의 가상 장치로 분할되는 물리적 장치입니다. vGPU는 중재 장치(mdev) 유형입니다. 물리 GPU의 성능은 가상 장치로 나뉩니다. 중재 장치를 하나 이상의 VM(가상 머신)에 할당할 수 있지만 게스트 수는 GPU와 호환되어야 합니다. 일부 GPU는 여러 게스트를 지원하지 않습니다.
9.16.11.2.1. 사전 요구 사항
9.16.11.2.2. 구성 개요

중재된 장치를 구성할 때 관리자는 다음 작업을 완료해야 합니다.

  • 중재된 장치를 만듭니다.
  • 중재된 장치를 클러스터에 노출합니다.

HyperConverged CR에는 두 작업을 모두 수행하는 API가 포함되어 있습니다.

중재된 장치 생성

...
spec:
  mediatedDevicesConfiguration:
    mediatedDevicesTypes: 1
    - <device_type>
    nodeMediatedDeviceTypes: 2
    - mediatedDevicesTypes: 3
      - <device_type>
      nodeSelector: 4
        <node_selector_key>: <node_selector_value>
...

1
필수: 클러스터의 글로벌 설정을 구성합니다.
2
선택 사항: 특정 노드 또는 노드 그룹의 글로벌 구성을 재정의합니다. 글로벌 mediatedDevicesTypes 구성과 함께 사용해야 합니다.
3
nodeMediatedDeviceTypes 를 사용하는 경우 필수 항목입니다. 지정된 노드의 글로벌 mediatedDevicesTypes 구성을 덮어씁니다.
4
nodeMediatedDeviceTypes 를 사용하는 경우 필수 항목입니다. 키:값 쌍을 포함해야 합니다.

클러스터에 미디어된 장치 노출

...
  permittedHostDevices:
    mediatedDevices:
    - mdevNameSelector: GRID T4-2Q 1
      resourceName: nvidia.com/GRID_T4-2Q 2
...

1
호스트의 이 값에 매핑되는 중재 장치를 노출합니다.
참고

/sys/bus/pci/devices/<slot>:<bus>:<domain>.<function>/mdev_supported_types/<type>/name, 시스템의 올바른 값을 확인하여 장치가 지원하는 중재 장치 유형을 확인할 수 있습니다.

예를 들어 nvidia-231 유형의 이름 파일에는 선택기 문자열 GRID T4-2Q 가 포함되어 있습니다. GRID T4-2QmdevNameSelector 값으로 사용하면 노드에서 nvidia-231 유형을 사용할 수 있습니다.

2
resourceName 은 노드에 할당된 것과 일치해야 합니다. 다음 명령을 사용하여 resourceName 을 찾습니다.
$ oc get $NODE -o json \
  | jq '.status.allocatable \
    | with_entries(select(.key | startswith("nvidia.com/"))) \
    | with_entries(select(.value != "0"))'
9.16.11.2.3. 노드에 vGPUs를 할당하는 방법

각 물리적 장치에 대해 OpenShift Virtualization은 다음 값을 구성합니다.

  • 단일 mdev 유형.
  • 선택한 mdev 유형의 최대 인스턴스 수입니다.

클러스터 아키텍처는 장치를 생성하고 노드에 할당하는 방법에 영향을 미칩니다.

노드당 여러 카드가 있는 대규모 클러스터

유사한 vGPU 유형을 지원할 수 있는 여러 카드가 있는 노드에서 관련 장치 유형은 라운드 로빈 방식으로 생성됩니다. 예를 들어 다음과 같습니다.

...
mediatedDevicesConfiguration:
  mediatedDevicesTypes:
  - nvidia-222
  - nvidia-228
  - nvidia-105
  - nvidia-108
...

이 시나리오에서 각 노드에는 두 개의 카드가 있으며 둘 다 다음 vGPU 유형을 지원합니다.

nvidia-105
...
nvidia-108
nvidia-217
nvidia-299
...

각 노드에서 OpenShift Virtualization은 다음과 같은 vGPU를 생성합니다.

  • 첫 번째 카드에 16 vGPU 유형의 nvidia-105입니다.
  • 두 번째 카드에 nvidia-108 유형의 2 vGPUs.
하나의 노드에는 하나 이상의 요청된 vGPU 유형을 지원하는 단일 카드가 있습니다.

OpenShift Virtualization에서는 mediatedDevicesTypes 목록에서 먼저 지원되는 유형을 사용합니다.

예를 들어 노드 카드의 카드는 nvidia-223nvidia-224 를 지원합니다. 다음과 같은 mediatedDevicesTypes 목록이 구성되어 있습니다.

...
mediatedDevicesConfiguration:
  mediatedDevicesTypes:
  - nvidia-22
  - nvidia-223
  - nvidia-224
...

이 예에서 OpenShift Virtualization에서는 nvidia-223 유형을 사용합니다.

9.16.11.2.4. 중재된 장치 변경 및 제거 정보

클러스터의 중재 장치 구성은 다음을 통해 OpenShift Virtualization으로 업데이트할 수 있습니다.

  • HyperConverged CR을 편집하고 mediatedDevicesTypes 스탠자의 내용을 변경합니다.
  • node MediatedDeviceTypes 노드 선택기와 일치하는 노드 레이블 변경
  • HyperConverged CR의 spec.mediatedDevicesConfigurationspec.permittedHostDevices 스탠자에서 장치 정보를 제거합니다.

    참고

    spec.mediatedDevicesConfiguration 스탠자에서 제거하지 않고 spec.permittedHostDevices 스탠자에서 장치 정보를 제거하는 경우 동일한 노드에 새로운 중재 장치 유형을 생성할 수 없습니다. 중재된 장치를 올바르게 제거하려면 두 스탠자 모두에서 장치 정보를 제거하십시오.

특정 변경 사항에 따라 이러한 작업으로 인해 OpenShift Virtualization에서 중재된 장치를 재구성하거나 클러스터 노드에서 제거합니다.

9.16.11.2.5. 중재된 장치 준비

중재 장치를 구성하려면 먼저 IOMMU(Input-Output Memory Management Unit) 드라이버를 활성화해야 합니다.

9.16.11.2.5.1. IOMMU 드라이버를 활성화하려면 커널 인수 추가

커널에서 IOMMU(Input-Output Memory Management Unit) 드라이버를 활성화하려면 MachineConfig 개체를 생성하고 커널 인수를 추가합니다.

사전 요구 사항

  • OpenShift Container Platform 클러스터에 대한 관리자 권한을 보유하고 있어야 합니다.
  • Intel 또는 AMD CPU 하드웨어.
  • BIOS의 Directed I/O 확장용 Intel Virtualization Technology 또는 AMD IOMMU(Basic Input/Output System)가 활성화되어 있습니다.

절차

  1. 커널 인수를 식별하는 MachineConfig 오브젝트를 만듭니다. 다음 예제에서는 Intel CPU에 대한 커널 인수를 보여줍니다.

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: worker 1
      name: 100-worker-iommu 2
    spec:
      config:
        ignition:
          version: 3.2.0
      kernelArguments:
          - intel_iommu=on 3
    ...
    1
    새 커널 인수를 작업자 노드에만 적용합니다.
    2
    name은 머신 구성 및 그 용도 중 이 커널 인수의 순위(100)를 나타냅니다. AMD CPU가 있는 경우 커널 인수를 amd_iommu=on으로 지정합니다.
    3
    Intel CPU의 커널 인수를 intel_iommu로 식별합니다.
  2. MachineConfig 오브젝트를 만듭니다.

    $ oc create -f 100-worker-kernel-arg-iommu.yaml

검증

  • MachineConfig 오브젝트가 추가되었는지 확인합니다.

    $ oc get MachineConfig
9.16.11.2.6. 중재된 장치 추가 및 제거

중재된 장치를 추가하거나 제거할 수 있습니다.

9.16.11.2.6.1. 중재된 장치 생성 및 노출

HyperConverged CR(사용자 정의 리소스)을 편집하여 가상 GPU(vGPU)와 같은 중재된 장치를 노출 및 생성할 수 있습니다.

사전 요구 사항

  • IOMMU(Input-Output Memory Management Unit) 드라이버를 활성화했습니다.

절차

  1. 다음 명령을 실행하여 기본 편집기에서 HyperConverged CR을 편집합니다.

    $ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
  2. HyperConverged CR 사양에 중재된 장치 정보를 추가하여 mediatedDevicesConfigurationallowedHostDevices 스탠자를 포함하도록 합니다. 예를 들어 다음과 같습니다.

    설정 파일 예

    apiVersion: hco.kubevirt.io/v1
    kind: HyperConverged
    metadata:
      name: kubevirt-hyperconverged
      namespace: openshift-cnv
    spec:
      mediatedDevicesConfiguration: <.>
        mediatedDevicesTypes: <.>
        - nvidia-231
        nodeMediatedDeviceTypes: <.>
        - mediatedDevicesTypes: <.>
          - nvidia-233
          nodeSelector:
            kubernetes.io/hostname: node-11.redhat.com
      permittedHostDevices: <.>
        mediatedDevices:
        - mdevNameSelector: GRID T4-2Q
          resourceName: nvidia.com/GRID_T4-2Q
        - mdevNameSelector: GRID T4-8Q
          resourceName: nvidia.com/GRID_T4-8Q
    ...

    <.>는 미디어 장치를 생성합니다. <.> Required: Global mediatedDevicesTypes configuration. <.> 선택 사항: 특정 노드의 글로벌 구성을 재정의합니다. <.> nodeMediatedDeviceTypes 를 사용하는 경우 필요합니다. <.> 클러스터에 미디어 지정된 장치를 노출합니다.

  3. 변경 사항을 저장하고 편집기를 종료합니다.

검증

  • 다음 명령을 실행하여 장치가 특정 노드에 추가되었는지 확인할 수 있습니다.

    $ oc describe node <node_name>
9.16.11.2.6.2. CLI를 사용하여 클러스터에서 중재된 장치 제거

클러스터에서 중재된 장치를 제거하려면 HyperConverged CR(사용자 정의 리소스)에서 해당 장치의 정보를 삭제합니다.

절차

  1. 다음 명령을 실행하여 기본 편집기에서 HyperConverged CR을 편집합니다.

    $ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
  2. HyperConverged CR의 spec.mediatedDevicesConfigurationspec.permittedHostDevices 스탠자에서 장치 정보를 제거합니다. 두 항목을 모두 제거하면 나중에 동일한 노드에 새로운 중재 장치 유형을 생성할 수 있습니다. 예를 들어 다음과 같습니다.

    설정 파일 예

    apiVersion: hco.kubevirt.io/v1
    kind: HyperConverged
    metadata:
      name: kubevirt-hyperconverged
      namespace: openshift-cnv
    spec:
      mediatedDevicesConfiguration:
        mediatedDevicesTypes: 1
          - nvidia-231
      permittedHostDevices:
        mediatedDevices: 2
        - mdevNameSelector: GRID T4-2Q
          resourceName: nvidia.com/GRID_T4-2Q

    1
    nvidia-231 장치 유형을 제거하려면 mediatedDevicesTypes 배열에서 삭제합니다.
    2
    GRID T4-2Q 장치를 제거하려면 mdevNameSelector 필드 및 해당 resourceName 필드를 삭제합니다.
  3. 변경 사항을 저장하고 편집기를 종료합니다.
9.16.11.3. 중재 장치 사용

vGPU는 중재된 장치 유형입니다. 물리적 GPU의 성능은 가상 장치로 나뉩니다. 중재 장치를 하나 이상의 가상 머신에 할당할 수 있습니다.

9.16.11.3.1. 가상 머신에 중재된 장치 할당

가상 GPU(vGPU)와 같은 중재 장치를 가상 머신에 할당합니다.

사전 요구 사항

  • 조정 장치는 HyperConverged 사용자 정의 리소스에 구성됩니다.

절차

  • VirtualMachine 매니페스트의 spec.domain.devices.gpus 스탠자를 편집하여 중재된 장치를 VM(가상 머신)에 할당합니다.

    가상 머신 매니페스트 예

    apiVersion: kubevirt.io/v1
    kind: VirtualMachine
    spec:
      domain:
        devices:
          gpus:
          - deviceName: nvidia.com/TU104GL_Tesla_T4 1
            name: gpu1 2
          - deviceName: nvidia.com/GRID_T4-1Q
            name: gpu2

    1
    중재된 장치와 관련된 리소스 이름입니다.
    2
    VM에서 장치를 식별하는 이름입니다.

검증

  • 가상 머신에서 장치를 사용할 수 있는지 확인하려면 VirtualMachine 매니페스트의 deviceName 값으로 < device_name >을 대체하십시오.

    $ lspci -nnk | grep <device_name>
9.16.11.4. 추가 리소스

9.16.12. 워치독 구성

워치독 장치에 대해 VM(가상 머신)을 구성하고, 워치독을 설치한 후 워치독 서비스를 시작하여 워치독을 노출합니다.

9.16.12.1. 사전 요구 사항
  • 가상 머신에는 i6300esb 워치독 장치에 대한 커널 지원이 있어야 합니다. RHEL(Red Hat Enterprise Linux) 이미지는 i6300esb를 지원합니다.
9.16.12.2. 워치독 장치 정의

운영 체제(OS)가 더 이상 응답하지 않을 때 워치독이 진행되는 방식을 정의합니다.

표 9.5. 사용 가능한 작업

poweroff

VM(가상 시스템)의 전원이 즉시 꺼집니다. spec.runningtrue로 설정되었거나 spec.runStrategymanual로 설정되지 않은 경우 VM이 재부팅됩니다.

reset

VM이 재부팅되고 게스트 OS가 반응할 수 없습니다. 게스트 OS가 재부팅하는 데 필요한 시간은 활성 프로브가 시간 초과될 수 있으므로 이 옵션을 사용하지 않습니다. 클러스터 수준 보호에서 활성 프로브가 실패하고 강제로 다시 예약하는 경우 이 시간 초과로 VM을 재부팅하는 시간을 연장할 수 있습니다.

shutdown

VM은 모든 서비스를 중지하여 정상적으로 전원을 끕니다.

절차

  1. 다음 콘텐츠를 사용하여 YAML 파일을 생성합니다.

    apiVersion: kubevirt.io/v1
    kind: VirtualMachine
    metadata:
      labels:
        kubevirt.io/vm: vm2-rhel84-watchdog
      name: <vm-name>
    spec:
      running: false
      template:
        metadata:
         labels:
            kubevirt.io/vm: vm2-rhel84-watchdog
        spec:
          domain:
            devices:
              watchdog:
                name: <watchdog>
                i6300esb:
                  action: "poweroff" 1
    ...
    1
    watchdog 작업 (poweroff, reset, 또는 shutdown)을 지정합니다.

    위의 예제에서는 poweroff 작업을 사용하여 RHEL8 VM에서 i6300esb 워치독 장치를 구성하고 장치를 /dev/watchdog로 노출합니다.

    이제 워치독 바이너리에서 이 장치를 사용할 수 있습니다.

  2. 다음 명령을 실행하여 클러스터에 YAML 파일을 적용합니다.

    $ oc apply -f <file_name>.yaml
중요

이 절차는 워치독 기능을 테스트하는 데만 제공되며 프로덕션 시스템에서 실행해서는 안 됩니다.

  1. 다음 명령을 실행하여 VM이 워치독 장치에 연결되어 있는지 확인합니다.

    $ lspci | grep watchdog -i
  2. 다음 명령 중 하나를 실행하여 워치독이 활성 상태인지 확인합니다.

    • 커널 패닉을 트리거합니다.

      # echo c > /proc/sysrq-trigger
    • 워치독 서비스를 종료합니다.

      # pkill -9 watchdog
9.16.12.3. 워치독 장치 설치

가상 머신에 watchdog 패키지를 설치하고 워치독 서비스를 시작합니다.

절차

  1. root 사용자로 watchdog 패키지 및 종속성을 설치합니다.

    # yum install watchdog
  2. /etc/watchdog.conf 파일에서 다음 행의 주석을 제거한 후 변경 사항을 저장합니다.

    #watchdog-device = /dev/watchdog
  3. 워치독 서비스가 부팅 시 시작되도록 활성화합니다.

    # systemctl enable --now watchdog.service
9.16.12.4. 추가 리소스

9.16.13. 사전 정의된 부팅 소스 자동 가져오기 및 업데이트

시스템 정의이고 OpenShift Virtualization 또는 사용자가 생성한 사용자 정의 에 포함된 부팅 소스를 사용할 수 있습니다. 시스템 정의 부팅 소스 가져오기 및 업데이트는 제품 기능 게이트에 의해 제어됩니다. 기능 게이트를 사용하여 업데이트를 사용, 비활성화 또는 다시 활성화할 수 있습니다. 사용자 정의 부팅 소스는 제품 기능 게이트에 의해 제어되지 않으며 자동 가져오기 및 업데이트를 선택하거나 옵트아웃하기 위해 개별적으로 관리되어야 합니다.

중요

버전 4.10부터 OpenShift Virtualization은 수동으로 비활성화하거나 기본 스토리지 클래스를 설정하지 않는 한 부팅 소스를 자동으로 가져오고 업데이트합니다.

버전 4.10으로 업그레이드하는 경우, 버전 4.9 또는 이전 버전에서 부팅 소스에 대한 자동 가져오기 및 업데이트를 수동으로 활성화해야 합니다.

9.16.13.1. 자동 부팅 소스 업데이트 활성화

OpenShift Virtualization 4.9 또는 이전 버전에서 부팅 소스가 있는 경우 이러한 부팅 소스에 대한 자동 업데이트를 수동으로 활성화해야 합니다. OpenShift Virtualization 4.10 이상의 모든 부팅 소스는 기본적으로 자동으로 업데이트됩니다.

자동 부팅 소스 가져오기 및 업데이트를 활성화하려면 자동으로 업데이트하려는 각 부팅 소스에 대해 cdi.kubevirt.io/dataImportCron 필드를 true 로 설정합니다.

절차

  • 부팅 소스에 대한 자동 업데이트를 활성화하려면 다음 명령을 사용하여 데이터 소스에 dataImportCron 레이블을 적용합니다.

    $ oc label --overwrite DataSource rhel8 -n openshift-virtualization-os-images cdi.kubevirt.io/dataImportCron=true 1
    1
    true 를 지정하면 rhel8 부팅 소스의 자동 업데이트가 실행됩니다.
9.16.13.2. 자동 부팅 소스 업데이트 비활성화

자동 부팅 소스 가져오기 및 업데이트를 비활성화하면 연결이 끊긴 환경의 로그 수를 줄이거나 리소스 사용량을 줄이는 데 유용할 수 있습니다.

자동 부팅 소스 가져오기 및 업데이트를 비활성화하려면 HyperConverged CR(사용자 정의 리소스)의 spec.featureGates.enableCommonBootImageImport 필드를 false 로 설정합니다.

참고

사용자 정의 부팅 소스는 이 설정의 영향을 받지 않습니다.

절차

  • 다음 명령을 사용하여 자동 부팅 소스 업데이트를 비활성화합니다.

    $ oc patch hco kubevirt-hyperconverged -n openshift-cnv \
     --type json -p '[{"op": "replace", "path": "/spec/featureGates/enableCommonBootImageImport", \
     "value": false}]'
9.16.13.3. 자동 부팅 소스 업데이트 다시 활성화

이전에 자동 부팅 소스 업데이트를 비활성화한 경우 기능을 수동으로 다시 활성화해야 합니다. HyperConverged CR(사용자 정의 리소스)에서 spec.featureGates.enableCommonBootImageImport 필드를 true 로 설정합니다.

절차

  • 다음 명령을 사용하여 자동 업데이트를 다시 활성화합니다.

    $ oc patch hco kubevirt-hyperconverged -n openshift-cnv --type json -p '[{"op": "replace", "path": "/spec/featureGates/enableCommonBootImageImport", "value": true}]'
9.16.13.4. 사용자 정의 부팅 소스 업데이트를 위한 스토리지 클래스 구성

사용자 정의 부팅 소스에 대해 자동 가져오기 및 업데이트를 허용하는 스토리지 클래스를 구성할 수 있습니다.

절차

  1. HyperConverged CR(사용자 정의 리소스)을 편집하여 새 storageClassName 을 정의합니다.

    apiVersion: hco.kubevirt.io/v1beta1
    kind: HyperConverged
    metadata:
      name: kubevirt-hyperconverged
    spec:
      dataImportCronTemplates:
      - metadata:
          name: rhel8-image-cron
        spec:
          template:
            spec:
              storageClassName: <appropriate_class_name>
    ...
  2. 다음 명령을 실행하여 새 기본 스토리지 클래스를 설정합니다.

    $ oc patch storageclass <current_default_storage_class> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
    $ oc patch storageclass <appropriate_storage_class> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
9.16.13.5. 사용자 정의 부팅 소스에 대한 자동 업데이트 활성화

OpenShift Virtualization은 기본적으로 시스템 정의 부팅 소스를 자동으로 업데이트하지만 사용자 정의 부팅 소스를 자동으로 업데이트하지는 않습니다. HyperConverged CR(사용자 정의 리소스)을 편집하여 사용자 정의 부팅 소스에서 자동 가져오기 및 업데이트를 수동으로 활성화해야 합니다.

프로세스

  1. 다음 명령을 사용하여 편집할 HyperConverged CR을 엽니다.

    $ oc edit -n openshift-cnv HyperConverged
  2. HyperConverged CR을 편집하여 dataImportCronTemplates 섹션에 적절한 템플릿 및 부팅 소스를 추가합니다. 예를 들어 다음과 같습니다.

    CentOS 7의 예

    apiVersion: hco.kubevirt.io/v1beta1
    kind: HyperConverged
    metadata:
      name: kubevirt-hyperconverged
    spec:
      dataImportCronTemplates:
      - metadata:
          name: centos7-image-cron
          annotations:
            cdi.kubevirt.io/storage.bind.immediate.requested: "true" 1
        spec:
          schedule: "0 */12 * * *" 2
          template:
            spec:
              source:
                registry: 3
                  url: docker://quay.io/containerdisks/centos:7-2009
              storage:
                resources:
                  requests:
                    storage: 10Gi
          managedDataSource: centos7 4
          retentionPolicy: "None" 5

    1
    이 주석은 volumeBindingModeWaitForFirstConsumer 로 설정된 스토리지 클래스에 필요합니다.
    2
    cron 형식으로 지정된 작업의 스케줄입니다.
    3
    레지스트리 소스에서 데이터 볼륨을 생성하려면 을 사용합니다. 노드 docker 캐시를 기반으로 하는 노드 pullMethod 가 아닌 기본 pod pullMethod 를 사용합니다. 노드 Docker 캐시는 Container.Image 를 통해 레지스트리 이미지를 사용할 수 있지만 CDI 가져오기자는 액세스할 권한이 없는 경우에 유용합니다.
    4
    사용자 지정 이미지를 사용 가능한 부팅 소스로 감지하려면 이미지의 managedDataSource 의 이름이 VM 템플릿 YAML 파일의 spec.dataVolumeTemplates.spec.sourceRef.name 에 있는 템플릿의 DataSource 이름과 일치해야 합니다.
    5
    모두 사용하여 cron 작업이 삭제될 때 데이터 볼륨 및 데이터 소스를 유지합니다. cron 작업이 삭제될 때 데이터 볼륨 및 데이터 소스를 삭제하려면 None 을 사용합니다.