도록태가 뭔가요
cookis

Recent Comment

2016.01.29 13:46 softwares/quick reference

http://new.office-watch.com/2016/january-2016-office-hidden-bug-fixes-and-mysteries/

After you save an email message to an .msg file in Outlook 2016,
the attachment in the email message is displayed as 0 kilobyte (KB).

내용을 발췌해보면 아웃룩 2016에서 메일 메시지를 .msg 형태로 뺄 때, 파일 사이즈가 0KB로 나오거나
정상 사이즈의 파일 사이즈를 갖고 있더라도, 빈 화면으로 표시되는 버그가 있었는데
(아.. 내가 이것 때문에 매번 .mhtml 로 따로 저장해서 메시지를 보냈었음.. ㅜㅜ)
오피스 2016 출시 되고 4달이나 되어서야 버그가 수정 되었네... ㅜㅜ

MS Word 2016 은 쉐어포인트에서 공동 작업이 (저장이..) 안 되다, 어느 순간부터 업데이트 후에 되질 않나...

 

 

January 2016 Office ‘hidden’ bug fixes and mysteries

For a long time, Microsoft has quietly fixed bugs in Office, which is a good thing.  Not so good is their habit of hiding news of these fixes.  If you’ve been suffering with a particular bug, it’s hard to know when or if it’s been fixed.

Among the January 2016 fixes are these (using Microsoft’s bug description):

Office 2016

  • After you change from Mouse mode to Touch mode in Office 2016 applications, the Quick Access Toolbar (QAT) icons aren’t enlarged. KB3114536
  • After you use Office deployment tool to install Office 2016 Click-to-Run editions with multiple language packs, the language that is set in the config.xml as the first language isn’t set as the default language.   KB3114530
  • After a user overrides a policy tip for a document in an Office 2016 application, the information doesn’t appear in the Data Loss Prevention (DLP) report.  KB3114512

Outlook 2016

  • After you save an email message to an .msg file in Outlook 2016, the attachment in the email message is displayed as 0 kilobyte (KB).
  • You start Outlook 2016, and you use a right-to-left language. In this situation, when you move another window over Outlook 2016, a redraw issue occurs, and the background of Outlook 2016 isn’t repainted correctly. Therefore, it is difficult to read the content in Outlook 2016. KB3114536
  • Translates some terms in multiples languages for the accuracy of the meaning.
  • Assume that you send a meeting request that is in the HTML format in Outlook 2016. When you open the meeting request, the attachment is missing.  KB3114532

Excel 2016

  • When you edit the text in a chart and then select the Font Size drop-down list and pause on different font sizes in Excel 2016, Excel 2016 may crash.  KB3114531

Access 2016

  • You can’t connect to a SharePoint list in Access 2016 if the list contains a column in which the name is longer than 10 double-byte character set (DBCS) characters.  KB3114689

OneNote 2016

  • When you delete a bullet in a notebook in OneNote 2016, the ink in the notebook may disappear or OneNote 2016 may crash.   KB3114534

All the above bug fixes are described in their Knowledge Base articles under the heading “Improvements and fixes”.

But what are customers supposed to make of these three mysterious KB articles … KB3114533   KB3114525 and  KB3114521

They have no ‘improvements and fixes’ heading at all!  There’s nothing to indicate what (if anything) the Office updates do!

 

posted by cookis
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
2015.06.03 17:59 softwares/quick reference

Haswell-EP (E5-26xx v3) 를 탑재한 모델 (정확히는 10-Core 이상 부터 적용)에서 추가 된 BIOS 옵션

설정 요약

1. SQL Server, Hyper-V 등의 NUMA Aware Application 에서는 QPI Snoop 을 Cluster On Die로 설정
   기존 NUMA 아키텍쳐에서 2 Socket 기준 VM 1개의 최대 메모리 사용량이 1/2 이었다면, COD에서는 1/4로 가용량이 줄어듬
2. Hyper-V 에서의 1개의 최대 VM 메모리가 전체 메모리의 1/4을 초과 하는 경우에는 기본 설정 (Home Snoop)을 유지
   (ex> vNUMA 를 지원하지 않는 Legacy Linux VM 등등)
3. NUMA 를 인식하지 않는 Application에서는 (non-aware) 에서는 Early Snoop 을 설정

아키텍쳐 요약

1. 샌디 브릿지 EP 부터 L3 캐시 정책이 링버스로 변경 (코어의 증가로 인한 경로 축소)
2. CPU 코어가 늘어나면서 L3 캐시 접근 정책도 다양화 됨 (경로에 따라 CPU CORE/L3 캐시의 레이턴시가 불균일 해짐)
3. 불균일한 레이턴시를 줄이기 위해 1 Socket 의 CPU 1개를 NUMA 개념으로 2개의 도메인으로 나누어 사용

벤더 (HP)에서는 아래와 같이 요약 하고 있음

This option allows for the configurations of different snoop modes that impact the QPI interconnect. Changing this option may improve performance in certain workloads. Home Snoop provides high memory bandwidth in an average NUMA environment (default setting). Cluster on Die may provide increased memory bandwidth in highly optimized NUMA workloads. Early Snoop may decrease memory latency but may also result in lower overall bandwidth as compared to other modes.

1st) Early Snoop (memory latancy-sensitive workloads)
2nd) Cluster on Die Highly NUMA-optimizrd workloads)
3rd) Home Snoop (default) NUMA workloads that need maximum local and remote bandwidth


네할렘 마이크로아키텍처가 샌디브릿지로 대체되며 바뀐 가장 큰 구조적 변화는 바로 링 버스 구조를 도입한 것입니다. 멀티코어 다이 구성시 네할렘까지는 각각의 코어와 L3캐시를 각각 독립된 채널을 통해 일대일로 연결해주어야 했고, 이는 UCA (Uniform Cache Access; UMA의 캐시 수준에의 적용) 구현을 위해 당연한 것이었습니다. 그러나 많아 봐야 4코어까지 탑재하는 데스크탑 영역이나, 네할렘-EX의 최대 코어 구성이었던 8코어까지만 하더라도 그로 인한 오버헤드가 심각한 수준이 아니었지만 코어 갯수가 10개를 넘은 웨스트미어-EX부터는 설계의 복잡성이 커지기 시작했습니다. 이래서는 미래에 코어 갯수를 늘릴 때마다 기하급수적으로 늘어나는 채널의 수를 감당할 수 없겠다고 판단한 인텔은 샌디브릿지 마이크로아키텍처부터 링 버스를 도입합니다.

아이비브릿지 마이크로아키텍처에서 하스웰로 이행하며 우선 각급 다이의 코어 갯수가 일제히 늘었습니다. 그러나 달라진 것은 그뿐만이 아닙니다. 언코어 레벨에서 오히려 더 거대한 변화가 가해졌는데, 바로 링 버스가 '분리된' 두 개로 늘었으며, 각 링 버스 사이에 인터커넥트 스위치가 배치되었고, 물리적으로 분리된 링 버스마다 하나씩의 홈 에이전트와 메모리컨트롤러가 배치되었다는 점입니다. 어떤 의미에서는 '아주 타이트하게 결합된' MCM처럼 보일 정도로까지 내부 구조가 변화한 것입니다.

샌디브릿지에서 링 버스 구조를 도입하며 개별 코어가 각기 개별 L3캐시 슬라이스에 접근하는 레이턴시가 다양해질 수 있다는 점은 대표적인 위험 요소였단 이야기를 앞서 했었습니다. 아이비브릿지에서 코어 갯수가 늘어나며 이 부분의 모순이 더욱 커졌지만 그때까지만 하더라도 이로 인한 성능 손실이 눈에 띄는 정도는 아니었던 것 같습니다. 그러나 링 버스 자체가 한 다이 내에서 두 부분으로 분할되고, 각각을 접속시키기 위해 별도의 '스위치'를 거치게 되며 링의 양쪽(편의상 링 도메인이라 합니다)을 오가는 데 소요되는 레이턴시가 급격히 늘게 됩니다.

메모리컨트롤러가 꺼지는 문제는 인텔이 의도한 부분 같지는 않지만(그렇기에 더 큰 문제일 수 있지만), 사실 그 밖의 '두개의 링 도메인' 구조로부터 파생되는 문제에 관해서는 다행히 인텔이 그에 대처하는 옵션을 제공하고 있습니다하스웰-EP/EX부터 새로 도입된 제3의 캐시 일관성 관리 정책인 클러스터 온 다이 (Cluster on Die, COD) 모드가 그것입니다. , 이 모드는 두 개 이상의 홈 에이전트를 갖는 10코어 이상 모델 (12코어 다이 이상을 사용한 것) 에 한해 적용 가능합니다. 러프하게 보아 링 도메인을 기준으로, 물리적으로 한개의 다이를 논리적으로 두개의 소켓 (NUMA 도메인) 처럼 인식하는 것입니다.

사실 링 버스 구조 자체가 UCA로부터 멀어진 길이란 점은 위에서 언급했었습니다. 링 도메인이 두개로 분리되면서 하나의 하스웰-EP/EX 다이는 노골적으로 NUCA의 색채를 드러내고 있습니다. 심지어 양쪽 링 도메인이 별개의 메모리컨트롤러를 가지게 되면서, 한 소켓 기준으로 하나의 UMA 쿼드채널이라기보다는 두개의 NUMA 듀얼채널에 가까운 모양이 되었고 실제 작동에서도 비슷한 특성을 보였습니다. COD는 여기서 파생되는 문제점을 해결하기보다, 거꾸로 온전한 NUMA 도메인으로 분리하여 거기서 얻을 수 있는 장점을 키우는 쪽으로 노선을 바꿨습니다. 실제로 COD 모드 하에서 대부분의 멀티코어 최적화 어플리케이션 성능은 눈에 띄게 향상됩니다.

앞서 설명했듯 COD 모드는 캐시 일관성 관리정책의 한 가지입니다. 하스웰-EP/EX 다이 내에서 하나의 코어는 이론적으로 45MB L3캐시 모두에 접근할 수 있으나, 만약 필요로 하는 데이터가 다른 링 도메인에 속한 L3캐시에 있다면 이를 액세스하기 위해 큰 레이턴시를 감수해야 합니다. 이런 사례가 빈번하게 일어난다면 전체적인 성능 저하를 피할 수 없습니다. 러프하게 보아 캐시 용량보다 속도가 중요시되는 상황이라면 성능이 떨어집니다. 반면 링 도메인을 기준으로 사실상 별개의 CPU로 간주한다면 코어는 자신과 같은 링 도메인에 속한 L3캐시에만 접근하게 됩니다. 총 용량이 절반이 되므로 캐시 미스는 두배 증가하겠지만 레이턴시 역시 대폭 줄어듭니다. 이것이 COD의 본질입니다. COD의 단점은 COD가 없을 때의 단점을 뒤집어 놓은 것과 같습니다 : 캐시 속도보다 용량이 중요시되는 상황에서 성능이 떨어집니다. 또한 멀티코어에 최적화된 어플리케이션이라도 NUMA 자체에 최적화되지 않았다면 마찬가지로 성능이 떨어집니다.

출처 : http://iyd.kr/738

세 번 정독하고 그나마 이해... /전공자에 대한 /존경



posted by cookis
2014.11.11 10:36 softwares/quick reference
1. 부트 드라이브로 SSD를 쓴다.


너무나도 당연...

2. Windows 8.x 로 업그레이드 한다.

Windows 8 부터는 OS의 초기화 과정을 없애고, 최대 절전 모드를 기본으로 사용함으로 같은 하드웨어 장비를 쓰더라도 Windows 8.x 시스템이 더 빠른 부팅 속도를 경험할 수 있습니다. (MSFT 에서 테스트한 결과로는 30~70%까지 부팅 속도 향상)

Old Shutdown Steps - 기존 부팅 스텝

  1. 셧다운 (종료) 클릭
  2. Windows 가 실행중인 프로그램들에게 브로드캐스트 종료 혹은 저장되지 않은 데이터를 저장하라고 메시지창을 띄움
  3. 로그인된 유저 세션을 닫음 (로그 오프)
  4. Windows 가 각 시스템 서비스에게 셧다운 메시지를 알리고 프로세스를 종료 함. (반응이 없을 시 강제 종료)
  5. Windows 가 각 디바이스 드라이버에게 종료 명령
  6. Windows 가 시스템 세션을 종료 함
  7. Windows 가 쓰기가 지연된(pending)된 데이터를 디스크에 저장(flush)
  8. Windows 가 ACPI 인터페이스를 통해 시스템에 파워를 끊도록 명령

New Hybrid Shutdown - Windows 8 의 빠른 부팅 스텝

  1. 셧다운 (종료) 클릭
  2. Windows 가 실행중인 프로그램들에게 브로드캐스트 종료 혹은 저장되지 않은 데이터를 저장하라고 메시지창을 띄움
  3. 로그인된 유저 세션을 닫음 (로그 오프)
  4. 최대 절전 모드로 메모리에 있는 커널모드를 디스크로 저장 (하이버네이트)

Windows 8.x 의 기본 UI에 포함된 "시스템 종료" 를 하면, 기본적으로 최대절전모드를 이용한 부팅을 하게 되고, 그림에서 보다시피 Shutdown 후 변경된 하드웨어의 검색을 위해서 Hiberfile Read 후에 'Driver Init' 과정만 따로  떼어내져 있습니다. 사용자 세션 (로그온 세션)만 정상적으로 로그오프 처리하고, Windows 커널은 최대절전모드로 저장하고 불러옴으로서 부팅 속도를 더욱 더 빠르게 할 수 있습니다.

다만, shutdown /s /t 0 (시간) 의 명령어로 시스템을 종료 하거나 재시작 시에는 (역시나, 드라이버 재설치의 이슈 등등) 이와 같은 빠른 부팅을 사용하지 않기 때문에 이 경우 부팅 속도의 감소는 없습니다. (기본 설정은 제어판 -> 전원 옵션 -> 전원 단추 작동 설정에서 빠른 부팅(Fastboot) 끄고 켤 수 있습니다.) 이와 같은 이유로 빠른 부팅이 활성화 되어있는 경우는 WOL(Wakeup On Lan)이 작동하지 않습니다.


3. OS를 UEFI 로 설치 / UEFI BIOS를 사용 한다.

일반적으로 UEFI 가 Legacy BIOS에 비해 조금 더 빠른 부팅 속도를 제공 합니다. (OS의 부트 모드 확인은 아래의 그림처럼 Windows에서 msinfo32 를 실행 하면 Windows 가 설치된 모드를 확인할 수 있습니다. Legacy BIOS 혹은 UEFI) UEFI로 OS 설치를 설치하는 방법은 부트 시퀀스에서 USB / DVD-ROM 이 아닌 <UEFI> 메뉴가 활성화 된 부트 디바이스로 OS 설치 할 수 있습니다. (USB 드라이브로 설치 시 DISK의 파일 시스템은 꼭 FAT32 이어야 합니다)

부팅 방식을 UEFI 로 바꿈으로서 얻을 수 있는 추가적인 장점으로 SecureBoot, GPT Disk (2TB 이상 디스크를 부트 드라이브로 사용) 부트 등등.. 그다지 와닿는 기능들은 아니지만, BIOS 에서 Legacy DISK의 MBR을 검색하고 부트 드라이로 인식 하는 것이 아닌, Windows Boot Manager를 통해 OS를 부팅할 수 있습니다. 체감이 불가능한 수준이긴 하지만, Boot Sequence (우선 순위)에서 CD-ROM / HDD 등이 아닌 이 Windows Boot Manager를 첫번째로 올림으로서 부팅 시 체크 과정을 줄일 수 있습니다.


하지만, 일부 구형 시스템들은 이와 같은 UEFI 바이오스를 제공하지 않는 경우가 있을 수 있습니다. 그리고 기존 BIOS 에서 UEFI 로 OS 재설치 없이 변경하는 방법이 아예 없지는 않지만, 과정이 복잡하고 어렵기 때문에 추천하는 사례는 아닙니다. (UEFI 에서는 MBR DISK 대신 GPT 디스크를 쓰기 때문에 재설치 시 포맷 혹은 수동 변환 시 디스크 타입의 컨버트의 과정을 필요)


4. 메인보드의 Fast Boot / Instant Boot을 설정.

메인보드에서 제공하는 빠른 부팅 옵션(Fast Boot / Post Delay)을 설정 하면 바이오스 포스트 시의 키 입력 등 불 필요한 과정을 생략할 수 있습니다. (USB 디바이스를 통한 부팅이나, Windows OS 부팅 전에 입력할 수 있는 옵션들을 제공하지 않음) 그렇기 때문에 F1 혹은 DEL 키를 누르면 바이오스로 들어가는 일반적인 바이오스 셋업 화면을 제공하지 않습니다.

이로인해 일반적인 과정을 통해 바이오스 셋업에 들어갈 수 없는 경우는 Shift 키를 누른 상태로 재시작을 누르거나, 윈도우 고급 옵션의 'UEFI 펌웨어 설정' 메뉴를 통해 바이오스 셋업 화면으로 진입 할 수 있습니다. 만일 Fast Boot 이 설정 된 상태에서, Windows 진입이 불가능하여 UEFI 셋업으로 들어갈 수 없다면, RTC 리셋이나 Direct Key 등의 (일부 모델) 특정 기능을 사용하여 UEFI (바이오스) 셋업으로 들어갈 수 있습니다.

이 때 일부 기능 (Ultra) Fast Boot을 사용하기 위해서는 UEFI + Windows 8.x 를 사용하고, 외장형 VGA 를 필요로 할 수 있습니다. 추가적으로 일부 메인보드 기종에서 제공하는 Instant Boot 의 경우 시스템 종료 시, 메모리에 전원이 유지 되는 S3 또는 일반적으로 최대 절전모드라고 불리우는 S4 등의 상태에서 복귀하는 부팅 과정을 제공하는 메인보드도 있습니다.


CSM
Enable to launch the Compatibility Support Module. Please do not disable unless
you’re running a WHCK test. If you are using Windows 8.1/8 64-bit and all of your
devices support UEFI, you may also disable CSM for faster boot speed.

Fast Boot
Fast Boot minimizes your computer's boot time. In fast mode you may not boot
from an USB storage device. Ultra Fast mode is only supported by Windows 8.1/8
and the VBIOS must support UEFI GOP if you are using an external graphics card.
Please notice that Ultra Fast mode will boot so fast that the only way to enter this
UEFI Setup Utility is to Clear CMOS or run the Restart to UEFI utility in Windows.


references

http://blogs.msdn.com/b/olivnie/archive/2012/12/14/windows-8-fast-boot.aspx
https://gitorious.org/tianocore_uefi_duet_builds/pages/Windows_x64_BIOS_to_UEFI
http://www.kbench.com/?q=node/112024


--

전원 버튼 누르고 화면까지 정확히 몇 초 걸렸다.자료 (이건 링크의 케이벤치 자료 보시면 됩니다) 보다 최소 이 정도의 조건만 맞추어 주면 일반적인 구성보다 훨씬 빠르게 부팅 할 수 있다. 라는 정도의 가이드로만 보시면 될 것 같습니다. Windows 업데이트의 경우도 있을 수 있고, 각 시스템의 구성이 다 다르기 때문에 항상 몇 초 안에 부팅을 끊을 수 있다. 라고 보증을 할 수는 없기 때문입니다.

posted by cookis
2014.11.07 00:50 softwares/quick reference

c:\windows\installer 폴더 삭제하기

Windows Update가 실패하거나 취소 했을 떄 임시로 남아있는 폴더인데, OS 디스크를 옮기려고 보니 8GB 나 먹고 있음.
깔끔하게 삭제를 하기 위해서는 MSIZAP.EXE 를 필요로 하는데, Windows SDK Components 로만 제공.

8GB 폴더 삭제하려고 4.5GB 짜리 SDK 를 설치할 수는 없잖아... -_-;;
WIndows Resource kit 처럼 exe 파일만 다운로드 받아서 실행(MSIZAP.EXE !G)하면 지워 집니다.

PS C:\Users\Administrator\Downloads> .\MsiZap.exe !G
MsiZapInfo: Performing operations for user S-1-5-21-4138456422-3840560582-1411138238-500
Removing orphaned cached files.
   Error opening 84A8A6CE1D6736745B52C320722EF854\InstallProperties subkey of Products key for S-1-5-18 user. Error: 2
.
FAILED to clear all data.


PS C:\Users\Administrator\Downloads> .\MsiZap.exe !G
MsiZapInfo: Performing operations for user S-1-5-21-4138456422-3840560582-1411138238-500
Removing orphaned cached files.
   Removed file: C:\Windows\Installer\10cde7.msi
   Removed file: C:\Windows\Installer\231a481e.msi
   Removed file: C:\Windows\Installer\24ad7a5.msi
   Removed file: C:\Windows\Installer\24ad7ab.msi
   Removed file: C:\Windows\Installer\277f64.msi
   Removed file: C:\Windows\Installer\2873d9.msi

Error 2 가 발생하면 HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\의 S-1-5-18 의 SID를 삭제

http://nerdoftherings.net/wp/?p=66
http://wyang0.blogspot.kr/2010/06/clean-up-cwindowsinstaller.html

MsiZap.exe


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
2014.04.26 15:32 softwares/quick reference

인텔 Haswell 프로세서에 대응하는 H(Z)87 칩셋부터 코드네임 ClarkVille (i217-V)의 NIC가 추가 되었습니다. 처음에는 인텔 NIC라고 좋아 했었으나, Windows Server 2012 R2를 설치하면서 NIC 드라이버가 설치가 되지 않는 문제가 확인 되어 해결책을 찾아보기 시작했습니다. ClarkVille의 경우 같은 칩셋으로 Windows Server 계열의 OS를 지원하기 위해서는 i217-LM 이라는 다른 이름으로 드라이버를 제공하고 있으나, 이는 서버 계열을 지원하는 칩셋에서의 이야기고, i217-V의 경우 기본적으로 Windows 7 / 8 / 8.1 의 클라이언트 계열의 OS만 지원합니다.

공식적으로는 i217-V 는 Windows Server 계열의 OS를 지원하지 않으며, i217-V/LM의 드라이버 수정을 통해 Windows Server 2012에 설치가 가능합니다만, 인텔의 인증서로 서명된 드라이버(INF)를 수정해서 사용하기 때문에 Windows Server의 시작옵션 변경을 통해 공식적으로는 지원하지 않는 방법으로 설치 해야합니다.

관리자로 커맨드라인 실행, 아래의 명령어 입력 및 재부팅 후 드라이버의 서명이 되지 않아도 설치가 되도록 설정을 바꾼 뒤

bcdedit -set loadoptions DISABLE_INTEGRITY_CHECKS
bcdedit -set TESTSIGNING ON

첨부파일의 NIDS64 의 INF 를 선택해 주면 설치가 가능합니다. 드라이버 설치 후에는 ENABLE_INTERGRITY_CHECK,  TESTSIGNING OFF 로 원래대로 바꿔주시고요. 참조 된 블로그에서는 구 버전의 드라이버 뿐이라 19.0 기반의 드라이버로 다시 수정 해 두었습니다. 일반적인 컴퓨팅에는 문제가 없을것으로 보입니다만,

확실하진 않지만 i217-V 에서 랜카드의 특정 기능(Feature)를 지원하지 않는 것으로 추측 되는데 Internet Connection Sharing을 통해 네트워크를 공유할 때 연결이 끊어지거나(Disconnect와 Connect를 반복) 끊어진 후 다시 연결되지 않는 현상이 발생 했습니다. (i217-V 를 공식적으로 지원하는 Windows 8.1에서도 똑같이 확인 함) 결국은 다른 NIC와 역할을 바꾸어 문제를 해결하긴 했습니다만 (i217-V 와 EEPRO1000/GT 의 역할을 바꾸어 해결) 드라이버를 인식하더라도 뭔가 개운치 않은 것은 사실입니다.

19.0_NDIS64.zip

references
http://nearlydeaf.com/?p=1145
http://hardforum.com/showthread.php?t=1772066

posted by cookis
2014.04.23 00:26 softwares/quick reference

Windows Server 2012 (/R2) Standard Edition 에서 Datacenter Edition 으로 업그레이드 하는 방법은
DISM /online /set-edition:ServerDatacenter /productkey:ABCDE-EFGHI-JKLMN-OPQRS-TUVWX /AcceptEula
위의 명령어는 Microsoft 에서 공식적으로 지원하는 업그레이드 방법 입니다.

반대의, Edition 다운그레이드의 경우는 Microsoft 에서 공식적으로는 지원하지 않고 있으며,
하위 Edition의 버전으로 변경하기 위해서는 반드시 재 설치를 하는 것을 권고 하고 있습니다.

비공식적으로는 서버 버전의 레지스트리 키를 변경하여 Datacenter 에서 Standard로 변경
(이 것만으로는 Standard Edition으로 변경 되지 않습니다.  이것은 설치 프로그램 Standard Edition으로 인식하기 위해서 입니다) 후,
동일 버전의 Windows Server DVD 삽입 후, in-place 업그레이드를 진행하시면 Standard to Standard Edition으로
업그레이드를 진행하며, 마이그레이션을 통해 Edition만 다운그레이드 된 Windows Server를 만나보실 수 있습니다.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
Key: EditionID
Change To: ServerStandard
Key: ProductName
Change To: Windows Server 2012 Standard


http://social.technet.microsoft.com/Forums/en-US/0b0af758-44c7-48ee-be94-d6aa6828e739/installed-datacenter-want-to-downgrade-to-standard?forum=winserver8gen

posted by cookis
2012.09.04 01:59 softwares/quick reference

Windows Server 2012 RTM이 발표되고, 요 며칠 사이 테스트 해보는 중. 감동의 쓰나미가 밀려오기도 하다가, 의외로 허당 같기도 해서 롤러코스터를 타는 중. Windows Server 2012 같은 경우는 회사(프로젝트에 직접 참여한 건 아니지만)에서 Windows Server 2012 RDP (Rapid Deploy Program) 프로그램에 참여하게 돼서 교육도 받고, 최근 관심 있게 지켜보고 있는 항목. 내용은 Microsoft Evangelist이신 꼬알라(백승주)님의 블로그 내용을 참조 하였음.

EMC나 NetApp 등 최근 스토리지 장비의 화두는 유니파이드 스토리지(Unified Storage), Thin Provisioning, 데이터 중복 제거 기술(Data Deduplication) 이 세 가지가 세일즈 포인트인 느낌을 받는데, 그 중 데이터 중복 제거 기술이 Windows Server 2012의 기본 기능으로 들어가게 됐습니다. 이 디듑의 원리는 디스크에 저장된 데이터를 아주 작은 (32K~128KB) 하나의 단위(Chunk)로 조각 내고, 디스크 내에 동일한 조각이 있다고 판단 되면 중복된 조각을 지우고 하나의 조각으로 파일 시스템 내부에서 링크를 걸어 디스크의 공간을 절약하는 것. 사실 디스크 내에서는 데이터 조각이 파편화 되기 때문에 성능과는 거리가 있고 이 작업들이 실시간으로 이루어지지 않고, 스케쥴러를 통한 백그라운드 작업으로만 이루어지기 때문에 유연하지도 않은 것 같습니다. 보통 스토리지 벤더에서는 이러한 데이터 디듑 기능이 5~10%의 성능 저하를 일으킬 수 있다고 밝히고 있습니다.

이러한 중복 제거라는 기술을 처음 접하게 된 건, 오래전 Windows 2000 시절 Professional, Server, Advanced Server 이 세 개의 버전이 모두 한 장의 시디로 포함된 WoW(Windows on Windows나 World of Warcraft 아닙니다 -_-...) 버전을 본게 처음이었는데, 세 가지의 버전을 하드디스크로 복사하면 약 1.5GB를 넘는 용량이었지만 ISO나 실제 CD 내부에서는 650MB 안에 저장이 가능했었습니다. 이는 Windows 2000 설치 파일 중 세가지 버전에서 모두 공유해서 쓸 수 있는 Driver.cab 등의 중복 파일들을 CDFS 의 인덱스에서 링크(혹은 포인터)를 걸게 됨으로서 실제 CD에 저장되는 용량을 줄여 650MB 안으로 기록하는 기술 이었습니다. 물론 엄밀히 따지면 이렇게 CDImage.exe 나 OSCDIMG.exe 를 이용하는 방법이 File Chunk를 이용한 데이터 중복 제거와는 100% 다른 기능이긴 하지만, 대략의 원리는 비슷하다고 볼 수 있을 것 같습니다. (cdimage나 oscdimg에서는 -o 옵션을 주고 이미지를 만들게 되면 MD5 Hashing을 이용해 동일한 파일을 구분하여, Deduplication을 시행합니다)

Windows Server 2012의 서버 관리자의 역할 및 추가 기능 마법사로 "파일 서버 및 iSCSI 서비스" - "데이터 중복 제거" 기능을 설치할 수 있고, 설치 후에는 서버 관리자의 "파일 및 저장소 서비스" 항목에서 확인할 수 있습니다. 논리 드라이브(볼륨) 단위로 디듑 기능을 활성화 할 수 있습니다. 간단한 작동 포인트는, OS가 설치된 파티션 디스크 (C:\)는 디듑이 활성화 되지 않음. Clustered Shared Volume(CSV) 도 적용되지 않음주 1회, 일 1회의 중복 제거를 위한 스케쥴러가 설정 됨. MS에서도 타 스토리지 벤더와 마찬가지로 데이터 디듑에 의한 성능 저하는 5% 내외라고 주장하고 있습니다. 주 1회(토요일 새벽로 잡혀있는 GarbageCollection, Scrubbing 작업의 경우는 파워쉘(PS)에서 StartDedup-Job D: -Type Scrubbing (Job Name) 이라고 하면 바로 시작 된다고 하던데 Queue에만 걸리고 실제론 잘 안 됐습니다. (날짜 바꾸기도 귀찮고, 일주일 기다렸음... 헐...)

PS C:\Users\Administrator> get-dedupmetadata d:

 

 

Volume                         : D:

VolumeId                       : \\?\Volume{11e9d941-d2c6-464f-bd5f-d1e93f487b2e}\

StoreId                        : {1B76B5FD-920E-4253-A58F-01D957FE5667}

DataChunkCount                 : 422567

DataContainerCount             : 30

DataChunkAverageSize           : 73.62 KB

DataChunkMedianSize            : 0 B

DataStoreUncompactedFreespace  : 0 B

StreamMapChunkCount            : 257

StreamMapContainerCount        : 2

StreamMapAverageDataChunkCount :

StreamMapMedianDataChunkCount  :

StreamMapMaxDataChunkCount     :

HotspotChunkCount              : 69

HotspotContainerCount          : 1

HotspotMedianReferenceCount    :

CorruptionLogEntryCount        : 0

TotalChunkStoreSize            : 29.86 GB

 

 

PS C:\Users\Administrator> get-dedupstatus

 

FreeSpace    SavedSpace   OptimizedFiles     InPolicyFiles      Volume

---------    ----------   --------------     -------------      ------

222.44 GB    149.84 GB    150                150                D: 























실제 저장된 디스크의 내용은 데이터 디듑의 성능을 확인해보기 위해 같은 내용의 파일을 다른 이름으로 저장했고, 이는 데이터 디듑의 기능이 극대화 된 (78% 제거) 특수한 경우이며 일반적인 경우는 아니라고 생각 됩니다. D:\DD\ 폴더에는 약 192GB 가량의 파일이 저장되어있지만, 실제로 디스크에는 33GB의 공간만 점유하고 있으며, 디듑으로 세이브 된 공간은 약 150GB 가량으로 표시 됩니다.

데이터 디듑 기능 보다가 번뜩 떠오른 우스개 이야기로 살색 많이 나오는 야구 동영상들을 한 곳에 모아두면 중복 제거 비율이 더 높아질까? 아니면 같은 주인공인 영상이면 중복 제거가 더 잘 될까? 물론 이론적으로는 턱도 없는 소리(영상 압축)인 거 알지만, 흥미로운 주제여서 증명을 한번 해보고 싶었는데, 요즘 분위기로는 괜히 인증했다가 잡혀갈 거 같아서 패스 (개인적으로는 아동/동물/스너프 이런 거 혐오합니다. 노홍철보다 유재석을 더 선호합니다 (...) 

Windows 8 에도 데이터 디듑 기능을 넣어줬다면 좋겠지만 이 디듑 기능은 백 그라운드 작업을 기본으로 하기 때문에, OS 특성에도 안 맞아서 큰 효과를 낼 수 있을 지가 의문이긴 합니다. 스토리지 박스, Windows Server 2012 외에 이런 데이터 디듑을 사용할 수 있는 솔루션으로는 ZFS 파일시스템을 이용한 NexentaStor 등으로도 구현이 가능한 것으로 알고 있지만, 일반 용도의 레벨에서는 구현하기가 까다롭다는 단점이 있습니다. 간단한 Windows 시스템에서 파일 (스토리지) 서버를 구현해야 한다면 Windows Server 2012가 좋은 대안이 될 듯 합니다.

다만 한 가지 우려 되는 것은 Chunk 단위로 구분이 되기 때문에, 싱글 디스크 환경에서는 특정 섹터에 물리적으로 배드 섹터가 생기게 되면, 중복된 조각을 갖고 있는 다른(여러) 파일에 영향을 미칠 수 있을 것 같습니다. 그래서 대부분은 리던던트를 가진 RAID를 사용 하거나(서버에서는 기본적으로 사용하고 있다고 가정하거나) 사용하도록 권장을 하는 것 같습니다. 벤더에서 말하는 5~10% 의 성능 저하는 디듑이 적용 된 볼륨에서의 읽기/쓰기를 말하는 것 같고 (실제로는 성능 저하를 느끼지 못했습니다) 저장된 데이터를 조각내어 재배열하는 작업(백그라운드 스케쥴러)에는 별도의 디스크 I/O와 시간을 필요로 합니다. 하드웨어 벤더 쪽에서는 이 디듑 I/O가 발생하는 시간과 일반 I/O가 겹쳐 질 때, 디듑의 디스크 I/O를 감소시키거나 건너 띌 수 있게 관리 할 수 있다고 하는데, Windows Server 2012에선 그러한 고급 컨트롤이 되는지는 모르겠습니다. 

시스템 관리자 입장에서는 디스크 공간을 최대한 활용할 수 있는 매력적인 기능이며, 2차 백업 서버 등의 실무에는 고민 없이 곧바로 적용할 수 있는 아이템입니다. 낭비 되는 디스크의 공간을 절약하기 위한 역사를 살펴보면 MS-DOS 시절의 스태커나 더블 스페이스, NTFS의 폴더 내용 압축 등 이름만 다른 한 가지의 기술들이 사용 되어왔는데요. 데이터 디듑 기능은 이러한 압축 기반이 아닌 순수 파일 시스템 기반의 기술 입니다.

--

이런 중복 제거 기술을 극대화 해서 활용할 수 있는 곳은 VHD/VMDK 라이브러리 or DB 백업 서버 등등... 근데 괜히 잘 돌아가는 거, 신기술 적용/활용도 높여보겠다고 건드렸다가 장애 내고 긁어 부스럼 만들거 같아서 항상 딜레마임. 안 그래도 시키는 일 많은데, 안 시킨 일까지 찾아하려면 귀찮기도 하고...

posted by cookis
2012.07.17 16:35 softwares/quick reference

1. update vmware esxi 5

ESXi 서버는 4.0/5.0 메이저 버전과 뒤에 붙은Update 1/2등의 서비스팩 수준의 패치, 그리고 매월 제공되는 패치로 나뉘어집니다. 보안 패치나 기능 개선 패치를 위해 매월 Build 번호를 구분하여 VMWare 사이트에 업로드(ZIP파일) 되며, 패치들을 묶어 Update1 이나 Update2 등의 설치 패키지로 제공(ISO파일) 됩니다.

VMWare 사이트에서 VMWare vSphere Hypervisor – Downlaod ESXi Patches 항목에서 패치를 다운로드 받을 있습니다. 패치 파일은 ESXi500-201206001.zip 형태의 ZIP파일로 제공 되며, 다운로드 받은 파일은 ESXi 서버의 로컬 디스크(VMFS) 업로드 합니다. 


업데이트는 ESXCLI 사용하며, vSphere Remote CLI 설치되어있어야 합니다. 명령어는 아래의 형식으로 실행 합니다. 업데이트 완료 후에 ESXi 서버의 리부팅을 진행하면 변경(패치) ESXi 서버의 빌드 번호 확인할 있습니다.

C:\ esxcli –s 192.168.100.1 –u root –p password  software vib install -d /vmfs/volumes/datastore1/ESXi500-201206001.zip

업데이트 다음과 같은 오류가 발생 한다면 datastore 이름과 경로, 파일이름이 정확히 입력 되었는지 확인 합니다. 이 과정에서 에러가 나는 대부분의 이유는 vCenter로 서버가 등록 되면서 datastore의 이름이 "datastore (n)" 으로 변경되어 공백이 포함되거나, 파일이름을 잘못 입력한 경우 발생합니다. 공백이 있는 경우는 datastore의 이름을 변경합니다.


근데.. Diskless 시스템에서는 어떻게 패치하지?
ESXi 4.1->5.0 으로 CD를 넣고 Migrate 했더니, VMFS 는 그대로 3.4에서 VMFS 5로 안 올라감. 그냥 백업하고 새로 깔음 -_-


2. adding 10Gbps NIC

가상 시스템을 생성하면 기본적으로(Default 설정) 어댑터 유형을 E1000으로 생성하게 됩니다. 이는 Intel Ethernet Express Pro 시리즈의 NIC 에뮬레이션 하는 것으로, 대부분의 OS(Windows, Linux)에서 기본 드라이버를 탑재하고 있습니다.

이상의 NIC 사용하거나, VLAN이나 별도로 구성된(DMZ 등등) 네트워크 자원을 사용하고자 때는, 가상 시스템의 설정 편집에 네트워크 어댑터 네트워크 연결 네트워크 레이블에서 앞서 호스트의 네트워크 구성에서 설정한 네트워크의 레이블을 선택하고, 가상 NIC IP/SUBNET MASK/GATEWAY/DNS 등의 정보를 입력하면 됩니다.주의할 점은 E1000 아답터는 대역폭이 1Gbps 까지만 지원 가능합니다. 1Gbps 이상의 네트워크 10Gbps ESXi 호스트에서 Active/Active(Ether Channel Bonding)으로 대역폭이 1Gbps 이상일 경우에는 VMXNET3 타입의 아답터로 추가하면 가상 시스템 내에서는 10Gbps 추가 됩니다. 만일 같은 ESXi 호스트 내의 가상 시스템끼리 통신하는 경우는 VMXNET3 추가 했을 경우 10Gbps 인식하지만, 실제 통신 대역폭은 호스트의 물리적 네트워크 대역폭을 따라가게 됩니다.


내부 버스에서만 이루어지는 통신인데, 1Gbps 리밋이 걸리는 건 뭐데? -_-


3. change firewall rulset via esx ssh shell

vSphere Client 통해 ESXi 방화벽 설정을 잘못해서 접속이 되는 경우, SSH 접속을 통해 설정 값을 변경 있습니다.

#정책 보기
esxcli network firewall ruleset allowedip list
#정책 삭제
esxcli network firewall ruleset allowedip remove --ip-address=172.xx.xx.xxx --ruleset-id=vSphereClient
#정책 추가
esxcli network firewall ruleset allowedip add --ip-address=10.xx.xx.xx.0/24 --ruleset-id=vSphereClient 

ESXCLI 관련된 KB 문서는 에서 확인할 있습니다.


IP를 넣을까 말까.. 한 세번쯤 고민하다가 넣었는데 넣자 마자 짤리는... 아...
vSphere 에서는 접속 Client의 Client IP를 찍어주는 메뉴가 없어서, 확실치 않으면 ssh 들어가서 netstat 이라도 해봐야할 듯?

posted by cookis
TAG esxi, VMware
2012.04.04 14:13 softwares/quick reference

VMWare ESX/ESXi 에 SNMP를 설정하려면 vSphere Remote CLI가 깔려있어야 함. 사용하는 ESXi 버전에 따라 다르고, 설치 후 CLI 명령어 실행할 때 libxml2.dll (perl.exe) 문제가 발생하면 내 컴퓨터 - 등록정보 - 고급 - 환경 변수 - 사용자(혹은 시스템) 변수 에서 Path 에 ;C:\Program Files (x86)\VMware\VMware vSphere CLI\bin 경로를 넣어주고 재시작 하면 됨.

근데, ESXi 5.0 호스트는 잘 긁어오는데 4.0 은 NIC만 긁어오네? -_-

C:\Program Files (x86)\VMware\VMware vSphere CLI\bin>vicfg-snmp.pl --server 192.168.0.100 --username root --password (password) -c (communityname) --enable
Changing community list to: public...
Complete.
Changing notification filter to: --enable...
Complete.

-n 은 disable snmp trap (no trap)

더보기

references

vSphere Remote CLI for 4.x – http://www.vmware.com/download/download.do?downloadGroup=VCLI41
vSphere Remote CLI for 5.0 – http://www.vmware.com/download/download.do?downloadGroup=VCLI50
Configuring SNMP Traps for ESXi/ESX 3.5, 4.x, and 5.0


posted by cookis
2012.03.29 18:02 softwares/quick reference

Q) 루트 인증서 업데이트 KB931125 의 자동 업데이트가 정상적으로 되지 않고, 설치 과정에서 무한 루프가 돈다.

A) 내부 WSUS(Windows Server Update Services) 를 사용할 때 같은 KB(931125)로 여러 버전의 업데이트를 내려주게 되면, 오래된 버전의 업데이트를 설치하지 못 한다. WSUS에 올라온 업데이트는 귀찮으니까 대충 승인 했었는데, 이젠 그냥 해주면 안 되겠더라. WSUS 콘솔에서 최근 날짜의 버전은 설치 승인, 이전 버전의 업데이트는 설치 거부 로 해결 가능.

수동으로 루트 인증서 삭제 후, 최신 rootsupd.exe 를 받아서 설치. 혹은 클라이언트에서 설치를 거부 하는 방법도 있지만..
대부분은 필요 없을 듯 -_-

1. Add the Certificates snap-in to the Microsoft Management Console.
a. Click the Start button, click Run, type mmc, and click OK.
b. Click the File menu, and select Add\Remove Snap-in.
c. Click the Add button, then select the Certificates snap-in and click Add
d. Select Computer Account and click Next
e. Click Finish.
f. Click Close.
g. Click OK.
2. Expand Certificates (Local Computer).
3. Expand Trusted Root Certification Authorities.
4. Click on Certificates.
5. Backup and then delete trusted root certificates that you are not using in your environment.

references

Root Certificate update KB931125 keeps installing.... again & again & again
Warning: Problems With Root Certificates Update, KB931125

posted by cookis
2012.03.16 12:11 softwares/quick reference

thin provisioning을 사용해 디스크를 생성하면 가상 머신에서 실제로 사용하는 만큼만 스토리지(datastore)에서 사용하는데, 이 디스크의 용량은 한번 늘어나게 되면, 실제 데이터를 지우더라도 스토리지에서의 크기가 줄어들진 않는다. osx의 vmware fusion 같은 경우는 clean up disk 같은 기능을 제공하는데, 이 과정을 reclaming disk 라고도 한다. (셧다운 상태에서 가능) 하지만 esx, esxi 에서는 이런 기능을 지원하지 않는다. 즉, 한 번 늘어난 디스크의 크기는 쉽게 반환 하지 않는다.


이 실제 디스크의 여유 공간을 확보하려면 두 가지의 방법이 있는데, 하나는 시스템을 셧다운 시키고 OVF 템플릿 내보내기/배포의 과정으로 export/import의 과정을 거치는 것이고, 나머지 하나는 블럭 사이즈가 다른 저장소로 가상 머신을 이동하는 것이다. 전자의 경우는 가상 머신의 셧다운과 많은 시간을 필요로 하고, 두번째 방법은 vMotion 기능을 포함한 vCenter 및 다양한 환경(별도의 VMFS 스토리지 혹은 SAN/iSCSI 네트워크 스토리지)을 필요로 한다.

로컬 datastore (block size 1MB) -> iSCSI iscsistore (block size 2MB) 로 이동 후 여유 공간 확보 (약 100G 가량). 이를 다시 iscsistore에서 datastore로 이동하면 원래대로 돌아올 수 있는데, VMFS3 (ESX4) 에서는 아래의 그림과 같이 작은 사이즈의 블럭으로는 이동이 안 된다 (VMFS5/ESX5 에서는 블럭 사이즈와 상관없이 가능)

그래서 해결한 방법은, 다른 블럭 사이즈의 VMFS3로 생성된 네트워크 스토리지로 vMotion(스토리지,호스트 마이그레이션) 후, 호스트와 datastore를 ESX5/VMFS5 로 재설치 (or 하드 추가). 그 뒤에 역순으로 vMotion(호스트,스토리지 마이그레이션)으로 해서 원래의 로컬 datastore로 이동. 그러니까, 하드웨어 조건만 맞으면 ESX4 에서 ESX5로 vMotion 이 된다는 이야기.

thin prov 디스크 공간 확보하려고 이런 작업들을 하기에는 굉장히 비효율적인 크기의 작업 같은데, 방법이 없는 것 같다. 구글링 해보면 sysinternals의 sdelete로 여유 공간을 채우고 옮기라는 의견도 있었는데, 실제로는 sdelete 작업을 안 해도 가능했음.


posted by cookis
2011.12.13 13:24 softwares/quick reference

Juniper SSL VPN과 외부 인증서버(RSA/PinSafe)를 결합해 쓰게되면, SSL VPN 과 인증서버 두 가지의 라이센스를 사용자 수만큼 구매해야 합니다. 인증서버의 라이센스 개수를 줄이기 위해 동일 토큰을 공유해서 쓰거나 소프트웨어 토큰을 복제해서 쓰는 방법이 있었는데, 실제로는 인증 계정을 공유해서 쓰더라도 동시 접속이 안 되었기 때문에 이 꼼수를 실무에 적용해서 쓰기에는 무리가 있었습니다. 하지만 Juniper IVE 7.0 업데이트 부터 계정(Role)의 동시 접속을 가능하게 지원되어, 이전 보다는 더 유연하게 적용이 가능할 듯 합니다. 이러한 동시 접속 에서는 접속 정책(Policy)를 분리할 수 없습니다. 같은 정책의 계정만 적용이 가능합니다.

Signing In – Signing Policies – Enable multiple user sessions
Select this check box and enter the maximum number of sessions per user per realm in Users > User Realms > [Realm Name] > Authentication Policy > Limits page. By default, this is 1, or one session per user per realm. If you do not select this check box, you limit the user to one session for all realms of this user.

AD/RSA/PinSafe(Realm Name) – Authentication Policy – Limits

Define the limit per user per realm. You must select "Enable multiple user sessions" in the Signing In -> Sign-in Policies page to enable this limit. Otherwise, only one session is allowed per user for all realms regardless of the value entered here.

Network Connections – Network Profile -> Static IP -> DHCP 로 변경
고정 ip로 설정 되어있을 때는, 동시 접속 시 클라이언트 IP 충돌이 날 수 있기 때문에.

posted by cookis
2011.11.24 18:21 softwares/quick reference
디지털 카메라로 찍는 JPG 파일에는 EXIF(EXchangeable Information File)라는 이름의 데이터로 카메라 정보(렌즈)/촬영정보(날짜,조리개,셔터) 등이 자동으로 입력되는데, 이 데이터에 추가로 사진을 찍은 개인 정보를 입력할 수 있습니다. 이 정보를 입력하는 가장 큰 이유는 일반적으로 웹상에서 돌아다니는 사진에서 본인의 사진임을 표기하는 워터마크의 개념으로 주로 입력합니다. (물론, 이 정보는 수정하여 변조 될 수도있고, 웹의 업로드 툴등을 통해 리사이즈되면서 EXIF 데이터가 사라지는 경우도 있습니다) 캐논 EOS DSLR 의 예를 들면, EXIF Artist 정보가 카메라에 입력(설정)된 소유자(Owner)의 이름으로 대치가 되는데, 경험상으로는 이 과정이 투명(?)하지가 않아서 제대로 안 들어가거나, 변경/컨버팅 과정에서 유실되는 경우가 발생합니다.

EXIF와는 별도로, 기본적인 촬영 정보 외에 추가로 메타 정보를 담을 수 있는 IPTC(International Press Telecommunications Council) 혹은 XMP(Adobe)가 있는데, 라이트룸에서는 EXIF 데이터를 직접 수정하지 못하고 이 IPTC 정보만을 취급할 수 있습니다. IPTC 에선 EXIF 데이터와의 호환을 위해 EXIF 의 각각의 데이터 항목에 대해 IPTC 데이터를 매칭 해두었습니다. 항목에 대한 자세한 정보는 여기서 확인 하실 수 있습니다. 결과적으로는 EXIF 데이터를 추가할 수 있으나, 이 데이터는 IPTC를 통해서만 가능하다. 입니다. XMP는 별도의 파일로 사이드카 파일로 되며 리터칭 등의 변형 정보를 담고 있으니, EXIF 나 IPTC와는 조금 다른 형태의 메타 파일입니다.

라이브러리 탭에서 메타데이터 메뉴 드랍다운, '메타데이터 사전 설정 편집...' 에서 IPTC 작업자 별 사전 설정(Preset)을 생성할 수 있습니다. 수정된 메타데이터의 설정은 라이브러리의 '메타데이터' 항목에서 적용이 가능하며, 이 사전 설정 "없음"에서 생성된 사전 설정으로 기본 적용은 안 되는 것 같습니다. 한 개 혹은 여러개의 사진을 선택 후에 사전 설정된 메타데이터를 아래와 같이 적용하여야 합니다. 그 후에 내보내기(Export)를 하면 최종적으로 적용된 EXIF 데이터를 확인할 수 있습니다.


references
http://lightroomsecrets.com/2009/11/metadata-presets/
http://haydnwilliams.com/blog/wp-content/uploads/2008/03/lr_exiftool_mapping.pdf
posted by cookis