RHEV: VMs lost network connectivity after RHEL Hypervisor upgraded to 6.7
환경
- Cisco UCS
- Red Hat Virtualization 3.4, 3.5, 3.6 and 4.x
- Red Hat Enterprise Linux 6.7, 6.8 based Hypervisor
- kernel-2.6.32-573.el6 (and higher)
- Red Hat Enterprise Linux 7.x based Hypervisor
- kernel-3.10.0-123.el7 (and higher)
- driver: enic version 2.1.1.67
증세
- kernel-2.6.32-573.el6 이상을 실행하는 RHEL 하이퍼 바이저로 마이그레이션하면 VM의 네트워크 연결이 끊어집니다.
- 업그레이드되지 않은 하이퍼바이저로 VM을 다시 마이그레이션하면 간단히 다시 액세스 할 수 있습니다.
- DHCP 응답 / 제공은 KVM 게스트로 전달되지 않습니다.
- KVM 게스트의 PXE 부팅 시간이 초과되었습니다.
- 하이퍼 바이저 브리지는 ARP 요청을 가상 머신 vnetX로 전달하지 않습니다.
- 가상 시스템은 동일한 호스트에서 실행중인 다른 가상 시스템 만 핑할 수 있습니다.
- Hosted-Engine은 실행중인 호스트 만 핑할 수 있으며 다른 호스트에 연결할 수 없습니다.
- NIC가 promiscuous 모드에 있지 않으면 서버가 통신 할 수 없습니다
해결방법
근본 원인 섹션을 먼저 읽고 이해하십시오.
포괄적 인 분석 및 토론 후에 enic 드라이버 변경 (VLAN 0 제거)을 되돌려 야한다는 합의가 없었습니다. 예를 들어, 어떤 사람들은 리눅스 커널과 그 드라이버가 유선으로받은 것을 전달해야한다고 주장합니다. 또한 네트워크 스택에서 프레임이 제거 될 위치 (예 : tcpdump에 태그 표시 여부)에 대한 합의가 없었습니다. 이 문제는 bugzilla 1434533에서 추적되었지만 초기 문제는 bugzilla 1262184에서 논의되었습니다. 둘 다 현재 WONTFIX로 종료되었습니다.
이 문제를 해결하는 방법에는 4 가지가 있습니다. 아래의 모든 방법을 참조하십시오.
참고 :이 시점에서 솔루션 3을 권장합니다.
하이퍼바이저 커널 버전 다운그레이드
커널버전을 다운그레이드 합니다. 이것은 RHEL 기반 하이퍼바이저에서만 가능합니다. 다음 표를 참조하십시오 :
- RHEL 기반 하이퍼바이저의 경우
| RHEL 하이퍼 바이저 버전 | 커널 버전 |
|---|---|
| 7.x | 없음, 해결 방법이 불가능합니다 |
| 6.7 이상 | 없음, 해결 방법이 불가능합니다 |
| 6.6 | ⇐ 2.6.32.504.30.3.el6 |
| 6.5 이하 | 아무버전이나 가능 |
| 5.x | 아무버전이나 가능 |
- RHEV-H 및 RHVH (NGN) 하이퍼바이저의 경우
| 하이퍼 바이저 버전 | 버그 상태 |
|---|---|
| RHVH (차세대) 3.6 및 4.x | 영향을 받음, 해결 방법 불가능 |
| RHEV-H7.x | 영향을 받음, 해결 방법 불가능 |
| RHEV-H6.7 이상 | 영향을 받음, 해결 방법 불가능 |
| RHEV-H6.6 이하 | 커널 버전 ⇐ 2.6.32.504.30.3.el6 인 경우 영향을 받음 |
| RHEV-H6.5 이하 | 영향을받지 않았다 |
Cisco enic 드라이버 사용
버그에 대한 해결책이있는 Red Hat에서 지원하지 않는 대체 드라이버에 대해서는 Cisco에 문의하십시오.
가상 머신 커널 버전
VM을 VLAN ID 0을 처리하는 커널로 업그레이드합니다. VM 측에서 해결 방법을 제공하는 커널은 아래 표를 참조하십시오.
| 게스트 VM RHEL 버전 | 커널 버전 |
|---|---|
| 7.x | 아무버전이나 가능 |
| 6.7 이상 | 아무버전이나 가능 |
| 6.6 | > = 2.6.32-504.22.1.el6 |
| 6.5 | > = 2.6.32-431.61.2.el6 |
| 6.4 이하 | 없음, 해결 방법이 불가능합니다 (아래 참조). |
| 5.x | 없음, 해결 방법이 불가능합니다 (아래 참조). |
가상 머신 8021q 커널 모듈 활성화
위 표의 버전에서 커널의 경우 8021q 모듈을 수동으로로드하면 네트워크 통신이 modprobe 8021q가능할 수 있으므로 가상 머신이 VID 0 태그가 지정된 프레임을 처리하게 할 수 있습니다. 그렇게하려면 아래를 참조하십시오.
게스트 내부에 VLAN 모듈을로드하십시오.
modprobe 8021q
그런 다음 게스트가 ping 또는 기타 유틸리티를 사용하여 하이퍼 바이저 외부 시스템에 네트워크로 연결할 수 있는지 확인하십시오. 그렇다면 부팅시 게스트가 모듈을 로드하도록하십시오.
echo "modprobe 8021q" >> /etc/rc.modules && chmod 755 /etc/rc.modules
PXE 부팅에 대한 참고 사항
gPXE (RHEL6 호스트) 또는 iPXE (RHEL7) 호스트를 사용할 때 동일한 VID 0 PDU가 PXE 부팅을 중단합니다. 이 이미지는 VLAN 0 태깅을 지원하지 않으며 단순히 패킷을 버리고 VM이 PXE 부팅을 방해합니다.
Red Hat은 gPXE와 iPXE에 기능 (우선 순위 태깅)을 도입하여 이러한 이미지가 불필요한 VLAN 0을 버리고 VM이 PXE 부팅을 수행 할 수 있도록했습니다.
이것은 다행스럽게도이 문제의 해결 방법으로 사용되는 기능입니다. 다음 버전에는이 기능이 포함되어 있습니다.
- RHEL7 : ipxe-roms-qemu-20160127-5.git6366fa7a.el7.noarch.rpm 이상 (RHEL 7.3 GA에서 릴리스 됨)
- RHEL6 : gpxe-0.9.7-6.16.el6 (RHEL 6.9 GA 및 6.8.Z와 함께 릴리스 됨)
근본 원인
Cisco Interconnect는 이전에 태그가 지정되지 않은 패킷에 VLAN 0을 태그합니다. RHEL 6.6 이전 버전에서는 enic 드라이버가 VLAN 0 태그를 가져 와서 프레임에 태그가 다시 지정되지 않았습니다. RHEL 6.7에서는 enic 드라이버가 업데이트되었으며 이 시점부터 VLAN 0으로 태그가 지정된 그대로 와이어에 수신 된 그대로 프레임을 남겨 둡니다. 궁극적으로 관리자가 네트워크를 태그가없는 것으로 구성한 경우에도 가상 시스템에는 VLAN 0으로 태그가 지정됩니다.
VID 0은 게스트가 태그없는 프레임과 동일한 방식으로 처리해야합니다. 그러나 일부 게스트 운영 체제 및 Linux 커널은이를 제대로 처리하지 않아 프레임이 삭제되어 네트워크 연결이 이루어지지 않습니다. 이전 enic 드라이버 버전에서는 드라이버가 태그를 제거함에 따라이 마스크가 마스크되었습니다. 그러나 태그 제거도 올바르지 않으므로 호스트는 와이어를 통해 수신 된 프레임을 수정하지 않고 전달해야합니다.
따라서 두 가지 문제가 있습니다.
- 가상 머신 : 이전 커널에서 VID 0으로 VLAN 패킷을 수신 할 수 없음
- 하이퍼 바이저 : 최신 enic 드라이버 및 새 VLAN에서 VLAN VID 0으로 들어오는 패킷의 불필요한 태그 지정 모델.
진단 방법
tcpdump를 사용하여 다음과 같이 VM에서 802.1q 태그가 지정된 프레임을 확인하십시오.
# tcpdump -i INTERFACE -n -e -s 0 ...... ethertype 802.1Q (0x8100), length 104: vlan 0, p 0, ethertype IPv4 .....
vlan 0 와 같은 태그가 패킷에서 발견되면 해당됩니다.