도록태가 뭔가요
cookis

Recent Comment

2015.06.20 18:06 softwares/quick reference

SR-IOV 적용 가이드를 기반으로 다른 플랫폼에서 테스트를 완료 했고, 실제 서비스 HOST/VM에 SR-IOV 의 할당을 받도록 적용 했지만, 안타깝게도 CPU 사용률은 떨어지지 않았습니다. i350 기가비트의 VF 스펙이 최대 6개 였고 서비스 VM이 6개 이상 올라갔기 때문에, 트래픽이 가중되는 공인(Public)망 쪽 pNIC 및 SR-IOV 가상 스위치를 2개로 나누어 두었는데, 실제 적용 후 모니터링을 해보니 각 SR-IOV 스위치 1/2에 실리는 트래픽이 전혀 다른 상태을 보여줬었습니다.

vSwitch_Public_SR-IOV_1 의 가상 스위치와, HP 366FLR_6 번이 논리적으로 맵핑 된 한 세트이고, vSwitch_Public_SR-IOV_2 와 HP 366FLR_5 번이 나머지 다른 한 세트입니다. 서버를 SR-IOV 1/2 로 각각 50%씩 나뉘어 할당을 했는데요. 실제 SR-IOV1에 할당 된 VM 에서 SR-IOV 활설 상태의 메시지를 확인 했지만, 실제로는 SR-IOV 의 VF/i350 로 통신을 하는 것이 아니고, Hyper-V 호스트 입장에서는 VMBUS를 통한 기존의 가상 스위치로 네트워크 트래픽이 실리는 것이 확인 되었습니다.

이를 반대의 상황인 SR-IOV 가 정상적으로 구성 되었다고 보이는 VM의 내부에서 살펴 보면, 일반적인 SR-IOV 구성으로는 TCP/IP -> Hyper-V 네트워크 어댑터 -> VF Miniport 드라이버 -> VF로 연결이 되기 때문에, 실제로 보이는 트래픽(sent, receive byte)이 가 i350 VF에는 보이지 않더라도 pps 항목의 카운터는 Hyper-V 네트워크 어댑터의 pps 수준과 같거나 비슷한 수치로 표기가 되는 것이 정상입니다. 다시 원래대로 돌아가서 SR-IOV가 적용되지 않은 VM 의 구성을 살펴봤었는데, 여기서는 i350 VF 에서 Hyper-V 네트워크 어댑터에 실리는 네트워크 트래픽을 처리하지 않고 바로 VMBUS/가상스위치로 통신을 하는 것으로 확인이 되었습니다. 각각 SR-IOV1 과 SR-IOV2 스위치에 할당 된 VM 의 차이가 무엇일까? 하고 고민 해봤는데...

SR-IOV 가상 스위치를 생성하기 위한 작업을 시행 했을 때, 담당 작업자가 기존의 VM에 할당 된 가상 스위치를 삭제하기 위해, 일부 VM 에서 vNIC 인터페이스를 삭제를 했던 것이 원인이었습니다. (가상 스위치가 vNIC에 할당(assign)되어있으면 가상 스위치가 삭제 되지 않습니다. 그래서 가상 스위치를 제거가 필요할 때는 vNIC 의 매핑을 '연결 되지 않음'으로  변경하여 할당을 모두 해제하여 작업 합니다)

나머지, 일부 VM은 '연결 되지 않음'의 상태로 할당을 해지하여 작업을 하였고, 문제가 되었던 초기의 일부 VM 은 vNIC (Hyper-V 네트워크 어댑터 #1/#2) 제거 / vNIC (Hyper-V 네트워크 어댑터 #3/#4) 추가의 과정을 거쳤기 때문에 Hyper-V 호스트 상에서는 실제로는 사용하지 않는 Hyper-V 네트워크 어댑터 #1/#2의 고스트 네트워크 어댑터로 SR-IOV 하트비트를 주며 SR-IOV 활성 상태라고 인지하고 있었지만, 실제로 VM 내부에서는 #3/#4번의 Hyper-V 네트워크 어댑터와 VMBus를 통해 네트워크 통신을 하고 있었습니다.

일반적인 작업/과정이라면 이러한 문제가 전혀 발생 하지 않을 가능성도 크지만 (실제로 적용 전 선행 테스트에서는 이러한 상황/버그가 발생 하지 않았습니다) Hyper-V 에서 VM 내부의 상황을 100% 이해하지 못하고 VMBus를 통해 한정적인 정보만을 통신하기 때문에, 이와같이 SR-IOV가 활성화 된 것으로 오인하는 상황이 발생 할 수 있을 것으로 보입니다. Hyper-V 네트워크 어댑터 #1/#2를 삭제하는 과정은 VM 내부에서 cmd / set devmgr_show_nopresetn_devices=1 , devmgmt.msc (보기 - 숨김장치 표시)의 디바이스 관리자에서 비활성화 된 Hyper-V 네트워크 어댑터 #1/#2 를 각각 삭제하는 것으로 해결이 되었습니다.

트러블슈팅 과정만 보면 굉장히 논리적인 추측으로 구간 별로 부드럽게 측정, 진행 되었다고 보일 수도 있지만, 실제로는 SR-IOV 로 연결된 구조 / 네트워크 흐름도를 모두 파악하고 구간 별로 위치한 디바이스를 성능 모니터링의 카운터를 통해 원인을 유추하는 과정이 쉽지 많은 않은 과정입니다. 다만 중요한 것은 이 모든 과정을 시행할 수 있도록 성능 모니터를 통해 부담 스러울만큼 많은 모니터링 요소를 제공 해준다는 사실입니다. 일반적인 작업 과정으로 트러블슈팅 없이 SR-IOV가 한번에 적용 되었다면 결과적으로는 만족했겠지만, 그 만큼 SR-IOV를 더 잘 이해할 수 없었거나, 단순한 옵션 체크 박스 하나로만 인지할 가능성이 높았기 때문입니다.

 

VMWare vSphere 에서의 SR-IOV 구성도


references

http://blogs.technet.com/b/privatecloud/archive/2012/05/14/increased-network-performance-using-sr-iov-in-windows-server-2012.aspx
http://blogs.technet.com/b/jhoward/archive/2012/03/12/everything-you-wanted-to-know-about-sr-iov-in-hyper-v-part-1.aspx
http://blogs.technet.com/b/koalra/archive/2012/08/07/windows-server-2012-hyper-v-io-sr-iov.aspx
https://msdn.microsoft.com/en-us/library/windows/hardware/hh451362(v=vs.85).aspx
https://msdn.microsoft.com/en-us/library/windows/hardware/hh440238(v=vs.85).aspx
https://msdn.microsoft.com/ko-kr/library/hh440150(v=vs.85).aspx
https://www.youtube.com/watch?v=hRHsk8Nycdg
http://h20565.www2.hp.com/hpsc/doc/public/display?docId=emr_na-c03514877
http://www.intel.com/content/dam/www/public/us/en/documents/technology-briefs/ethernet-sr-iov-microsoft-windows-brief.pdf
http://www.windowsnetworking.com/articles-tutorials/windows-server-2012/single-root-io-virtualization.html

posted by cookis
2015.06.19 23:37 softwares/quick reference

일반적으로 서버 가상화 환경에 올라가는 어플리케이션들의 종류를 보면 대부분 웹이나 게임 서버 등의 TCP 소켓 기반의 연결 혹은 연결 지향형 어플리케이션들 위주로 올라가고, 빠른 반응 속도(network latency)를 위해 디자인 된 UDP 프로토콜 기반의 중계 어플리케이션들은 (ex> Dedicated 서버 혹은 Relay 서버) 애초에 가상화 대상이 아니거나 물리 기반의 서버에서만 운용을 하던 것이 대부분이었습니다. 이유를 살펴보면 TCP 프레임에 비해 상대적으로 많은 수의 패킷을 처리하고 UDP 프레임을 인코딩/디코딩 하는 과정에서 많은 CPU의 오버헤드를 발생할 수 있어서 CPU 의존도가 높아서 그렇다고 합니다만, Hyper-V 기반의 VM에서 이와 같은 '데디 혹은 릴레이' 서버의 적용을 위한 트러블 슈팅 과정이있어 구성가이드 및 트러블 슈팅기를 정리해 둡니다.

실제로 Hyper-V VM 으로 구동 되는 VM 에서 문제가 발생하기 시작한 시점은 Hyper-V의 NIC를 이용한 Virtual Switch의 업링크 인터페이스(NIC)에서 수신 150,000 (150k), 송신 300,000 (300k), 총 450,000 정도의 PPS 에서 네트워크의 지연 현상이 발생하기 시작 했습니다. Hyper-V 호스트의 유저 모드에서 특정 코어의 CPU 사용률이 100%를 기록하고 있었고, 이 CPU peak의 원인을 네트워크로 지목하게 된 이유에는 'Hyper-V Virtual Switch Processor' 의 성능 모니터를 봤을 때, Root VP (Virtual Processor) 0번 에서 물리 NIC에 실리는 전체 패킷과 동일한 양의 패킷을 처리하고 있었기 때문입니다.

이러한 가상화 환경에서 VM의 네트워크 성능을 끌어올리는 기술은 VM(d)Q 혹은 Single Root-IO Virtualization 등을 제안할 수 있습니다만, 실제로 현업 환경에 적용해 본 케이스는 없었기 때문에 테스트를 하면서도 잘 될까? (효과가 있을까?) 잘 하고 있나 하는 등의 걱정이 있었던 것은 사실입니다. VMQ에 대한 내용이나 장 단점에 대해서는 다른 글에서 기술하도록 하고, 이 글에서는 SR-IOV 에 대한 기술만 하도록 하겠습니다. SR-IOV에 대한 개념, 원리등은 아래 references 링크를 통해 확인하시면 많은 도움이 될 것 같습니다. 문서를 통해 Microsoft 에서 가이드하는 SR-IOV에 대한 성능을 향상에 대한 부분은 낮은 CPU 사용량 (최대 50%), 낮은 네트워크 레이턴시 (최대 50%), 더 높은 네트워크 대역폭 (최대 30%)로 가이드 하고 있습니다. (서비스/서버마다 어느 정도의 네트워크가 사용 될 지 알 수 없기 때문에 굉장히 보수적으로 잡은 가이드 이긴 합니다)

 

HP에서 제공하는 SR-IOV Implement 문서를 발췌 해보면,

일차적으로 서버의 BIOS 설정에서 SR-IOV의 항목을 Enable 해주어야 합니다. SR-IOV 기술 자체가 PCI-SIG를 통해 제정 되긴 했지만, 기본적으로는 인텔의 VT-D를 이용한 기술입니다. 이는 물리 서버의 PCIe 레인에 설치 된 하드웨어 (여기서 정확히는 pNIC)를 VM레벨에서 물리(PCI-Passthrough) 혹은 가상의 디바이스(SR-IOV/VF)로 인식 시켜주는 기술이므로 하드웨어 설정의 도움을 받아야 합니다 (실제로 SR-IOV가 Passthrough로 작동하는 것은 아닙니다) 이 설정을 함으로써 포트 별이 아닌 전체 네트워크 카드에 대해 SR-IOV 옵션이 적용 되므로, 이 옵션을 사용하기 전에 SR-IOV 를 사용하지 않은 상태로 vSwitch를 만들어 관리 IP를 등록하여 사용하였다면, SR-IOV 가 적용 됨으로써 원격에서 접근이 불가능 상태가 발생할 수 있으므로 콘솔에서 메인터넌스 작업을 하거나, 콘솔의 도움을 받는 것을 추천합니다.

BIOS에서 SR-IOV 를 활성화 하였다면, Hyper-V 관리자의 가상 스위치 관리자에서 'SR-IOV 사용' 을 확인 하여 가상 스위치를 새로 만들어 줍니다. 물리 서버에서 인식하는 pNIC의 디바이스 정보가 바뀌었기 때문에, 기존에 사용하던 가상 스위치는 사용할 수 없을 것으로 보입니다. 다만, 이렇게 기존의 가상 스위치를 삭제하고 생성하는 과정에서 VM에 할당 된 vNIC는 반드시 vNIC를 삭제하지 않고, 할당 해제 후, 가상 스위치를 삭제 하도록 합니다. (이유는 다음 트러블슈팅 글에서 다시 기술) 운영 중인 서버가 아닌  신규 셋업이라면 무시하고 바로 진행 하여도 됩니다.

각 VM 의 설정 정보에서 vNIC 의 네트워크 정보 '하드웨어 가속' 에서 SR-IOV 를 사용으로 바꿔주고 확인을 누르면, 아래의 VM 상태 창, 네트워킹 탭에서 SR-IOV 가 활성화 된 항목을 확인할 수 있습니다. SR-IOV 의 적용 유/무는 온라인 상태에서 즉시 적용 가능하며, SR-IOV 를 지원하지 않는 타 물리 서버와의 VM 이동 (migration) 호환성도 갖고 있습니다. (EVC 등의 프로세서 호환성과는 무관) 

SR-IOV는 pNIC의 프로세서를 사용하는 하드웨어 장치이기 때문에, pNIC의 스펙에 대한 의존성을 갖고 있습니다. 이게 무슨 말인가하면 기가비트 기반의 Intel i350 에서는 6개의 VF (Virtual Function)을 제공하고 있는데, 이를 해석하면 1개의 pNIC 포트에는 최대 6개의 VM 밖에 할당하지 못한다는 이야기 입니다. 스펙으로 확인한 대부분의 10GbE pNIC 에서는 62개 대역의 VF를 갖고 있으나, 기가빗 기반의 이더넷 pNIC 들은 이러한 스펙상의 한계를 갖고 있습니다. (참고로 인텔 NIC 기가비트 모델에서는 GT/MT/PT/GT/VT/ET 등의 다양한 모델이 있지만, SR-IOV를 지원하는 기가빗 컨트롤러는 ET 이후 세대에서만 지원 합니다. ET 듀얼 포트 NIC의 중고가가 PT/VT 보다 두 배이상 높은 이유이기도 하고요. emulex/broadcom 등의 최근 나오는 대부분의 10GbE는 SR-IOV를 지원 합니다)

pNIC 의 포트를 더 할당하여 두 번째 SR-IOV 가상 스위치를 만들면 (당연히도 TOR 스위치에 케이블링/연결 필요) 한 대의 VMHOST 에서 6개 VF 스펙 이상의 VM 을 구동할 수 있습니다만, SCVMM 에서 VM을 자동으로 할당하고자 할 때도 정해진 가상 스위치의 이름이 아니거나, 실제 트래픽이 heavy 하는 실리는 공인/사설망 등의 분리 여부 (확인 필요) 등의 관리의 복잡성이 증가할 수 있습니다.

VM 내부에서 보면 Hyper-V 네트워크 어댑터외에 pNIC 의 장치 이름인 i350 Virtual Funtion이 확인 됩니다. 이는 VM 레벨에서는 TCP/IP - Hyper-V 네트워크 어댑터 - VF Miniport Driver - VF NIC (i350) 등의 연결 절차를 거치게 되고, SR-IOV 가 적용 되지 않은 일반적인 VM 에서는 TCP/IP - Hyper-V 네트워크 어댑터 - VMBus - Virtual Switch 등의 연결 절차를 이용하게 됩니다.

Child 1의 VM 이 SR-IOV를 타지 않는 구조이고, Child 2가 SR-IOV가 적용 된 연결 구성도 입니다. 결과적으로는 Child 1의 구성으로는 VMBus를 통한 가상 스위치 쪽에 트래픽/패킷이 몰리면 호스트 유저 모드의 특정 CPU를 사용할 가능성이 높아져서 결국은 전체 VM 네트워크의 지연 현상으로 이어지게 되었습니다. 이러한 구조의 가상 네트워크를 pNIC 기반의 하드웨어 장치로, VM 레벨에서 p/VF NIC 을 할당 하여 가상 스위치의 서비스 프로세서의 CPU 사용율을 덜어주는 기술이 바로 이 SR-IOV 입니다.

PS C:\Windows\system32> get-vmhost | fl
....
IovSupport                                : True
IovSupportReasons                         : {OK}
VMHost 에서 SR-IOV 지원 여부 확인, BIOS 설정이 안 되어있을 경우 IovSupportReasons 에서 표기


PS C:\Windows\system32> get-netadaptersriov
....
Name                 : Public_SR-IOV_1
InterfaceDescription : HP Ethernet 1Gb 4-port 366FLR Adapter #6
Enabled              : True
SriovSupport         : Supported
SwitchName           : DefaultSwitchName
NumVFs               : 6
VMHost 에 장착 된 pNIC 의 스펙 및 VF 개수 확인

PS C:\Windows\system32> get-netadaptersriovvf

Name                           FunctionID VPortID MacAddress        VmID                           VmFriendlyName
----                           ---------- ------- ----------        ----                           --------------
Public_SR-IOV_2                0          {1}     00-15-5D-07-B9-0D 35C08A38-AB24-46D8-A415-A03... VMTEST11
Public_SR-IOV_2                1          {2}     00-15-5D-07-B9-11 3C7B056A-866F-4CD9-8687-495... VMTEST22
Public_SR-IOV_2                2          {3}     00-15-5D-07-B9-12 7BDE3915-1251-4912-8744-EA0... VMTEST33
Public_SR-IOV_2                3          {4}     00-15-5D-07-B9-0F 13959A5D-164B-4203-8CB5-E06... VMTEST44
SR-IOV 어댑터에 할당 된 VF 포트 및 VM 네임을 확인

SR-IOV를 통해 실행 되는 VM을 구현하기 위한 필요 사항

1. SR-IOV / IOMMU 를 지원하는 시스템보드
2. VT-D / SLAT 를 지원하는 CPU
3. SR-IOV를 지원하는 NIC
4. Windows Server 2012 or VMWare Hypervisor 
   (Windows 8의 Hyper-V 는 SR-IOV를 지원하지 않습니다. VMQ는 지원)
5. 기타 : 네트워크 NIC Teaming 구성일 경우에는 SR-IOV를 지원하지 않음

posted by cookis
2015.06.11 20:46 softwares/quick reference

Case1
물리서버/SQLServer에서 (Hyper-V)가상서버/SQLServer 로 로그 전달을 구성 시 아래의 경고 메시지가 발생한다.

The tail of the log for database DATABASE_DBN is being rewritten to match the new sector size of 4096 bytes.2048 bytes at offset 836282368 in file X:\dblog\DATABASE_DBN.ldf will be written

Case2
물리서버/SQLServer에서 백업된 풀백업/트랜잭션 백업 데이터를 (Hyper-V)가상서버/SQLServer 에서 복원 시 (restore database) 메시지 9004 로 오류가 발생한다.

 

이와 같은 문제가 발생하는 원인은 일반적으로 물리 서버일 경우 디스크의 Physical Secor Size가 512byte 혹은 512e의 4k 에뮬레이션을 사용합니다만, Windows Server 2012 이후의 Hyper-V 에서 채택하고 있는 VHDX 디스크 이미지에서는 4K (혹은 Native 4K) 의 방식을 기본으로 사용하기 때문에 물리적 디스크의 구성을 최대한 활용하려는 알고리즘을 가진 SQLServer에서 이 디스크 환경의 차이를 인식하지 못하여 (align을 정확히 맞추지 못하여) Case1처럼 오버헤드가 발생하거나, Case2 와 같은 SQLServer 내부의 버그로 인한 복원 오류가 발생 합니다.

해결방법은 "Set-VHD –Path c:\test.vhdx –PhysicalSectorSizeBytes 512" 명령어를 통해 VHDX 파일을 4K에서 512 byte 디스크의 형식으로 바꾸어 주면 됩니다. 원본도 4K 에서 백업되었고, 복원도 4K에서 한다면 문제가 없을 걸로 보여 (VMtoVM), 물리toVM 에 대한 문제로 오해할 수 있겠지만, 실제로는 물리서버와 가상화 서버의 환경 (정확히는 설정)의 차이로 이와 같은 문제가 발생합니다. 2번의 케이스에서 SQLServer 2008 에서는 복원 시 9004에 대한 핫픽스 (정확히는 Service Pack2)를 제공 하고 있지만 (제보로는 제대로 안 된다고...-_-;;), SQLServer 2012에서는 이와같은 핫픽스를 (아직까지는) 제공하지 않고 있습니다.

이와같은 NTFS 의 Physical sector size 는 fsutil fsinfo ntfsifno X: 명령어로 확인할 수 있고, 아래와 같이 총 4개의 케이스로 나뉘어집니다. 일반적인 컴퓨팅에서는 문제가 없으나, 디스크 섹터 단위로 align을 맞추는 SQLServer 에서는 위에서 설명한 것과 같이 갖가지의 문제가 발생할 가능성이 있습니다. 특별한 설정을 하지 않고 생성된 .VHDX 는 기본적으로 4K 포맷으로 생성 되어있고 (.VHD 는 512byte) 이를 512 byte의 .VHDX 로 변환하기 위해서는 할당 된 VM 의 디스크를 종료 / Set-VHD cmdlet 으로 간단히 변경할 수 있습니다. (작업은 데이터 유실 없이 곧바로 진행 됩니다)

섹터당 바이트 512
실제 섹터당 바이트 512

섹터당 바이트 512
실제 섹터당 바이트 <지원되지 않음>

섹터당 바이트 512
실제 섹터당 바이트 4096

섹터당 바이트 4096
실제 섹터당 바이트 4096

 

추가로, 하드웨어 기반의 SQL Server 에서는 디스크의 성능을 개선하기 위한 튜닝 방법으로 Disk Partition Alignment 라는 방법이 사용 되는데, 요약하면 RAID Logical Volume 의 Stripe Size 와 NTFS Allocation SIze (클러스터당 바이트)를 같은 크기로 생성하여 최소 단위 작업 (혹은 Queue) 발생 시 물리적 디스크와 NTFS의 클러스터 사이즈의 align을 맞추어 주는 작업입니다. Windows 2003 까지만 하더라도 디스크 Partition 의 start offset을 수동으로 지정하여야 했지만, 2008 이후로는 이러한 작업이 필요 없는 상황입니다. 따라서, Hyper-V를 운영하는 호스트의 경우에도 이와 같이 64K Stripe SIze, 64K NTFS 로 설정하고 VM Guest 내부에서 사용 되는 데이터 디스크의 클러스터 사이즈도 64KB 로 맞추어주면 이론상으로는 최적의 성능을 낼 수 있습니다.

 

references
https://technet.microsoft.com/en-us/library/hh848561(v=wps.630).aspx
https://support.microsoft.com/en-us/kb/2987585
https://msdn.microsoft.com/en-us/library/windows/desktop/hh848035(v=vs.85).aspx
http://support.microsoft.com/kb/2624272
http://blogs.msdn.com/b/psssql/archive/2011/09/27/after-applying-sql-server-2008-r2-sp1-error-9013-is-logged-the-tail-of-the-log-for-database-ls-is-being-rewritten-to-match-the-new-sector-size-of-d-bytes.aspx
http://blogs.msdn.com/b/psssql/archive/2011/01/13/sql-server-new-drives-use-4k-sector-size.aspx
http://www.seagate.com/kr/ko/tech-insights/advanced-format-4k-sector-hard-drives-master-ti/
https://technet.microsoft.com/en-us/library/dd758814(v=sql.100).aspx
https://blog.workinghardinit.work/2012/07/10/windows-server-2012-with-hyper-v-the-new-vhdx-format-lead-the-way/

 

posted by cookis
2014.06.19 11:24 softwares/quick reference

시나리오1.
Hyper-V Host 에서 VHD 가 담긴 디스크의 물리/논리적 재구성이 필요하여, 드라이브를 비웠다가 다시 구성해야할 경우

시나리오2.
VM 을 정상적으로 내보내지 않고 오프라인 상태로 VM 의 파일들을 (Virtual Machines 의 XML 파일과 Virtual Hard Disks) 의
구조를 그대로 복사해서 백업하거나 가져올 경우

 

시나리오1의 경우로 VHD 파일이 저장된 디스크의 재구성 (DISK * 6 에서 DISK * 2 로 축소)이 필요하여 D:\VHD\ 아래에 저장된 VM 별 폴더를 다른 디스크로 이동 후 (이동 시 삭제하지 못하는 문제는 서비스에서 Hyper-V 가상 컴퓨터 관리를 잠시 중지) 디스크 재구성 후, 기존 환경과 동일한 경로로 다시 이동 후 VM 을 시작 시, 아래와 같은 권한의 문제로 VM 을 시작하지 못하는 문제가 있습니다.

정상적인 Hyper-V VM 의 디스크 VHD 의 권한을 보면 Hyper-V VM GUID 의 이름으로 VHD(X)의 권한이 들어가게 되는데, 이 권한이 파일을 복사하는 과정에서 유실 되어 발생 되는 문제입니다. icacls 를 통해 각 VM 의 GUID(SID) 권한을 할당하여 이를 해결할 수 있습니다. 그렇지 않은 경우라면, Hyper-V 관리자에서 내보내기 후, 가져오기를 시행(새로운 GUID 권한을 할당 하는 과정을 수행)하거나, 새로운 VM 을 생성 후, 기존 DISK만 연결하는 방식으로 복구 할 수 있습니다. (Virtual Machines XML에 저장된 VM 설정이 초기화 되기 때문에 이 경우는...)

ICACLS 를 통해 아래와 같은 명령어로 권한을 다시 할당할 수 있고, GUID/SID 는 Virtual Machines 폴더 밑에 GUID.XML 의 이름으로 파일이 생성 됩니다.

ICACLS SYSTEM.VHDX /GRANT "NT VIRTUAL MACHINE\SID:(R,W)"

 





시나리오3.

정상적으로 내보내기 및 가져오기 과정을 거쳤음에도 불구하고, 'Unnamed VM'이(가) 가상 컴퓨터 구성을 읽거나 업데이트할 수 없습니다. 보안 식별자 구조가 올바르지 않습니다. (0x80070539). 메시지와 함께 정상적으로 시작이 안 되는 경우 파워쉘 Get-VM 후, Grant-VMConnectAccess -Username Administrator -VMName "VMName" 의 명령어로 권한을 복구 해주면 정상적으로 시작이 됩니다.

 

posted by cookis
TAG hyper-v
2014.04.26 22:36 softwares/quick reference

Windows Server 2012 R2 부터 추가 된 기능 중, 가장 마음에 드는 것을 하나 꼽으라면 VM을 끄지 않더라도 내보내기 할 수 있는 "온라인 내보내기" 입니다. 기존 2012 까지만 하더라도 VM Guest를 복제하기 위해서는 반드시 VM을 꺼야 했었는데, 2012 R2 부터는 VM을 끄지 않고, 저장된 상태로 다른 호스트 혹은 복제를 할 수 있습니다. 이 기능을 쓰면서 발견한 문제인데, 종종 네트워크 (L2 Layer)에서 Mac Flapping 이 발생한다는 것이 었습니다. 저희 사이트에서는 고정 MAC이 아닌 동적 MAC을 사용하고 있었는데, VM을 복제해서 사용하면서 이와 같은 MAC 충돌이 발생 했습니다.

결론만 말씀드리면, 온라인 내보내기 후 가져오기를 한 다음 VM의 종료/시작을 안 한 것이 원인이며(VM 내부의 재부팅은 해결이 되지 않습니다), 자세한 원인을 찾기 위해 찾아본 결과 Hyper-V 에서 동적 MAC을 할당하는 구조를 알게 되었습니다.

VM 의 MAC 이 00-15-5D-98-1E-07 일 경우, 앞의 세 자리 00-15-5D는 Microsoft 에서 Hyper-V 에만 할당해서 쓰는 대역이며, 98-1E 는 호스트에 Hyper-V 롤을 설치할 당시의 Physical NIC 에 할당 된 IP의 세번째, 네번째의 옥탯에 해당하는 16진수 입니다. (Hyper-V 호스트의 ip가 192.168.152.30 일 때, 세번째 옥탯 152에 해당하는 98 / 30에 해당하는 1E가 할당 됩니다.) 마지막 자리 07 은 서버에서 자동으로 할당 되는 주소이며 기본 설정으로는 호스트 한 대당 최대 255개까지의 MAC만 할당할 수 있습니다. (http://support.microsoft.com/kb/2804678)

이와 같은 사실로 추정해보면 1.1.152.30 의 호스트에서 동적으로 할당 된 MAC과 1.2.152.30 의 Hyper-V 호스트에서 동적으로 할당 된 MAC 은 중복이 될 가능성이 있으며, (동적 MAC 의 영역은 실제로는 희박하다고 하더라도 서버마다 같은 IP를 가진 상태로 Hyper-V 롤이 설치 될 경우는 충돌 가능성이 아예 없지는 않습니다) 반대로 VM의 MAC 을 알면 어느 호스트에서 할당 된 것인지 (혹은 사용 중인지) 확인이 가능합니다.

각 호스트에서 Get-vmNetworkAdapater -all 의 결과

HOST1

AA-GAME01 vSwitch-Public  00155D981F07
AA-GAME01 vSwitch-Private 00155D981F08

HOST2

BB-GAME01 vSwitch-Public  00155D981F07
BB-GAME01 vSwitch-Private 00155D981F08


이 문제를 조금 더 확장해서 살펴보면, HOST1 에서 HOST2로 Live Migration 이나 Replica 의 환경도 한번 더 확인을 해봐야 하겠는데요, Live Migration 시에는 HOST1 에서 할당 된 MAC 을 HOST2로 이동 시, 그대로 HOST1 대역의 MAC 을 들고 이동하기 때문에 문제가 없습니다. 하지만 HOST 2번에 있다가 점검을 위해 VM의 전원을 껐다 킬 때 문제가 되는데요. 이 때부터는 HOST2 대역의 MAC을 가져오게 되어있습니다. (Replica 는 꺼져 있는 상태이니 Replica HOST 의 MAC 대역을 가져오겠고요)

여기까지가 윈도우 계열의 VM 및 전체적인 환경에 대한 이야기이고, Linux VM (특히 CentOS, RedHat 계열)의 경우는 똑같지만 약간 다른 방식으로 작동합니다. 왜냐하면, CentOS 에서는 동적으로 할당 받은 VM 의 MAC을 파일로 시스템 설정의 파일로 저장하고 있습니다. 윈도우의 경우 가상 NIC의 MAC이 바뀌더라도 IP를 할당 받지 못하는 경우가 없으나, Linux VM의 고가용성 환경 (Live Migration) 혹은 Replica 구성의 경우, 옮겨 가서 VM의 전원이 ON 될 때 기존의 NIC 에 설정 된 IP를 불러오지 못하는 경우가 발생 합니다.

따라서, 결론은...

이와 같이, Linux VM 의 고가용성 (혹은 Replica 구성)을 구성할 경우 반드시 VM NIC 의 MAC을 고정 (Static) 으로 사용하도록 설정 할 것이며, 동적 MAC을 사용하게 될 경우 FailBack을 설정하거나, 장애 조치 시 복구 가능한 시나리오를 확인 하는 것이 우선 입니다. CentOS 계열의 VM을 복제하여 사용 할 경우, /etc/sysconfig/network-script/ifcfg-eth0 의 HW_ADDR 을 지우고 /etc/udev/rules.d/70-persitent-net.rules 의 할당 된 MAC 을 지워야 합니다 eth0/1로 올라오게 됩니다.)

 

Important Considerations for Making Linux Virtual Machines Highly Available in Failover Clustering and Hyper-V Linux virtual machines that will be deployed in a highly available scenario (using Failover Clustering) should be configured with static MAC addresses for each virtual network adapter.

Because of the way Linux configures the network adapter, in some versions of Linux, it is possible that the networking configuration will be lost after failover because a new MAC address might be assigned to the virtual network adapter.

To work around this issue, ensure that each virtual network adapter has a static MAC address by editing the settings of the virtual machine in Hyper-V Manager.

references
http://support.microsoft.com/kb/2804678
http://www.padisetty.com/2013/09/centos-64-on-hyper-v.html

posted by cookis
2014.04.26 21:52 softwares/quick reference

Hyper-V VM 시작 시, 사용 가능 한 메모리 (Available Memory)가 충분함에도 불구하고 시스템의 메모리가 부족하다고 에러를 뱉는 경우가 있는데 대부분 호스트 서버를 재시작 하면 해결 되긴 합니다만, 이는 작업 관리자에서는 Available Memory를 Standby + Free 로 표시하고 있고, Hyper-V 에서는 Free 영역에만 메모리를 할당 할 수 있어서 발생하는 문제 입니다.

이 대기 메모리 (Standby Memory, OSX 에서는 inactive memory)는 재사용을 할 수도 있고, 안 할 수도 있는 영역입니다만, Sysinternals 의 RamMap을 통해 Standby Memory를 비워주고 VM 을 시작 하면 정상적으로 VM 에 메모리가 할당 되고 실행 됩니다.

http://technet.microsoft.com/ko-kr/sysinternals/ff700229.aspx

posted by cookis
2014.04.26 15:53 softwares/quick reference

Hyper-V 에서 Windows 계열의 OS를 설치 시, Intergration Component를 같이 설치하면 가상 하드웨어(네트워크) 드라이버를 같이 설치하게 되어 최적의 VM Guest의 상태로 운영 됩니다만,-Windows 계열의 (, Linux) OS에서는 이와 같은 IC Linux Kernel 혹은 배포본에 포함 되어있습니다. 하지만, 이 Linux용 IC는 Windows VM과는 다르게 아무리 최신 버전으로 설치를 해도 Degraded 에서 Ok 상태로 올라오지 않습니다.

“저하됨(Degraded)” 으로 표시되는 것과는 다르게, 실제로는 Hyper-V 프로토콜을 통해 백단(backward compatible)에서 호환되어 이용 되고 있으며 이는 다음 Hyper-V 릴리즈 에서는 정상적으로 표기 될 예정이라고 합니다.

실제로, 이 문제가 KB에 발표되기 전에 Windows Azure에서 Ubuntu Linux 인스턴스를 생성하여 확인 했을 때, 동일한 버전의 IC를 사용하고 있었으므로 Linux에 포함되어있는 현재의 버전이 가장 최신 버전의 IC라고 보시면 될 것으로 보입니다.

Cause

The various messages shown in the symptoms section occur because the non-Windows guest integration services may not always have the code to interoperate with the latest Hyper-V protocols. This is due to the fact that Windows release cycles are not in sync with the release cycles of other operating systems. As a hypothetical example, the latest Red Hat Enterprise Linux (RHEL) release may ship in January but the latest Windows release may ship in the following September. Between January and September, the Windows team may upgrade the Hyper-V protocols due to which the RHEL release shipped in January may have integration components that were written based on earlier Hyper-V protocols. Now, when a user tries to run an older RHEL release as a virtual machine on a newer Windows release then they may observe messages suggesting that the RHEL integration components are degraded.

Resolution

Users are hereby advised to ignore all messages and warnings that seem to indicate that no technical support will be provided because integration services for a non-Windows guest virtual machine are degraded. Microsoft will provide technical support even if when such messages are visible while running supported non-Windows guests on Hyper-V. Linux users may review a list of supported distributions on Hyper-V on the following page: Linux Virtual Machines on Hyper-V

Note that it is safe to ignore these messages because Hyper-V protocols are implemented to be backward compatible. Therefore, even if a certain non-Windows guest has integration services that were based off earlier Hyper-V protocols, the guest is expected to run flawlessly on newer Hyper-V releases


references
http://support.microsoft.com/kb/2956569

posted by cookis