백업에서 부팅 드라이브에 복사한 후 ESXi 관리가 실패하고 연결이 거부됨

Question

나는 스스로 해결책을 찾은 후에 이 글을 쓰고 있습니다. 왜냐하면 그것은 문서화할 가치가 있는 매우 이상한 "문제"였기 때문입니다.

복원을 수행하는 동안 이 문제가 발생했지만 ESXi 설치의 부팅 드라이브가 시스템에 연결되어 있는 동안 다른 운영 체제로 부팅하는 경우, 특히 디스크 크기가 변경된 경우 이 문제가 발생할 수 있습니다.

최근에 대부분의 VM과 해당 가상 부팅/시스템 디스크를 보관하는 데이터 저장소가 포함된 VMware ESXi 설치의 부팅 드라이브를 복원했는데, 양호하다고 알려진 이 상태가 어떻게든 중단된 것을 발견했습니다.

서버 로컬 콘솔의 디스플레이에 따르면 ESXi는 정상적으로 부팅되는 것처럼 보였지만 다음과 같은 문제가 있는 증상이 많이 나타났습니다.

• vSphere Client로 로그인할 수 없으며 "vSphere Client가 다음에 연결할 수 없습니다"라는 메시지가 표시됩니다.주인. 알 수 없는 연결 오류가 발생했습니다. (접속 실패로 인해 요청이 실패했습니다. (원격 서버에 접속할 수 없습니다.))”

• vSphere Client의 로그에 오류가 포함되었습니다.

  System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it

• 웹 브라우저를 사용하여 서버에 로그인하려고 시도하면 브라우저에서 연결이 거부되었다고 보고했습니다.

• 로컬 콘솔에서 이를 활성화한 후에도 서버에 SSH로 접속할 수 없습니다.

• 로컬 콘솔을 통해 관리 네트워크와 관리 에이전트를 다시 시작해도 문제가 해결되지 않았습니다.

• 로컬 콘솔에서 hostd실행되지 않는 것을 발견했으며 재부팅해도 문제가 해결되지 않았습니다.

• esxcli명령은 항상 다음과 같습니다.Connect to localhost failed: Connection failure

• 예상보다 디렉터리 수가 적었고 /vmfs/volumes그 중 어느 것도 내 데이터 저장소로 보이지 않았습니다.

• 로컬 UI의 "시스템 구성 재설정"으로도 문제가 해결되지 않았습니다. (나는 다시 복원할 수 있는 알려진 좋은 이미지가 있었기 때문에 이 작업을 시도했습니다. 문제를 해결한 후에 복원했지만, 아무것도 변경되었는지는 확실하지 않습니다.)

제가 복원한 백업 복사본은 서버가 다운된 상태에서 촬영한 RAID 논리 디스크의 낮은 수준 이미지였습니다. 잠재적으로 손상된 RAID 어레이를 삭제하고 다시 만든 후 HBA에 연결된 별도의 드라이브를 사용하여 물리적 Windows Server 설치로 부팅하여 이미지를 새 RAID에 복사했습니다. 저는 HDD Raw Copy Tool을 사용했습니다.hddguru.com, 이는 기본적으로 Linux 명령에 비해 덜 비밀스럽고 까다로운 대안입니다 dd.

(이것은 VMware를 백업하는 매우 완전한 방법이지만 야만적이지만 이 디스크는 주로 데이터가 아닌 VM 부팅/시스템 디스크만 저장하므로 주요 변경을 수행할 때를 제외하고는 어쨌든 자주 백업되지 않습니다. 기본 데이터에 대한 훨씬 더 나은 백업 시스템.)

RAID에서 더 큰 드라이브로 업그레이드했는데 데이터 저장소가 약간 찼기 때문에 백업한 것보다 새 RAID 논리 디스크를 더 크게 만들었습니다. 백업이 작동하는지 확인한 후 데이터 저장소를 확장할 계획이었습니다.

원본 사본을 완성하자마자 ESXi로 부팅하여 그것이 중단되었음을 발견했습니다. 무슨 일이에요?!

이것은 꽤 오래된 ESXi 5.0 U3입니다. (현재 요구 사항을 잘 충족하고 있지만 업그레이드를 위해 업그레이드를 관리하고 자주 발생하는 문제를 해결하는 등의 작업을 수행할 정규 IT 직원이 없습니다.)

Answer 1

내 경우에는 Windows에서 손상이 발생했을 수도 있지만 다른 소프트웨어에서 동일한 문제가 발생할 수 있습니다.

이는 확실히 ESXi 5.0 U3에 적용되며 아마도 모든 ESXi 5.x에 적용되며 아마도 모든 ESXi 6.x에 적용됩니다. 다른 단순한 파티션 레이아웃을 사용하는 ESXi 7에는 적용될 가능성이 적습니다.

조사 배경

마침내 알아 내기 시작했을 때 새로 설치하는 것이 거의 가까웠습니다.

을 둘러보면서 /vmfs/volumes발견한 이상한 점 중 하나는 $RECYCLE.BIN모든 디렉토리에 DESKTOP.INIWindows 탐색기 셸 확장과 일치하는 내용의 파일이 포함되어 있다는 것이었습니다. 이는 Windows를 기반으로 하지 않았거나 기반으로 한 적이 없는 하이퍼바이저의 시스템 파티션에서 발견되는 약간 특이한 현상입니다.

나는 디스크 이미지를 복사하는 데 사용한 Windows OS가 디스크 이미지에 어떤 작업을 수행했는지 즉시 의심하게 되었습니다. ESXi는 부팅 디스크에서 여러 FAT 파티션을 사용하므로 Windows가 이 파티션을 사용할 수도 있습니다. 디스크 이미지가 알려진 양호한 상태에서 가져왔지만 전혀 아무것도 하지 않고 실패한 것을 고려하면이내에ESXi, 이것이 가장 유망한 조사 과정으로 보였습니다.

나는 처음에 16진수 편집기를 통해 이러한 $RECYCLE.BIN디렉토리가 디스크 이미지에도 나타나는 것을 발견했을 때 실망했습니다. 처음에 저는 이것을 이미지가 촬영되기 전에 Windows Server에서도 이미 손상이 발생했다는 의미로 받아들였습니다. 그러나 이것들은 나를 올바른 방향으로 이끌었지만 양성적인 것으로 판명되었습니다. Windows는 디스크가 항상 "오프라인"으로 유지되었음에도 불구하고 아직 크기가 조정되지 않은 원래 논리 디스크를 확인하자마자 이를 추가했을 가능성이 높습니다.

16진수 편집기(HxD - 16진수 편집기 및 디스크 편집기, 정말 좋은 도구) 디스크 이미지의 GPT 파티션 테이블과 새 RAID 디스크에 있는 GPT 파티션 테이블 사이에 이상한 작은 차이점이 하나 있습니다. 이는 파티션 편집기에서 표시한 차이점이 아닙니다.실제로는 논리적으로 아무런 차이가 없습니다, 내가 아는 한. 이것은 원시 16진수 덤프에서 찾아보아야 할 것입니다.

근본 원인

두 경우 모두 파티션 배열에는 비어 있지 않은 항목이 7개 있었습니다. 그러나 ESXi가 원래 배열을 작성한 방식에는 처음 3개 항목 뒤에 하나의 빈 항목(모두 128바이트가 0으로 지정됨)의 공백이 있었습니다. 따라서 마지막 4개의 유효한 항목은 자체 512바이트 섹터에 속했습니다. ESXi가 중단된 라이브 디스크에서 마지막 4개의 유효한 항목은 간격을 줄이기 위해 한 항목 위로 이동되었습니다. 그 외에는 항목이 동일했습니다.

누가 이 작업을 했는지는 Windows인지 HDD Raw Copy Tool인지는 모르겠지만 Windows가 어느 정도 의심스럽습니다. 다시 테스트했는데 이 변경사항이 표시됩니다.즉시복사가 완료된 후, 복사 도중 및 복사 후에 디스크 관리 MMC 스냅인에서 RAID 논리 드라이브가 "오프라인"인 경우에도 마찬가지입니다. CRC가 모두 정확하고 백업 GPT도 마찬가지로 변경되었으므로 이는 분명히 의도적인 변경입니다.

내 이론은 이런 일을 하는 사람이 디스크 크기와 일치하지 않기 때문에 GPT를 다시 작성하고 기존 배열을 정확하게 복사하는 대신 파티션을 일부 내부 구조에 목록으로 기억한 다음 다시 작성한다는 것입니다. 물론 배열을 간단하게 작성하면 간격이 생기지 않습니다.

참고로, ESXi가 작성한 배열의 항목은 디스크에서 물리적으로 발생하는 파티션의 순서와 동일하지 않았지만, 간격을 메운 프로그램이 무엇이든 적어도 항목을 자유롭게 정렬할 수는 없었습니다. 고맙게도!

수동수정

일반적으로 모든 파티션 편집기가 동일한 작업을 수행하기 때문에 이 간격을 다시 만드는 쉬운 방법은 없습니다. 즉, 기존 테이블을 도구에서 사용하는 내부 표현으로 변환하고 해당 표현에 대해 요청한 변경 작업을 수행합니다. 그런 다음 올바른 데이터를 갖도록 테이블을 GPT 형식으로 다시 작성하십시오. 내가 아는 한 어레이 항목의 디스크 상의 정확한 위치 지정은 관련성이 없으며 다시 쓰는 "올바른 데이터"의 일부가 되지 않습니다.

그러나 ESXi가 정확한 어레이 레이아웃에 까다로울 수 있다는 직감이 있었기 때문에 어떤 일이 발생하는지 확인하기 위해 수동으로 수정하기로 결정했습니다. 절차는 다음과 같습니다.

1. 예방 조치로 디스크 관리 MMC 스냅인에서 디스크가 "오프라인"인지 확인하십시오.
2. 16진수 편집기에서 디스크를 엽니다. HxD에서는 아래에 있습니다.엑스트라→디스크 열기..."물리적 디스크"에서 선택해야 합니다. 기본적으로 켜져 있는 "읽기 전용으로 열기"를 선택 취소하세요. 이것이 위험하다는 적절한 경고를 받게 될 것입니다.
3. 일반적으로 LBA 2(헤더의 쿼드워드 48h에서 확인)에서 시작하는 기본 GPT 배열에서 범위를 복사하고 아래쪽에 붙여넣은 다음 간격을 0으로 설정하여 간격 뒤에 있어야 하는 항목을 아래로 밀어냅니다. 더 나은 방법은 백업 이미지가 있는 경우 실제 테이블을 복사하는 것입니다. 그러나 LUN의 크기가 변경된 경우 GPT 헤더에 복사할 수 없으며 그렇지 않으면 해당 헤더가 필드 20h 및 30h에 대해 잘못된 값을 갖게 되므로 상황이 반복될 수 있습니다.
4. 선택전체GPT 배열의 범위. 기술적으로는 GPT 헤더의 50h와 54h에 있는 더블워드의 곱을 사용하여 범위를 결정해야 하지만 이 숫자는 일반적으로 16,384바이트입니다.
5. 4단계에서 선택한 범위의 CRC32를 선택합니다. UEFI 사양에서 CRC32 알고리즘에 대한 수학적 매개변수를 찾을 수 없었지만 이것이 ISO 802-3의 매우 일반적인 매개변수라는 것을 알 수 있었습니다. 정규 다항식 04C11DB7h를 사용합니다. 온라인 계산기로 계산할 수 있습니다.여기, "입력 유형"을 16진수로 설정해야 합니다. 이를 리틀 엔디안 형식의 GPT 헤더 58시간에 배치합니다.
6. 10시에 GPT 헤더의 4바이트에 임시로 0을 배치합니다.
7. 길이가 0Ch의 더블워드에 의해 헤더 자체에 지정되는 헤더의 CRC32를 가져옵니다. 이것을 10시에 헤더에 넣으세요.
8. 백업 GPT에 대해 3~7단계를 반복합니다. 배열과 해당 CRC는 동일하므로 복사하면 되지만 헤더는 다르므로 CRC도 달라집니다. 백업 헤더는 일반적으로 디스크의 가장 마지막 섹터에 있고 그 바로 앞에 어레이가 있지만 기술적으로는 기본 GPT 헤더에서 쿼드워드 20h를 확인하고 백업 헤더에서 쿼드워드 48h를 확인해야 합니다.
9. 만약 당신이완전 확실해모든 작업을 올바르게 수행했습니다. 저장을 누르세요. 여기서도 HxD가 적절한 경고 메시지를 표시합니다.

상담하실 수 있습니다.위키피디아 기사GPT 형식의 기본 기술 세부정보를 확인하세요.

스크린샷

"깨진" GPT 배열의 일부는 다음과 같습니다. 유효한 항목은 77Fh에서 끝나며 그 전에는 0이 오랫동안 실행되지 않습니다.

내가 고친 방법은 다음과 같습니다. 이제 유효한 항목은 7FFh에서 끝납니다.

결과

나는 이것이 작동할 것이라고 정말로 기대하지 않았습니다. 나는 그것을 연구하지 않았지만 UEFI 사양은 배열 항목의 순서나 간격에 아무런 의미를 두지 않을 것으로 예상합니다. 실제로 모든 파티션에는 고유한 GUID가 있습니다.정확하게그래서 당신은~하지 않다그러한 취약한 경험적 방법에 의존해야 합니다. 따라서 배열 인덱스에 따라 테이블을 작성할 당시와 동일한 것은 좋지 않은 생각입니다.

^{(다시 말하지만, 엔터프라이즈 수준의 소프트웨어 및 펌웨어가 나쁜 아이디어에 관여하는 것을 본 것이 처음은 아닐 것입니다. 시스템 관리자 모자를 쓸 때마다 눈이 멀 정도로 멍청한 문제에 직면하게 되는 것 같습니다. 프로그래밍 조각...하지만 호언장담은 하지 않겠습니다.)}

그래서 조정된 테이블을 조심스럽게 저장하고 RAID로 다시 부팅하고 ESXi를 시작하고 vSphere Client를 연결하면 모든 것이 정상으로 돌아왔습니다.

이상적으로는 일반적으로 Veeam Backup과 같은 기능을 사용하는 것이 더 좋지만 경우에 따라 더 많은 경우가 있습니다.애드 혹해결 방법이 적절할 수 있으며, 이 경우 이 버그가 발생할 수 있습니다.