2.4. 확인된 문제
- OpenShift Container Platform 클러스터에서 OVN-Kubernetes를 기본 CNI(Container Network Interface) 공급자로 사용하는 경우, OVN-Kubernetes의 호스트 네트워크 토폴로지 변경으로 인해 호스트의 기본 인터페이스에 Linux 브리지 또는 본딩을 연결할 수 없습니다. 해결 방법으로 호스트에 연결된 보조 네트워크 인터페이스를 사용하거나 OpenShift SDN 기본 CNI 공급자로 전환할 수 있습니다. (BZ#1887456)
-
웹 콘솔을 사용하여 VMware VDDK(가상 디스크 개발 키트) 이미지를
openshift-cnv/v2v-vmware구성 맵에 추가하면 관리 리소스라는 오류 메시지가 표시됩니다. 이 오류는 무시해도 됩니다. 저장을 클릭하여 구성 맵을 저장합니다. (BZ#1884538) - 노드가 제거될 때(예: OpenShift Container Platform 클러스터 업그레이드 중 노드가 유지보수 모드에 배치된 경우) 가상 머신이 한 번이 아닌 두 번 마이그레이션됩니다. (BZ#1888790)
- 업그레이드 후 운영 체제 워크로드당 템플릿이 두 개 이상 있을 수 있습니다. 기본 운영 체제(OS) 이미지 기능을 사용하여 복제된 PVC에서 Microsoft Windows 가상 머신을 생성할 때 OS에 올바른 워크로드 값이 정의되어 있어야 합니다. 웹 콘솔에 (사용 가능한 소스) 라벨이 표시되는 경우에도 잘못된 Workload 값을 선택하면 기본 OS 이미지를 사용할 수 없습니다. 기본 OS 이미지는 최신 템플릿에 연결되어 있지만 마법사는 기본 OS 이미지를 지원하도록 구성되지 않은 이전 템플릿을 사용할 수 있습니다. Windows 2010 시스템은 Desktop 의 워크로드 값만 지원하며 Windows 2012, Windows 2016 및 Windows 2019는 Server 의 워크로드 값만 지원합니다. (BZ#1907183)
-
특정 네임스페이스의 가상 머신에 KubeMacPool 라벨을 적용하고
io특성을 사용하여 해당 네임스페이스에 대한 MAC 주소 풀을 활성화하면io특성 구성이 VM에 대해 유지되지 않습니다. 해결 방법으로 VM에io특성을 사용하지 마십시오. 또는 네임스페이스에 대해 KubeMacPool을 비활성화할 수 있습니다. (BZ#1869527)
- OpenShift Virtualization 2.5로 업그레이드하면 운영 체제, 워크로드, 플레이버의 각 조합에 대해 이전 버전과 최신 버전의 공통 템플릿을 모두 사용할 수 있습니다. 공통 템플릿을 사용하여 가상 머신을 생성할 때는 최신 버전의 템플릿을 사용해야 합니다. 문제를 방지하려면 이전 버전을 무시하십시오. (BZ#1859235)
실시간으로 마이그레이션할 수 없는 가상 머신을 실행하면 OpenShift Container Platform 클러스터 업그레이드가 차단될 수 있습니다. 여기에는 hostpath-provisioner 스토리지 또는 SR-IOV 네트워크 인터페이스를 사용하는 가상 머신이 포함됩니다. (BZ#1858777)
해결 방법으로 클러스터를 업그레이드하는 동안 전원이 꺼지도록 가상 머신을 재구성할 수 있습니다. 가상 머신 구성 파일의
spec섹션에서 다음을 수행합니다.-
evictionStrategy를 삭제합니다. LiveMigrate필드. 제거 전략을 구성하는 방법에 대한 자세한 내용은 가상 머신 제거 전략 구성을 참조하십시오. -
runStrategy필드를Always로 설정합니다.
-
-
알 수 없는 이유로
containerDisk볼륨 유형의 메모리 사용량이 메모리 제한을 초과할 때까지 점진적으로 증가할 수 있습니다. 이 문제를 해결하려면 VM을 재시작하십시오. (BZ#1855067)
웹 콘솔에서 OpenShift Virtualization Operator의 구독 채널을 편집하려고 할 때 서브스크립션 개요의 채널 버튼을 클릭하면 JavaScript 오류가 발생하는 경우가 있습니다. (BZ#1796410)
해결 방법으로 다음
oc패치 명령을 실행하여 CLI에서 OpenShift Virtualization 2.5로의 업그레이드 프로세스를 트리거합니다.$ export TARGET_NAMESPACE=openshift-cnv CNV_CHANNEL=2.5 && oc patch -n "${TARGET_NAMESPACE}" $(oc get subscription -n ${TARGET_NAMESPACE} --no-headers -o name) --type='json' -p='[{"op": "replace", "path": "/spec/channel", "value":"'${CNV_CHANNEL}'"}, {"op": "replace", "path": "/spec/installPlanApproval", "value":"Automatic"}]'이 명령을 실행하면 해당 구독이 채널
2.5로 업그레이드되고 자동 업데이트가 활성화됩니다.
노드에 다른 CPU 모델이 있으면 실시간 마이그레이션이 실패합니다. 노드의 물리적 CPU 모델이 같은 경우에도 마이크로코드 업데이트로 인한 변화가 미치는 영향은 동일합니다. 기본 설정에서 실시간 마이그레이션과 호환되지 않는 호스트 CPU 통과 동작을 트리거하기 때문입니다. (BZ#1760028)
이 문제를 해결하려면 다음 예와 같이
kubevirt-configConfigMap에서 기본 CPU 모델을 설정하십시오.참고실시간 마이그레이션을 지원하는 가상 머신을 시작하기 전에 이러한 변경을 수행해야 합니다.
다음 명령을 실행하여 편집할
kubevirt-configConfigMap을 엽니다.$ oc edit configmap kubevirt-config -n openshift-cnv
ConfigMap을 편집합니다.
kind: ConfigMap metadata: name: kubevirt-config data: default-cpu-model: "<cpu-model>" 1- 1
<cpu-model>을 실제 CPU 모델 값으로 바꿉니다. 모든 노드에 대해oc describe node <node>를 실행한 후cpu-model-<name>라벨에서 이 값을 확인할 수 있습니다. 모든 노드에 존재하는 CPU 모델을 선택합니다.
OpenShift Virtualization에서는
oc adm drain또는kubectl drain을 실행하여 트리거되는 노드 드레이닝을 안정적으로 확인할 수 없습니다. OpenShift Virtualization이 배포된 클러스터의 노드에서 이러한 명령을 실행하지 않도록 합니다. 노드에 실행 중인 가상 머신이 있는 경우 노드가 드레이닝되지 않을 수 있습니다.- 현재 해결책은 노드를 유지보수 모드에 배치하는 것입니다.
-
OpenShift Virtualization 스토리지 PV가 RHV VM을 가져오는 데 적합하지 않은 경우 진행률 표시줄이 10%로 유지되고 가져오기가 완료되지 않습니다. VM Import Controller Pod 로그에 다음과 같은 오류 메시지가 표시됩니다.
볼륨을 바인딩하지 못했습니다: PVC에 프로비저닝에 실패했습니다. (BZ#1857784)
RHV VM을 가져오는 동안 RHV Manager에 잘못된 자격 증명을 입력하면
vm-import-operator에서 RHV API에 반복적으로 연결을 시도하기 때문에 Manager에서 관리자 계정을 잠글 수 있습니다. (BZ#1887140)계정을 잠금 해제하려면 Manager에 로그인하여 다음 명령을 입력하십시오.
$ ovirt-aaa-jdbc-tool user unlock admin
-
OpenShift Container Platform 클러스터에
기본 사용자 권한이있는 사용자로 로그인한 경우virtctl guestosinfo <vmi_name>을 실행하여 게스트 에이전트 정보를 검색할 수 있습니다. 이 문제를 해결하려면oc describe vmi명령을 실행하여 게스트 에이전트 데이터의 하위 집합을 가져올 수 있습니다. (BZ#2000464)
