imnas

반드시 Synology DSM만 그런 것은 아닐텐데요. 간혹 하디드스크의 부트 파티션이 날라가 버리는 경우가 생길 수 있습니다. 이러한 경우 부팅 시에 boot partition not found라는 메시지를 무한출력하는 경우가 있습니다. 이러한 경우 Linux나 Windows를 이용해서 fixmbr 또는 bcd도구를 사용해도 되는데요. 간혹 수정이 안될 경우가 있습니다. 1. DSM에서 하드디스크 초기화를 시켰는데도 여전히 문제 발생. 2. Windows에서 mrb 복구작업을 해도 여전히 문제발생 이러한 경우 대게 위의 그림에서 디스크 1번과 같은 상태가 됩니다. 다시 복구하려면 디스크 3과 같이 만들어야 하는데요. 간단한 방법은 bootice를 이용해서 MBR을 생생해 주는 것입니다. Windows에서 bootice을 사용하기 위해서는 MBR을 생성할 하디드스크를 슬레이브로 장착하고 bootice를 설치하고 아래와 같이 실행합니다. 1. 구글 검색으로 bootice를 찾아 다운로드 받습니다. 2. bootice를 실행합니다. 3. physical disk 탭을 선택합니다. 4. destination disk에서 MBR을 생성할 디스크를 선택합니다. 5. Process MBR 버튼을 클릭합니다. 간단히 트러블슈팅이었습니다.

가끔 피곤하면 저녁먹고 바로 꼴까닥해서 새벽에 깨는데 아마도 나이탓 듯합니다. 이럴 때는 아메리카노 한 잔 놓고 심심풀이 서핑을 하는데요. XPEnology(엑스피이놀로지)에 대한 글을 읽다가 깜짝 놀랐습니다. 제가 본 포럼에서 작성한 글과 문구가 동일한 일부 내용이 웬 블로그에 출판되어 있어서 말이죠. 혹시 제가 공동저자인가 기대를 했더니 그건 아니더군요.^^ 해놀 또는 해놀로지를 불법으로 사용하신다구요??? 제가 작성한 것은 2015년 7월 24일이고, 글 하단에 보면 8월 3일날 마지막 업데이트를 했다고 기록해 놓았지요. 간혹 제가 제글을 읽어 보고 수정하는 경우가 있습니다. DIY-NAS-헤놀로지 vs XPEnology(굳이 링크는 하지 않겠습니다.) 라는 글을 보니 ... 2015년 8월 10일자로 출판되어 있는데요. 제글과 주제가 유사해 보이는군요. 그런데 블로그 글인만큼 정리가 잘되어져 있고 스페셜리스트의 향기가 나네요. 제가 작성한 문구 ... 1. 마치 시놀로지 NAS인 것처럼 '유효한 NAS ID'를 복제하는 경우 2. 마찬가지로 시놀로지 머신의 mac을 복제해서 정품처럼 사용하는 경우 3. 시놀로지 정품처럼 변경해서 DSM의 시놀로지 서비스를 제공받는 경우 4. 개인용도가 아닌 비지니스 목적으로 사용하는 경우 5. DSM을 특정 기계에 포팅해서 판매하는 경우 블로거가 작성한 문구 ... – 시놀로지 NAS인 것처럼 유효한 NAS ID를 복제하는 경우 – 시놀로지 기기의 mac addresss를 복제해서 정품처럼 사용하는 경우 – 시놀로지 정품처럼 변경하여 DSM의 시놀로지 서비스를 제공받는 경우 – 개인용도가 아닌 비즈니스 목적으로 사용하는 경우 – DSM을 특정 기기에 포팅해서 상업적으로 판매하는 경우 어떻게 저렇게 놀랍도록 같은지는 모르겠습니다만, 제글을 어떻게 했느니 뭐 .... 이런 것으로 따지는 것이 아닙니다. 논문도 카피하는 마당에 ... 미천한 제글을 ... 아무튼 제글이 모티브가 되어서 작성하신 것인지는 모르겠습니다만, 글을 꼼꼼하게 살펴 보니까 저와 몇 가지 공통되는 생각을 가지고 계시더군요. 그런데 몇 가지 잘못 파악하신 점이 있습니다. 그래서 그것에 대해 말하고자힙니다. 1. DSM을 좀더 확장하여 마치 정식으로 상용NAS를 구매 ....(이하 줄임) 이미 아시는 분들은 계실텐데요. 'XPEnology 프로젝트 팀'은 XPEnoboot 부트 이미지 외에 DSM을 임의적으로 확장해서 배포하지 않습니다. 그럼에도 위의 블로그는 마치 'XPEnology 프로젝트 팀' 자체가 GUN GPL를 어기고 불법 배포하는 양 기술했더군요. 2. XPEnology 관련 사이트들은 현재 'XPEnology 프로젝트 팀'이 운영하는 것이 아니고, XPEnology에 관심있는 사용자들이 각기 사비를 들여 독립적으로 운영하고 있습니다. 인터넷에서 작은 커뮤니티라도 만들고 운영하려면, 운영비용이 들어가죠. 그럼에도 현재 이 포럼만 해도 영리목적의 '광고'조차 달고 있지 않습니다. 3. 본 XPEnology support forum은 'XPEnology 프로젝트 팀'과는 별개로 XPEnology 사용자들간에 정보를 교환하는 포럼일 뿐입니다. 이러한 포럼은 누구든지 자유롭게 언제든지 개설이 가능하겠습니다만, 현재 본 포럼은 개인이 운영하고 있을 뿐이며, 그나마 인지도가 제일 높은 편이죠. 4. 시놀로지가 배포하는 DSM과 우리 사용자들이 사용하는 DSM은 동일합니다. 동일함은 md5로 확인하실 수가 있습니다. 예를 들어 ...XPEnology.me에서 배포하는 DSM 5.2-5592 DS3615xs의 md5는 '3ac1644e147a4d870ddc94eec6903c89'입니다. 해시값을 확인하신 다음에 이번에는 시놀로지에서 배포하는 DSM_DS3615xs_5592.pat.md5을 클릭해서 확인해 보세요. 동일하게 '3ac1644e147a4d870ddc94eec6903c89'임을 확인하실 수 있습니다. 물론 어느 곳에서든 다운로드 받으셔도 됩니다. 5. XPEnology는 부트 이미지만 제공할 뿐, 위에서 처럼 DSM을 임의로 핸드링하지 않습니다. 단, 커널 컴파일 등 사용자들 자신의 환경에 맞게끔 개조하거나 변조, 불법 공유가 있는 것은 사실입니다. 그러나 이러한 정보는 'XPEnology 프로젝트 팀'과는 무관하다고 할 수 있죠. 그 외에 블로그 글을 읽어 보면, 마치 XPEnology가 커스터마이징되어서 배포하는 듯한 착각을 주게 되는데요. 뭔가를 잘못 파악하고 있는 듯합니다. 한마디로 XPEnology는 비-시놀로지 기계, x86_64 아키텍처를 가지는 PC에서 시놀로지 웹OS인 DSM이 포팅되도록 해주는 것일 뿐입니다. 그 외에 DSM과 DSM 패키지는 XPEnology와 상관이 없습니다. 또한 XPEnology에서는 정식 시리얼을 요구하는 DSM 패키지는 설치가 되지 않는데요. 설치가 되도록 변조시키는 것은 이용자들의 개별사항이지, 'XPEnology 프로젝트 팀'과 무관한 것입니다. 또한가지 오픈소스이기 때문에 '불법적인 침해나 공격의 위험성이 존재'한다고 하시는데, 오히려 오픈소스이기 때문에 취약점이 발견되면 누구라도 빠르게 패치를 내놓을 있는 것이 바로 장점입니다. 저작권이 있는 경우라면 오히려 취약점을 발견해도 패치를 내놓을 수 없는 것이 오히려 걸림돌로 작용합니다. 이 세상에 오픈 소스가 얼마나 많습니까? 시놀로지 DSM도 오픈소스이며, 리눅스도 오픈소스인데 불안해서 어떻게 사용한답니까? 아마도 위에 블로그 글을 작성하신 분은 '엑스피이놀로지' 관련 블로그나 포럼을 'XPEnology 프로젝트 팀'이 운영한다고 생각하거나 잘못된 정보를 접하신 모양입니다. 제가 작성한 포럼글이 모티브가 되었다고 하더라도, 그 글에서 보면 'XPEnology 프로젝트 팀'과 관련된 불법적인 부분은 언급된 바가 없습니다. 불법적인 부분들은 본인 스스로가 만들어 내신 모양입니다. 해놀, 헤놀 잘못된 표현을 지적한다는 것은 백번 옳습니다만, 정작 XPEnology에서는 사소한 부분도 아니고 굉장히 잘못 설명하고 있군요. 다시 강조드리지만, XPEnology 프로젝트 팀'은 절대 불법 공유와는 상관이 없고, 일부 XPEnology 사용자나 혹은 XPEnology 정보를 다루는 블로그 또는 사이트, 또는 개별 사용자들의 정보 공유에 해당하는 것입니다.

가상화는 하드웨어빨이라고 .... 혹시 하면서 추석이라 VM한테 예따~ 먹어라 하고, 4GB 메모리 할당을 해주니 결론은 1GB/s를 그대로 뽑아버리는군요. 켁~ 이와 함께 네트워크 관련 성능에 관해 계속 탐구 중인데,련 재미있는 사항이 발견되네요.^^ 그나저나 ESXi 지원안하는 불안정한 리얼텍 8111/8168에서 VM에서 다운로드 : 느리게 비워지는 씩 프로비저닝 - 약 43MB/s 정도 빠르게 비워지는 씩 프로비저닝 - 약 70MB/s 정도 이던게 리소스 편집으로 메모리 4GB 할당 후에 빠르게 비워지는 씩 프로비저닝 - 약 100MB/s 나오는군요. 1GB/s 대역 전체를 사용하니까, 이거 뭐 실제 PC나 가상 PC나 차이가 없네요. 이맛에 ESXi 가상머신 VM 사용하는거죠. 고향가시는 분들은 즐거운 추석 보내시고, 무사히 안전하게 귀향하세요.^^

단순하게 디스크 프로비저닝의 유형에 따라서 네트워크 속도 차이가 나는군요. 별다른 미세 튜닝없이 단순하게 가상 하드웨어상의 어탭터 유형과 디스크 프로지저닝만을 테스트해 보았습니다. '느리게 비워지는 씩 프로지저닝' 보다 '빠르게 비워지는 씩 프로비저닝'에서 좀 더 빠른 NIC가 좀 더 빠른 퍼포먼스를 보이는 군요. - 물론 ESXi상에 XPEnology 설치 시에도 '빠르게 비워지는 씩 프로비저닝'이 권장됩니다. E1000, VMXNET 3과 별차이 없는 것으로 파악 됨. VMXNET 2 기본값으로 연결 안 됨. VMXNET 3, E1000과 별차이 없는 것으로 파악 됨. '빠르게 비워지는 씩 프로비저닝'에서 1GB이상의 파일로 송수신을 테스트 해보니, 이전 보다 2배 가량 네트워크 대역이 향상되었습니다. VM으로 업로드 : 느리게 비워지는 씩 프로비저닝 - 몇 초 정도만 100MB/s 로 작동하다 0~20MB/s에서 춤을 추던것 빠르게 비워지는 씩 프로비저닝 - 수십 초 이상 100MB/s 로 작동하다 20~100MB/s에서 춤을 춤. VM에서 다운로드 : 느리게 비워지는 씩 프로비저닝 - 약 43MB/s 정도 빠르게 비워지는 씩 프로비저닝 - 약 70MB/s 정도 결론적으로 프로비저닝만으로도 네트워크 대역차가 발생하는군요. *. 마이크로소프트 윈도우가 공식적인 호환성 인증제를 사용하듯이 VM웨어에서도 호환성 인증제를 시행하나 보군요. 결국은 리얼텍 8111/9168가 인증받지 않았기 때문에 ESXi 5.5이상에서는 기본적으로 드라이버를 제공하지 않나 봅니다. 결국은 VM웨어의 호환성 목록에 없는 인증되지 않은 장치를 사용하는 셈이군요. 물론 Windows도 그렇지만, 공식 인증받지 않아도 아무 탈없이 잘 동작되는 경우도 있습니다만 .... 아무래도 기존사용자 입장에서는 불만일 수밖에 없군요. 본 주제 글의 문제는 해결되었습니다. 8111/8168 성능 해결 - 역시 가상화는 하드웨어 빨(?)이네요.

행복한 추석한가위 보내세요. ESXi 5.5/6/0 이하의 버전에서는 인텔보드여서 그랬는지 네트워크이 불안정하거나 그런 문제가 없었는데요. 리얼텍 칩셋 8111/8168이 사용되면, 문제가 있네요. 일단 ESXi 5.5/6.0에서 리얼텍 8111/8168의 네트워크 카드가 인식되지 않을 경우, 드라이버 8.039.00-NAPI 번들을 사용하거나 또는 8.040.00 을 다운로드 받아 빌드하면 되는데요. 문제는 VM웨어에서 지원을 하지 않는 이유가 있나봅니다. 제경우의 증상은 단일 파일 기준으로 VM과 Windows 클라이언트에서 파일 송수신을 해보면, VM으로 업로드하는 경우 시작 몇 초 동안은 100MB/s 속도가 나다가 갑자기 뚝 떨어지면서 0 ~ 20MB/s 사이에서 춤을 춥니다. 다운로드의 경우는 100MB/s의 반에 조금 못미치는 43MB/s 정도를 꾸준하게 유지는 해주는데요. 재미있게도 1GB가량 이하의 단일 파일의 경우는 기가속도(110MB/s ~ 113MB/s)로 다운로드 됩니다. 메인보드 내장 리얼텍 8111E와 PCI-E ipTIME PX1000 모두 동일하더군요. 다른 VM에서는 어떤가 하고, Windows 7을 설치했더니, XPEnology와 마찬가지 증상입니다. 혹자는 IP6를 비활성화시킨다느니, 기본 게이트웨이를 사용하지 않는다든지, 부트 옵션을 변경한다는지, 다른 버전이나 리비전 차이 등 별별 팁들이 있습니다만, 제가 시도해 본 결과는 효과를 보지 못했습니다. 먼저, 네트워크 정보는 아래와 같습니다. esxcli network nic get -n vmnic0 Advertised Auto Negotiation: true Advertised Link Modes: 10baseT/Half, 10baseT/Full, 100baseT/Half, 100baseT/Full, 1000baseT/Full Auto Negotiation: true Cable Type: Twisted Pair Current Message Level: 51 Driver Info: Bus Info: 0000:02:00.0 Driver: r8168 Firmware Version: Version: 8.039.00-NAPI Link Detected: false Link Status: Down Name: vmnic0 PHYAddress: 0 Pause Autonegotiate: false Pause RX: false Pause TX: false Supported Ports: TP Supports Auto Negotiation: true Supports Pause: false Supports Wakeon: true Transceiver: internal Wakeon: MagicPacket(tm) 8111E나 8168E나 드라이버는 r8169로 인식됩니다. 드라이버는 Version: 8.039.01-NAPI로 커스터마이징 했는데, 그냥 Version: 8.039.00-NAPI로 표기되는군요. 불안정함에도 1GB가량의 단일 파일의 경우가 기가바이트 속도를 내거나, 다운로드시에 일정한 속도를 내는 것으로 보아서는 네트워크 관련 설정값으로 튜닝을 시도하면 가능성은 있지 않을까라는 생각이 듭니다만, 먼저 리얼텍 칩셋을 왜 지원하지 않는지를 알아봐야겠네요. 특별한 칩셋도 아니고, 거의 뭐 국민 칩셋이라고 할 수 있을 정도로 많이 사용되는데 말이죠. Native XPEnology에서는 환상적인 기가바이트 속도 내는데 말이죠. ESXi에서만은 문제군요. ESXi를가 될수있는한 하드웨어적으로 고사양이어야 좋고, 일반사용자들 보다 주로 다중 개발환경이 필요한 개발자들이 사용하겠지만 그래도 좀 아쉽네요.

애플님, 위에 COMS에서 운영체제를 찾는 것은 ESXi에서 공통적용되는 부분입니다. 어떤 머신에서는 되고, 어떤 머신에서는 안되고 이러는 것도 아니구요. 혹시 반복된다는 의미를 자동적으로 뱅뱅 돈다는 의미로 받아드리시는 것인지 모르겠지만, operating systen not found가 발생한다는 것은 부트 장치들을 한 번씩 접근해 봐도 부트 가능한 미디어를 찾지 못했다는 것입니다. 다시 부팅 시도를 하려면 USB, CD/DVD, 플로피와 같은 장치 중 부팅 가능한 미디어를 삽입하고, any key를 누르게 되면 부팅 가능한 미디어를 장치들을 통해서 다시 찾습니다. 만일 또 못찾았다면, 2차로 operating systen not found이 발생하게 되겠구요. 이렇게 부팅 이미지를 찾을 떄가지 3차, 4차, .... 반복하게 되죠. 이런 작동은 제 하드웨어에서만 발생하는 것도 아니고, XPEnology 설치에서만 발생되는 것도 아니고, ESXi에서 VM 생성시 게스트 운영체제에 모두에 해당하는 사항입니다. 저는 잘 모르겠습니다. 왜그렇게 부트순서에 연연해 하시고 ISO로 부팅하시려는지 말입니다. 주제글이자 논점은 vmdk를 이용해서 ESXi상에 XPEnology를 설치하는 것입니다. 여기서 왜 부팅 우선순위가 나와야하며, ISO를 이용한 설치가 나와야 하는지요. 당연하지 않겠습니까? ISO나 USB로 설치가 쉽게 되는데, 왜 굳이 vmdk를 사용하겠어요. 개인적으로 시도하는 여러가지 사항에 대해서 제가 간섭할 이유는 없습니다만, 논점에서 자꾸 벗어나시고 아무리 반복해서 말씀드려도 다른 얘기를 하시니까 저는 쓸데없는 정력이 낭비가 되는지 지치게 되네요. 토론이든 의견교환이든 환영하는 바이지만, 저도 그렇고 논점에서 벗어나 비약을 하게 되면 끝이 없는 듯합니다.

이미지를 캡처해서 업로드합니다. 순환이던, 재인식이던 .... 제경우 아래처럼 표현을 했는데요. 1. "ESXi에서 VM설치 중 재부팅이 실패하면, COMS는 부트 장치들을 순환하며 계속해서 부트 가능한 미디어를 찾게 됩니다." 2. "ESXi에서 VM설치 중 재부팅이 실패해도, CMOS는 부트 가능한 미디어를 재인식하게 됩니다." 제표현이 틀렸는지는 아래처럼 반복되는 이미지를 일단 보시고, 글 읽으시는 분 의견대로 하세요.^^ 위와 같이 부트 가능한 장치들에 대해서 반복해서 접근하고, 부트 가능한 미디어가 있는지를 계속 접근하게 됩니다. operating system not found라도 끝나는게 아니고, esc와 any key를 사용하게 되면 지속적으로 루핑됩니다. 이렇게 시작해서 이 문제만 가지고도 제가 수차례 반복하고 있는데요. 동의하지 않으신다면 할 수 없겠죠.

아 참! "ESXi에서 VM설치 중 재부팅이 실패하면, COMS는 부트 장치들을 순환하며 계속해서 부트 가능한 미디어를 찾게 됩니다."는 표현에 문제가 있네요. "ESXi에서 VM설치 중 재부팅이 실패해도, CMOS는 부트 가능한 미디어를 재인식하게 됩니다." 로 변경하면 되겠네요.

주제글, 논점에서 한 참 벗어나서 반복해서 얘기해야 그렇고요. 짧게 정리하고 말겠습니다. ESXi에 게스트 운영체제(VM)를 설치하기 위해서는 주로 전통적인 방법대로 디바이스의 첫번째 노드의 고정적 하드디스크에 설치하면 됩니다. 그러나 XPEnology/시놀로지 DSM의 경우는 NAS의 가용성(hotswap, raid) 유지를 위한 관리 매커니즘상 하드디스크가 시스템 파티션을 가지지만 부트는 이미지는 가지지 않도록 설계되었습니다. 이러한 이유로 ESXi상의 XPEnology는 부팅을 IDE 노드로 에뮬레이션합니다. ESXi상에서 DSM 설치 중 재부팅 시점에서 문제가 발생하는데요. 이러할 때는 설치를 이어갈 수 있도록 부트 가능한 미디어를 연결시켜 주면 됩니다. ESXi에서 VM설치 중 재부팅이 실패하면, COMS는 부트 장치들을 순환하며 계속해서 부트 가능한 미디어를 찾게 됩니다. 이 때 XPEnoboot 부트 이미지 ISO를 CD/DVD 드라이브에 마운트시키면 성공적인 설치가 이루집니다.

확인해 보니까 데이터스토어에 부트 이미지로 .vmdk를 업로드해서 첫 번째 디바이스 노드로 연결시켜주지 않으면 설치가 되지 않는군요. vmdk없이 클라이언트 디바이스나, 호스트 디바이스, 데이터스토어에 ISO를 업로드해도 설치가 진행되지 않습니다. XPEnology support forum에서 안내해 주는 방법대로 하면 되겠습니다. vmdk 부트 이미지를 업로드 시켜주고 설치하는 것이 ESXi상에서 XPEnology를 설치하는 방법이구요. missing operating system으로 설치 중 재부팅이 실패할 경우 ... 1. 껏다 키면 됩니다.(제경우는 이것만으로 설치 가능합니다.) 2. 1번으로 안되면, 설치 중에 XPNoboot ISO를 클라이언트 디바이스로 연결합니다. 3. 2번으로 안되면, 아예 VM 시작(전원 켬) 후에 클라이언트 디바이스로 연결하고 시작합니다. 이에 대한 자세한 설명은 ESXi에서 missing operating system을 회피하는 방법을 참조합니다.

ESXi상에서 XPEnoboot를 이용한 설치방법입니다. 본 XPEnology support forum에서 안내받을 수 있는 최신정보에 해당합니다.(2015년 9월 현재) [GUIDE] XPEnoboot 5.1-5022.2 on ESXi 5.5.0 저도 위에 링크를 참고해서 설치합니다만, 사용하는 도구와 버전은 조금 차이가 있습니다. 그러나 설치하는데는 이상이 없습니다. 위의 방법으로 ESXi 5.1/5.5/6.0 최신 버전까지 설치했습니다. 제 경우는 Windows 10 Pro를 사용합니다. Software used: VMware ESXi 6.0.0 update 1 XPEnoboot 5.2-5592.2 StarWind V2V converter Rufus 2.3 Synology DSM 5.2-5592.PAT open-vm-tools_bromolow-5.1_9.10.0-2476743-1.spk - ESXi-Customizer-v2.7.2

부트 순서 변경하는 것에 대해, 제경우를 살펴보니까 항목자체가 보이질 않습니다. 링크하신 블로그에는 VM이 XPEnology가 아니고 Windows 8.1인데 그래서인지는 모르겠습니다. 그리고 apple3000님 말씀하시는 부트순위는 전체적으로는 무슨 말씀인지를 알겠는데요. 굳이 VM 설치를 위한 부트 순위는 의미가 없다는 것이 제생각이에요. 우선순위라는 것은 1개 이상의 부트장치가 경쟁을 할 때 어떤 것이 먼저임을 지정함으로써 우선순위 지정이 필요한 것이지요. 여러개 부팅 중에 하나의 장치를 사용해서 부팅을 하는데, 우선순위가 왜 필요까요? 물론 액세스를 지정한 순번대로 거치기야 하겠지만, 어느 것에든 부팅 이미지만 있으면 되지 않습니까? 문제는 vmdk로 시작하는 것에 오류가 발생한다는 것이 문제의 출발점입니다. 그 문제의 출발점은 그대로 두고 끝까지 가는 것에 의미를 둔 것이구요. 그렇지만 ISO는 출발점이 다르지 않을까요? 물론 결과만을 놓고 본다면 같을 수는 있지만, vmdk를 사용하는 이유가 있지 않을까요? 다시 말해 vmdk를 사용하던 USB를 사용하던 실제 CD/DVD 또는 가상 ISO, 플로피 등 우선순서가 중요한 것이 아니고, VM를 설치하기 시작해서 종료까지 지정한 부트장치를 유지해주면 설치는 성공한다는 것이죠. 제글의 핵심은 vmdk를 이용한 설치에서 missing operating system으로 설치에 실패하니까, 이를 회피하는 대책으로 ISO를 이용한 것에 불과합니다. 당연히 VM 설치 방법은 여러가지가 있을 수 있겠죠. 그리고 그 중에 처음부터 ISO를 이용하는 것은 여러 설치 방법 중에 하나일 것이구요. ISO이미지를 이용한 설치는 VMware Works에서는 일반화된 방법이지 않습니까? vmdk를 이용하는 방법도 설치 방법 중에 하나이구요. 왜 vmdk를 이용한 설치 방법인지는 모르겠습니다만, 뭔가 이유가 있지 않을까 합니다. 저도 그에 대한 호기심이 발동하는군요.

시간없어서 급하게 작성하신 것인지 읽다가 제머리가 빙빙 도네요^^ "USB 부팅 후에 콘솔로 빠진다"고 제가 어디서 한 것인지 모르지만, ESXi에서 말씀하시나 본데요? ESXi는 ESXi가 탑재되는 실제기계(Real Machine 또는 Physical Machine)가 있지 않습니까? 이게 호스트 운영체제에 해당하죠. 그리고 이 호스트 운영체제를 기반으로 가상기계(Virtual Machine)들이 생성됩니다. 실제기계, 실제머신을 약칭 RM이라고 하고 가상기계 가상머신을 VM이라 합니다. RM에 ESXi를 설치하는 것이고, NIC를 인식 못해서 no network adapter가 발생한다는 문제를 제기하셨습니다. ESXi가 설치되는 RM을 콘솔(console)이라고도 칭합니다. 원래 콘솔은 호랑이 담배피던 시절 메인 프레임의 별칭이죠. 예전에는 콘솔작업과 터미널작업이 구분되어 콘솔 작업은 관리자가 직접 메인 프레임을 조작하는 것을 의미했습니다. ESXi에서는 RM을 Direct Console, 직접 콘솔이라 칭하네요. no network adapter가 발생했어도 직접 콘솔에서 OP(조작)가 가능합니다. 설치 화면에서 콘솔 화면로 빠지려면 alt + F1, 콘솔화면에서 설치화면으로 돌아가려면 alt + F2입니다. 콘솔화면이 나오면 비밀번호 없이 root로 로그인하면 됩니다. 그리고 내용이 이전에 저하고 대화했던 missing operating system 회피에 대한 말씀을 함께 하시나 본데요. 1순위가 바뀌던지 안바뀌던지 어차피 처음에는 vmdk로 아무 이상없이 부팅이 되다가, 설치 중간 재부팅 시에 vmdk로 부팅을 못하지 않습니까? 아예 처음부터 요지 부동으로 부팅 순서가 바뀌지 않는다면 vmdk도 인식하지 못하지 않을까요? 그런데 하여튼 이 문제는 그리 중요한 것은 아니고, 이번 주제글과는 다른 문제네요. 말씀하신 사항은 한 번 점검해 보겠습니다. 이 전 글에서 콘솔로 USB를 마운트해서 드라이버를 설치한다는 말은 좀 잘못되었네요. ESXi 설치를 위해 USB로 부팅한 상태면 마운트가 된 상태구요. 드라이버의 경우에는 설치를 하려면 정상적으로 인식이 가능해야 하는데, 인식가능한 것을 간단히 커스터마이징해서 설치하면 되는데, 굳이 콘솔작업으로 설치할 필요는 없지요. 이 부분은 제가 잘못 설명을 드렸네요. 중요한 것은 여하튼 ESXi에서 인식가능한 NIC이거나, 인식되지 않으면 어떠한 드라이버를 사용해야 하는지 그것이 문제네요. 8168칩셋 NIC도 ESXi에서 아예 인식 못하는 이슈는 저도 오늘 접했습니다. 리얼텍 r8168-8.039.01으로 대부분 설치가 가능한 줄았습니다. 리얼텍 사이트에서는 r8168-8.040.00이 최신 드라이버인데요. 이것으로 가능한지는 모르겠습니다만, 빌드를 해야하는 문제가 있네요. VM웨어가 괜히 HCL을 보여주는게 아닌가 보군요. 애구 .... 호환 안되는 장치를 가진게 죄네요.^^

네트워크가 안되라도 ESXi USB 부트 드라이브에 NIC 드라이브를 저장하고 부팅한 다음에 직접 콘솔 셸로 빠져서, USB 마운트 후에 저장한 드라이버로 설치하는 것이 가능할 겁니다. lspci -v | grep "Class 0200" -B 1 이더넷 콘트롤러 정보를 확인한 다음에 ESXi에서 제대로 작동할 수 있는 드라이버를 설치하시면 되는데요. 문제는 현재 상태에서 어떤 드라이버가 정상 작동을 할지 알 수가 없는 것이네요. 제대로 작동하는 것을 안다면, 굳이 CLI에서 복잡하게 작업하는 것 보다, 그냥 커스터마이징해서 설치하면 끝나는 일인데 말이죠. 제 경우는 NIC가 3개인 경우가 있는데, 메인보드 내장 NIC 1와 추가적으로 ipTIME PX1000 PCI-E 2개의 경우 ESXi에서 네트워크가 설정되지 않아도 콘트롤러로써 인식을 아래처럼 합니다. 02:00.0 Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Giganet Controller Class 0200: 10ec:8168 03:00.0 Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Giganet Controller Class 0200: 10ec:8168 03:00.0 Realtek Semiconductor Co., Ltd. Motherboard 일단 정확하게 NIC 정보와 ESXi 콘트롤러를 확인해 보세요. 그리고 그다음 ESXi와 어떤 문제가 있는지 확인해 봐야겠습니다.

No network Adapters나오면, reboot 하지 마시고, ALT+F1를 누르시면 콘솔 셸로 빠집니다. login : root password: [root@localhost:~]_ 프롬프트로 떨어지고, 커서가 깜빡이죠. 네트워크는 연결되지 않는 상황이죠. 어디까지 가능할지는 .... ESXi도 리눅스계열이에요.^^

혹 제가 잘못기억하는지 몰라도 설치에 실패는 해도 직접 콘솔에 액세스가 가능한 키가 있는 것으로 기억하는데요. 쉬프트-조합인지 .... shift+F1인가.

OEM이 아니라도 8168칩셋 계열 랜카드가 간혹 문제 있는 경우가 있나 보네요. 수동 구성을 하라는 얘기가 있는데요. ESXi 콘솔에서 작업하셔야겠네요. 우분투지만 한글 사용자의 경우 공유한게 있네요. 아래를 참조해 보세요. http://redbadastory.tistory.com/m/post/54

Vendor 10ec : Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller 위에 장치의 경우 일반적으로 설치하는데 이상이 없어 보이는데요. OEM PC라면 일반적이지 않을 수도 있겠군요. 혹시 ESXi 5.0이나 그 이하 버전에서도 NIC를 찾지 못할런지요?

EC10 8168라는게 뭔지 제가 잘모르겠습니다만, 8168칩의 리얼텍 랜카드라면 인터넷에서 얻을 수 있는 드라이버들이 많습니다. 일단 최신이랄 수 있는 ESXi 5.5/6.0에서는 리얼텍 8168용 드라이버를 제공하지 않으니까 vib나 zip를 인터넷에서 다운로드 받아서 커스터마이징하세요. Adding Realtek R8168 Driver to an ESXi 6.0 ISO 위의 포스트를 참조해서 net55-r8168-8.039.01-napi-offline_bundle.zip으로 커스터마이징 하셔도 설치가능할 것입니다.

제가 수차례 테스트한 결과로는 기존의 방법대로 ESXi를 설치하는 상황에서 추가적으로 CD/DVD 드라이브에 부트 이미지만 마운트 시킨상태로 DSM 설치를 진행하면, vmdk 부트 이미지를 못읽거나 변경되어 missing operating system이 발생했어도 다로 다른 순위의 부팅 장치로 마운트된 CD/DVR 드라이브의 이미지를 읽어 DSM 설치가 성공적으로 진행된다는 것입니다. 결과적으로 missing operating system이 발생해도 CD/DVD 드라이브에 XPEnoboot ISO만 삽입한 상태면, 설치는 이상없이 진행이 됩니다.

apple3000님 글을 읽어 보니까 제가 경험하고 파악한 것과는 달리하는 점이 있어 적어볼까 합니다. ESXi에 올라가는 VM의 CMOS는 부팅장치를 우선순위순으로 설정한 부팅 장치를 찾으면서 계속 press any key에 의해서 부팅 이미지를 찾을 때까지 루핑하게 됩니다. 예를 들어 1, 2, 3, 4라는 부팅장치가 있으면, 계속 1-2-3-4를 스캔하면서 부팅 장치를 찾게되죠. 부팅장치 간에는 우선순위로 1순위, 2순위, 3순위, 4순위를 지정할 수 있지만 우선순위가 빠른 장치가 실패할 경우 자동적으로 다음 순위를 찾게 됩니다. 마지막 부팅장치까지 탐색해서 부팅이 불가능할 경우 대기상태에 들어갑니다. 그러다 다시 부팅 가능한 장치를 삽입하고, press any key를 하게 되면 다시끔 부팅장치를 탐색하게 됩니다. missing operating system은 말씀대로 1순위에 해당하는 vmdk 이미지와 연관됩니다. 마운트되지 않거나 찾지를 못하는 것이죠. 그런데 1순위는 1순위일 뿐이지, 부팅에 실패하면 다음 순위는 2순위로 넘어갑니다. 만약 2순위가 PXE라면 DHCP로 부터 IP할당을 받으려시도 합니다. 이것도 실패하면 자동적으로 3순위, 4순위로 CMOS에서 설정된 장치에 접근하게 되겠죠. 결국 모든 부팅장치를 통해서 부팅이 불가능하게 되면, operating system not found 메시지를 출력하고 pause 상태로 있게 됩니다. 1~4순위까지 부팅 순서를 찾는 중에 esc키가 입력되면 다음 순위의 부팅장치로 건너뛰게 되지만, 결국 모든 장치에서 부팅이 불가능하면, operating system not found를 발생시키는데 이 때 CD/DVD 드라이브와 같은 장치에 이미지를 연결하고 press any key를 하게 되면 pause에서 다시 부팅장치를 탐색하고 결국 새롭게 연결된 CD/DVD를 찾아 부팅하게 됩니다. 그것이 제가 설명한 핵심내용이라고 할 수 있죠. missing operating system는 첫번째 1순위로 지정한 부팅장치에서 실패했다는 것만을 의미합니다. 2순위에 해당하는 장치로 부팅이 가능한 순간 순위 자체는 무의미해집니다. 1순위의 장치에 대해 특별히 재설정할 것도 없는 것이죠. 다른 무엇인가가 1순위가 되는 것은 그렇게 중요치 않고, 2순위에서 부팅 가능하면 그것으로 부팅 프로세스는 진행되는 것이라는거죠. XPEnology 설치 과정에서 중요한 것은 설치과정 중에 재부팅에 실패했어도 다른 부팅 장치로 부팅해서 설치 과정이 이어지는게 중요한 것입니다. 결국 설치 과정에서 missing operating system이 발생할 때 CD/DVD의 이미지로 설치과정이 중단없이 이어진다는 것이 중요하다 생각합니다. 또 말씀하신 1~3단계라는 것이 DSM의 설치단계의 재부팅을 말씀하시는 것인데요. 4단계에서 5단계로 넘어가는 마지막 단계에서 재부팅을 하게 되고, 이 때 1순위 vmdk를 통해 부팅이 불가능하니까 missing operating system이 발생하기 때문에, 어쨋든 그 다음 순위가 부팅(여기서는 CD/DVD롬)하게 해줌으로써 설치가 계속되게 한다는 것이 핵심 내용이죠. 문제는 단순하게 vmdk 부팅 이미지만을 못찾는 것이지, 아니면 vmdk가 손상이나 변경되어 부팅을 못하는 것인지 확실하게 어느 경우인지는 모는 상황인데, 제경우는 vmdk에 손상이나 변경이 없는 상태로 보아서는 부팅 이지가가 손상되지 않는 경우라고 할 수 있습니다. 왜냐하면 제 경우는 단순하게 설치 중 콜부팅을 하게 되면 해결되니까요. 그러나 apple3000님이 동영상에서 설명한 것 처럼 vmdk에 손상이나 변경이 생겨서 부팅이 안되는 경우도 있다는 것이고, 그 경우에는 최종적으로 vmdk가 손상되지 않는 이미지로 대체시켜줘야하는데 제경우와는 또다른 경우에 해당합니다. 이렇게 missing operating system도 2가지의 경우도 있다는 것이 되죠. 문제는 중단없는 DSM의 설치입니다. 설치 후에도 DSM의 vmdk가 손상되거나 변경되지 않았으면 좋을 것이고, 손상된 상태라면 apple3000님이 알려주신대로 vmdk의 대체가 필요합니다. DSM설치 과정에서는 비록 1순위 장치에서 설치 실패를 했어도 부팅 순서는 그리 중요한게 아니라는 생각이구요. 어떻게도 제2, 제3, 제4순위의 부팅 가능한 이미지가 마운트되어서 설치를 계속 진행시키느냐가 관건입니다.

본 글의 완전한 제목은 'ESXi에서 missing operating system을 회피해서 XPEnology를 설치하는 방법'입니다. ESXi에서 XPEnology는 VMware vSphere Client를 통해서 설치하게 됩니다. 그런데 VMware vSphere라고 해도 VMware Workstation, VMware Player나 유사한 점이 많죠. 게스트 운영체제 설치나 부팅에 필요한 장치들을 여러가지 방법으로 사용할 수 있다는 점입니다. ESXi에서 XPEnology의 경우는 부트이미지를 담고 있는 .vmdk와 DSM 시스템과 데이터를 저장할 .vmdk로 작동됩니다. 편의를 위해서 XPEnology가 .vmdk를 제공하기도 하는데요. 기본적인 설치방법은 부트 이미지 .vmdk를 이용하는 것이지만, 설치 중간에 missing operating system이 발생할 경우 별도로 XPEnoboot의 ISO를 마운트 시켜 missing operating system을 회피해서 설치를 진행할 수 있다는 것을 알게되었네요. 물론 제가 기술하는 내용이 전혀 새롭거나 뜻밖의 설치 방법은 아닙니다. 이미 XPEnology가 ISO로 부트 이미지를 제공하고 있기 때문이죠. missing operating system로 인해서 설치가 불가능할 경우에 요령을 발휘해서 설치시에는 부트 .ISO를 이용하고, 설치 후에는 .vmdk를 사용하는 것입니다. 별 것도 아닌데 서두가 길었습니다. ESXi상에서 XPEnology 설치시에 missing operating system이 발생해서 설치가 중단된다면, 처음부터 아래와 같은 방법으로 다시 시도해 보세요. 그림을 보시면 쉽게 이해가 가실 것입니다. 추가적으로 XPEnoboot ISO가 마운트된 상태에서 설치합니다. CD/DVD 드라이브는 별도로 특정하지 않습니다. 디폴트상태로 콘솔이 열리면 로컬 ISO가 마운트 될 수 있도록 활성화됩니다. 그 때 XPEnoboot ISO를 마운트해주세요. 0. 모든 것은 vmdk를 이용한 설치방법과 동일한 상태로 시작합니다. 1. 최초 설치단계에서 install/upgrade로 이동만 해둡니다.(Enter 누르면 안 됨) 2. 이제 콘솔 상단의 CD/DVD 드라이브에서 로컬 디스크의 ISO 이미지 연결을 클릭합니다. 3. XPEnoboot의 ISO을 찾아 선택해줍니다. 4. install/upgrade에서 Enter를 치고 설치에 들어갑니다. 5. DSM 설치를 끝까지 마치고, 마지막에 ISO 연결을 끊습니다. 부트 이미지 ISO는 missing operating system가 발생하기 이전부터 아예 마운트를 시키고 설치를 해도 되며, missing operating system이 발생한 시점에서 ISO를 마운트시키고 '아무키나 누르고' 부트를 지속시키는 방법을 사용해도 됩니다. missing operating system이 발생하게 되면, 다른 부트 장치를 계속 찾게 되는데(예를 들어 PXE) ESC를 눌러 빠져나온 다음에 '아무키나 누르면' 마운트한 ISO 부트 이미지를 찾아 부트 메뉴를 출력하게 될 것입니다. 저 개인적인 상황은 missing operating sytem가 발생해도 실제로는 .vmdk의 부트 이미지는 손상이나 변경은 없는 상태인데요. 다른 경우에는 설치 도중에 부트 이미지가 손상되거나 변경이 일어나는 경우에도 missing operating system이 발생하는 경우가 있나 봅니다. 이런 경우는 위에서 처럼 처음부터 설치 종료까지 ISO를 계속해서 마운트 시켜 설치를 하세요. 그 이후에 설치가 종료된 상태에서 apple3000님이 알려주신 방법처럼, 부트 이미지를 대체 시켜 주는 것입니다. VMware vSphere에서 생성한 VM(XPEnology)이 가동중인 경우는 덮어씌워지 않을 것이고, VM을 끄고 데이터스토어에 부트 이미지 다시 업로드 해서 기존 부트 이미지 .vmdk를 덮어씌우시면 됩니다. 감사합니다.

결국은 원인은 모르지만 missing operating system을 회피해서 설치할 수 있는 방법은 로컬 ISO를 마운트 시켜놓고 설치를 모두 안전하게 완료를 한 후에 ISO 대신에 .vmdk로 부팅하는 것이네요. 별도로'missing operating sysem을 회피해서 설치하는 방법'을 정리해서 주제글로 올려놓았습니다.

missing operating sysem에 대한 해결책을 하나 알아냈습니다. 제 경우는 가능했으므로 혹시라도 아래와 같은 방법으로 시도해 보세요. missing operating sysem PXE 부팅 시도 ..... operating system not found 위와 같은 상태에서 콘솔창에 상단에 보시면 CD/DVD 드라이브 있을 것입니다. 여기에 부팅 이미지 ISO를 연결해 주세요. XPEnoboot_DS3615xs_5.2-5592.2.iso 그리고 아무키나 누르시면 위의 CD/DVD로 부팅될 것입니다. 솔루션 1 : 제경우는 DSM 설치 진행 중에 4단계와 5단계 사이에서 재부팅 시에 missing operating sysem이 발생합니다. 이 경우 VM의 전원을 강제로 뜬 다음 다시 켜면 재부팅되어 설치가 계속 진행되더군요. 솔루션 2 : 두 번째 방법으로 1번 처럼 전원을 끄지 않고, 콘솔 창 상단에 CD/DVD 드라이브에 XPEnoboot 부팅 이미지 ISO를 연결해주고, 콘솔창에서 아무키나 누르면 다시 부팅 메뉴 화면이 나타납니다. 이 때 install/upgrade가 아닌 최상단 normal 부팅이 선택되게 합니다. 이렇게 되면 설치가 마지막 5단계까지 진행되는군요. 솔루션 3 : 애플님이 말씀하신 것 처럼 부트이미지 자체가 손상되거나 변경되어져서 missing operating sysem이 발생할지도 모릅니다. 그럴 경우 애플님이 제시하신 방법을 사용해 보세요. 3-1. 일단 VM을 끕니다. 3-2. 데이터스토어에 부트이미지를 재업로드 합니다. 3-3. 다시 VM을 킵니다. (DSM 설치 진행 시간이 끝나기 전까지 다시 VM을 켜야합니다. enjoy!

몇 차례 다른 방법으로 설치를 해보았으나, 제경우는 어떻게 하든 설치가 되네요. 그러니까 제경우는 부트 이미지 .vmdk에 손상내지 변형은 없는 상황인 듯합니다. 단지 설치과정 마지막 단계에서 재부팅을 실패한다는 것이 문제인데, 단순하게 부트 이미지가 연결되지 않거나 장치를 찾지를 못하거나 하는 상황으로 판단이 됩니다. 전원을 껐다 켜는 방법만으로 해결됩니다. 주제글 작성자와 같은 상황을 어떻게 연출시킬 도리가 없네요. 몇 가지 시도한 것을 정리하면 이렇습니다. 1. 설치과정 마지막 단계에서 재부팅이 실패한 경우 데이터스토어 있는 부트 이미지 .vmdk는 변경이 불가능하더군요. 당연하겠지만, 사용 중인 상태이기 때문에 파일이 잠기는 것이지요. 2. 시놀로지 어시스트턴트로 설치를 진행할 경우 여지껏 처럼 단순히 콜부팅하면 해결됩니다. 3. 시놀로지 웹 어시스턴트로 설치를 진행할 경우, 설치가 실패했어도 재부팅을 하게 되면, 마이그레이션 상태가 되어 그대로 설치를 다시 정상적으로 진행시켜 완료가 되는군요. 4. 애플님이 알려주신 방법은 제경우에 효과가 없어 보입니다. 설치가 진행 중에는 파일이 잠기므로 데이터스토어 업로드가 불가능하고, 설치를 중단하고 전원을 끄면 업로그가 가능합니다. 그렇지만 제경우에는 부트이미지가 손상/변경되지 않으므로 파일을 바꾸거나 안바꾸거나 마찬가지임 셈입니다. 결론적으로 저의 경우는 여기 주제글 작성하신 분의 상황과는 다르고, 그러한 상황을 연출할 수도 없는 상황입니다. #. 제상식으로는 부트 이미지를 담고 있는 파일이라면 설치 진행 중에 읽기전용으로 잠겨야 되고, 변경이나 수정이 불가능해져야만 하는데 말이죠. 그래야만 보안상으로도 안정할테고요. 실제로 설치 과정에서 부트 이미지가 손상 또는 변경된다면 참으로 어의없고, 희안한 일입니다.