Platform Engineer

VMware KB 블로그에 올라온 새로나온 KB를 정리해 보았습니다.

https://blogs.vmware.com/kb/2019/02/new-kb-articles-published-for-the-week-ending-16th-febuary2019.html

VMware vSphere ESXi

High number of “snmpd: lookup_vswitch: fetch VSI_MODULE_NODE_PortCfgs_properties failed Not found” messages in syslog.log

Date Published: 2/13/2019

Syslog logging 레벨이 WARNING 이상으로 설정되어 기록되는 것으로 서비스에 영향은 없습니다.

WMI Performance Adapter Service crashes on Windows 10 and Windows Server 2016 VMs with when VMware Tools

Date Published: 2/15/2019

VMware tools의 vmStatsProvider 의 이슈로 WmiApSrv.exe 서비스가 크래시되는 것으로 VMware Tools 10.1.10에서 fix 되었습니다.

VMware NSX Data Center

Rule Configuration failure is observed when multiple ports are configured for ALG Service

Date Published: 2/14/2019

FTP/SUNRPC와 같은 ALG 서비스를 위한 FW 룰을 만들때 다수의 Port가 구성되면 문제가 발생합니다. NSX 6.4.3에서 문제가 발생되고 아직까지 해결방법은 나오지 않았습니다. Workaround로 1개의 포트만 구성하셔야 합니다.

VMware NSX SD-WAN

VMware SD-WAN by VeloCloud Software Upgrade FAQ

Date Published: 2/14/2019

SD-WAN 제품인 VeloCloud 소프트웨어 업그레이드 FAQ 입니다.

VMware SDDC Manager

The HMS upgrade process fails with the following message “HMS Failed to Discover All Rack(s)” in VMware Cloud Foundation

Date Published: 2/11/2019

SSH HostKey 문제로 HMS 업그레이드가 실패 합니다. 수동으로 Hostkey를 재설정해서 해결할 수 있습니다.

How to import the SSL certificate from HPE Redfish for composability use in VMware Cloud Foundation 3.5.x

Date Published: 2/13/2019

원격관리를 위해 HPE Redfish connector를 연결할때 오류가 발생하며 Redfish SSL certificate를 수동으로 추가해야 합니다.

Creating an NSX-T VI workload domain in VMware Cloud Foundation 3.5.x fails on the Deploy NSX-T Manager task

Date Published: 2/11/2019

NSX-T workload domain을 위한 파일이 존재하지 않아서 오류가 발생하는 것으로 수동으로 복사해서 해결할 수 있습니다.

How to upgrade NSX-T components in VMware Cloud Foundation 3.5.1

Date Published: 2/11/2019

VCF를 3.5.1로 업그레이드 한 후 NSX-T를 2.3.1로 업그레이드해야 합니다.

VMware vCenter Server

Deploying a VM fails with “There is no VM_NAME process running for config file”

Date Published: 2/15/2019

Namespace DB 생성과 Migration 사이의  경합으로 VM이 생성되지 않을 수 있습니다. 현재 해결 방법을 찾고 있습니다.

VMware vRealize Operations Manager

The Service Discovery Management Pack provides minimal VM relationships and discovery

Date Published: 2/12/2019

Service Discovery Management Pack 2.1 부터 새로운 기능이 추가 되었습니다.

The list of child objects in a custom group under ‘Objects To Always Include/Exclude’ is incomplete in vRealize Operations 6.x and later

Date Published: 2/12/2019

Child object가 1000개의 제한을 가지고 있기 때문에 1000개 이상은 REST API를 사용해야 합니다.

“Troubleshoot a VM” is empty for users with limited access in vRealize Operations Manager 6.7 and higher

Date Published: 2/14/2019

admin 권한이 없으면 Troubleshoot a VM 대시보드에 아무것도 보이지 않는 이슈로 사용자나 그룹에 권한을 할당해야 볼 수 있습니다.

VMware vRealize Orchestrator

vRealize Orchestrator 7.x SQL plugin: “Add a Host” workflow fails with “Name already exists!”

Date Published: 2/12/2019

Orphaned 된 object가 남아 있어서 발생하는 오류로 XML resource element object를 삭제하면 됩니다.

VMware vSAN

vSAN KMS Health Check intermittently fails with SSL Handshake Timeout error: “QLC_ERR_TIMEOUT_EXPIRED” on vSphere 6.5

Date Published: 2/12/2019

vSAN 호스트와 KMS 사이의 지연이 1초 이상되면 발생하는 문제로 6.7에서 fix 되었으며 Certificate의 크기를 2048 bit으로 줄여서 회피할 수 있습니다.

감사합니다.

VMware KB 블로그에 올라온 새로나온 KB를 정리해 보았습니다.

https://blogs.vmware.com/kb/2019/02/new-kb-articles-published-for-the-week-ending-9th-february2019.html

VMware vSphere ESXi

Storage Center systems with Front End SAS connectivity show lun capacity 0MB
Date Published: 2/5/2019 

Dell SC Storage에 사용하는 lsi-msgpt3 드라이버 이슈로 Capacity를 잘못 보여주거나 PSOD 등이 발생할 수 있습니다.

VMware Horizon

Installation of Horizon View Agent 7.7 or newer on Windows 2008 R2 Server may fail
Date Published: 2/5/2019 

설치하려는 커널 드라이버 서명 이슈로 설치에 실패할 수 있습니다. Microsoft KB3033939로 해결할 수 있습니다.

Issues when Horizon View Connection Server / Security Server when deployed with dissimilar FIPS mode configurations

Date Published: 2/4/2019

다른 FIPS 모드가 설정된 View Connection 서버를 같은 POD에 배포하면 통신 오류가 발생합니다. 동일 FOPS로 설정해야 합니다.

VMware NSX for vSphere

NSX for vSphere 6.4.x postgres database queuing too many events and alarms causing high NSX Manager CPU utilization and filling of ‘/common’ partition
Date Published: 2/7/2019

Cluster host, Edge Service 등에서 Event 가 너무 많이 발생되서 /common 파티션 공간 부족, High CPU, SSH 연결이 안되는 증상이 발생하는 것으로 Support의 지원을 받으셔야 합니다.

VMware NSX-T Data Center

NSX-T Manager Upgrade Stalls with GUI and API Inaccessible
Date Published: 2/8/2019

2.3.0에서 2.3.1로 업그레이드 할때 실패하는 cron job으로 등록된 du가 원인 입니다. 2.4에서 해결될 예정입니다.

VMware SDDC Manager

How to upgrade VMware Cloud Foundation to version 2.3.2.6
Date Published: 2/8/2019

VCF 2.3.2.5에서 2.3.2.6으로 업그레이드 하는 방법 입니다.

Operations against an existing NSX-T workload domain fails after upgrading VMware Cloud Foundation to version 3.5.1
Date Published: 2/4/2019

VCF 3.5.1로 업그레이드한 후 NSX-T workload domain이 실패하는 경우 인증서 관련 조치 방법 입니다.

VMware Cloud Foundation does not successfully update the admin password in vRealize Operations Manager
Date Published: 2/4/2019

VCF에서 vRealize Operations Manager의 관리자 암호를 변경하지 못하는 이슈로 수동 업데이트로 해결할 수 있습니다.

Stopping and starting services on the SDDC Manager 3.x appliance fails.
Date Published: 2/6/2019

SDDC Manager VM의 서비스를 중지/시작할 수 없는 이슈로 root 권한을 획득해야 합니다.

VMware Skyline Collector Appliance

Dual-Homing the Skyline Collector VA Appliance
Date Published: 2/7/2019

Dual-Homing 구성일때 Skyline 네트워크 구성법 입니다.

VMware vCloud Usage Meter

How to submit missing usage reports that prevent automatic reporting
Date Published: 2/9/2019

사율률 리포트 오류로 자동으로 제출되지 않을때 대처 방법 입니다. 

VMware vRealize Operations Manager

CIM related metrics are not present with Management Pack for Storage Devices in vRealize Operations Manager 6.x and up
Date Published: 2/6/2019

SMART data collection via CIM API가 Disable 되어 있는 경우 스토리지 장비에 대한 CIM 정보가 수집되지 않습니다.

VMware vSAN

vSAN Drives presentation changed from pass-through to RAID0 automatically after upgrading the host from 6.5 U2C to 6.5 P03 (due to SSACLI utility )
Date Published: 2/6/2019

호스트를 6.5 U2C HPE 빌드에서 6.5 Patch 03으로 업그레이드 한 경우 hp-hpsa plugin 인 ssacli 문제로 vSAN 드라이브가 pass-through 에서 RAID0로 변경되어 보일 수 있습니다. 

감사합니다.

VMware KB 블로그에 올라온 새로나온 KB를 정리해 보았습니다.

원본 https://blogs.vmware.com/kb/2019/02/new-kb-articles-published-for-the-week-ending-2nd-february2018.html

VMware vSphere ESXi

NFS warning entries displayed in vmkernel logs for NFS version 4.1 and ESXi 6.7

Date Published: 1/28/2019 경고성 메시지로 시스템에 영향을 주지 않습니다.

VM deployed from template shows the original Network adapter in Summary tab incorrectly after powering VM on

Date Published: 1/28/2019 vCenter 6.5로 ESXi 6.0 이전을 관리할 때 ESXi 6.0에서 만들어진 Template으로 VM을 만들면 Network adapter 설정에 오류가 있습니다.

ESXi host is disconnected from vCenterServer and it is in an unresponsive state

Date Published: 1/29/2019 vmdk 파일 이름이 scsix: x.fileName 로 설정되어 있지 않아서 hostd가 계속 비정상종료되고 ESXi가 행 상태가 되는 이슈 입니다.  ESXi 6.0 P7에서 수정 되었습니다.

End of General Support for vSphere 6.0

Date Published: 1/31/2019 ESXi 5.5가 이미 EOGS 된 것처럼 ESX 6.0이 2020년 3월 12일에 EOGS 됩니다. 미리 업그레이드 준비를 하셔야 합니다.

VMware Horizon

Unable to start Skype calls from Virtual desktops using Virtualization Pack for Skype for Business.

Date Published: 1/30/2019 Virtualization pack for Skype for Business를 사용하면서 Proxy 설정이 되어 있는 경우 Skype call을 사용할 수 없습니다. 이 문제는 Horizon client 4.8에서 해결 되었습니다.

VMware SDDC Manager

Cloud Foundation upgrade from 3.0 to 3.5 fails with error “The registration of the ESXi upgrade bundle (iso) failed. Upgrade Failed”.

Date Published: 1/27/2019 Cloud Foundation 3.0에서 3.5로 업그레이드 할때 LCM 프로세스가 정상적으로 삭제가 되지 않아 발생하는 문제 입니다. 아직 패치가 있지는 않고 Workaround로 ssh를 사용해서 업그레이드 하는 vCenter에 접속해서 iso 파일을 삭제해야 합니다.

There is no option to change the MyVMware credentials on the Repository Settings page in SDDC Manager

Date Published: 1/30/2019 MyVMware 에서 암호를 변경한 후 SDDC Manager에서 오류 메시지가 나타나는 것으로 현재 해결 방법은 SDDC Manager VM에 접속해서 인증 정보를 변경해야 합니다.

Changing DNS Configuration of a vCenter breaks vCenter High Availability

Date Published: 1/30/2019 vCenter의 IP/DNS를 변경하는 것은 지원하지 않는 동작 입니다. VCHA 구성을 변경하기 전에 VCHA를 destory 하는 작업을 해야 합니다.

Unable to power ON Virtual machine with Error: Failed to power on the virtual machine. Cannot create Flash Read Cache: Operation failed.

Date Published: 1/29/2019 vFRC로 사용되던 SSD가 제거되어 발생한 문제로 vmx 파일을 수정해서 vFlash 구성 값을 변경해야 합니다.

VMware vRealize Automation

Request stuck at ‘In Progress’ if not approved within 7 days

Date Published: 1/31/2019 Deployment가 7일 안에 승인되지 않으면 Token이 제거되면서 발생하는 문제 입니다. in-progress task를 수동으로 삭제해야 합니다.

VMware vRealize Log Insight

vRealize Log Insight node fails to start with error “keystore was tampered with or password was incorrect”

Date Published: 1/31/2019 keystore가 사용자에 의해 수정되었거나 스토리지에 이슈가 있을 때 발생하는 이슈로 정상적인 노드에서 keystore를 복사해서 해결할 수 있습니다.

VMware vRealize Operations Manager

vRealize Operations Manager initial deploy fails if the Virtual Machine Port Group contains non-ASCII characters

Date Published: 1/31/2019 포트그룹 이름에 ASCII 가 아닌 한글이나 일본, 중국어 같은 문자가 들어 있을 경우 발생하는 이슈로 추후 해결될 예정으로 현재는 ASCII 문자만 사용해야 합니다.

VMware vSAN

vCenter reported “Host cannot communicate with other hosts” however there was never a network partition

Date Published: 1/31/2019 vSAN management 데몬의 메모리 이슈로 6.5 U2 P3에 해결 되었습니다.

감사합니다.

서버에 네트워크가 연결되지 않을때 네트워크 어뎁터 상태, ip address 구성, route 정보, ping, 네트워크 연결 상태, 네트워크 연결 테스트, 방화벽 설정 등을 점검하는 방법에 대해서 정리해 보았습니다.

-------------------------------------------------------- Linux -----------------------------------------------------------

네트워크 어뎁터가 연결되어 있는지 확인하기 위해 리눅스 에서는 ethtool을 사용합니다. 명령의 결과 가장 아래에 Link detected 가 yes로 되어 있으면 네트워크 어뎁터가 연결되어 있는 것입니다.

네트워크 IP 구성이 잘 되어있는지 확인하기 위해 ip address 명령을 사용 합니다. 

라우팅 정보는 route 명령을 사용해서 확인 합니다.

다른 장비로 Ping이 되는지 테스트 해봅니다.

라우팅 경로는 traceroute를 사용하고 mtr을 사용해서 좀 더 자세한 정보를 얻을 수 있습니다.

Network port 가 열려 있는지는 telnet, nc, nmap 등의 도구로 테스트 가능하나 샘플로 테스트는 진행하지 못했습니다.

Network connection 상태는 netstat 명령을 사용하면 확인 가능 합니다.

-------------------------------------------------------- ESXi -----------------------------------------------------------

네트워크 어뎁터가 연결되어 있는지 확인하기 위해 ESXi에서는 esxcli network nic list 명령을 사용합니다. Link Status 값이 Up으로 되어 있으면 네트워크가 연결된 것입니다.

ESXi 에서는 esxcli network ip interface ipv4 address list 명령을 사용해서 IP address와 netmask를 알 수 있습니다. CLI로 물리 어뎁터의 IP를 확인하는 방법은 찾지 못했습니다. vCenter나 Console에서 확인이 가능하기는 하지만 esxcli 또는 PowerCLI로 확인하는 방법도 있을것 같습니다.

라우팅도 esxcli 명령을 사용해서 확인 합니다.

esxi 에서는 vmkping을 사용해서 네트워크 상태를 확인할 수 있습니다. -s를 이용하면 패킷의 크기를 조절할 수 있고, -I 옵션을 사용하면 특정 vmk 을 사용해서 ICMP를 보낼 수 있습니다.

ESXi 에서도 traceroute를 사용할 수 있습니다.

telnet은 예전 버전에서는 사용 가능했던 것으로 보이나 6.7에서는 실행되지 않았습니다. 대신 nc를 사용하면 됩니다. 자세한 내용은 아래 KB를 확인하면 됩니다.

https://kb.vmware.com/s/article/2020669

Network 이 연결된 상태를 확인하려면 esxcli network ip connection list 명령을 사용하면 됩니다. 자세한 설명은 KB에 있습니다.

https://kb.vmware.com/s/article/2020669?lang=en_US

Network connection의 상태는 esxcli network ip connection list 명령을 통해서 확인 가능 합니다.

ESXi 에도 기본적으로 방화벽이 설정되어 있습니다. esxcli network firewall ruleset rule list 명령을 통해서 어떤 포트가 열려 있는지 확인 가능 합니다.

------------------------------------------------------ Windows ---------------------------------------------------------

Windows 에서는 NIC가 연결되어 있는지 확인은 GUI로 할 수 도 있으나 PowerShell로 확인해 보도록 하겠습니다. Get-NetAdapter cmdlet을 사용하면되고 Ethernet1 은 Network cable이 Disconnect 되어 있는 상태이고 Ethernet0은 정상적으로 연결되어 있는 상태인 것을 확인할 수 있습니다.

Windows 에서는 ipconfig 명령을 사용하는 것이 더 일반적이지만 PowerShell의 Get-NetIPAddress cmdlet을 사용해 보았습니다. Windows 에서도 ipconfig, netstat 명령처럼 오래전에 개발된 명령들은 더이상 추가 개발이나 수정을 하지 않기 때문에 PowerShell을 사용하는 것에 익숙해질 필요가 있습니다.

라우팅도 route print 명령이 있지만 PowerShell을 사용해서 확인 합니다.

Ping을 사용할 수 있지만 역시 PowerShell을 사용하도록 하겠습니다. Test-Connection은 ICMP를 보내는 Ping과 유사하다고 생각하면 됩니다. Test-NetConnection으로 Port를 지정해주면 해당 포트가 열려 있는지 확인할 수 있습니다. (Windows 에서 보안 이슈로 telnet은 기본 설치가 아닙니다. Feature로 추가를 하거나 Test-Connection 명령으로 테스트를 해야 합니다.)

Windows 에서는 Tracert를 사용할 수 있는데 PowerShell의 Test-NetConnection을 사용할 수도 있습니다. Windows에는 mtr과 같은 도구가 설치되어 있지 않은데 PowerShell로 개발된 스크립트가 있으니 대용으로 사용할 수 있습니다. https://gist.github.com/tylerapplebaum/dc527a3bd875f11871e2

Network의 연결 상태는 netstat 명령으로도 확인 가능하지만 Get-NetTCPConnection cmdlet으로 확인 가능 합니다. netstat에 마이너한 버그가 있었던 것으로 기억하는데 오래전 코드라 수정을 안한다고 기억 합니다.

방화벽 설정 룰을 확인하는 PowerShell cmdlet은 Get-NetFirewallRule, Get-NetFirewallPortFilter 를 조합하는 것인데 사용법이 편하지 않습니다. (블로그를 보면 이 cmdlet을 조합하는 것이 있습니다. https://itluke.online/2018/11/27/how-to-display-firewall-rule-ports-with-powershell/) 

방화벽 설정은 기존 netsh 명령으로 확인을 할 수 있습니다.

감사합니다.

시스템 행 현상이 발생 되었을때 원인 분석을 하는 방법에 대해서 글을 써보려고 하고 다음번 글에서는 행 덤프를 분석하는 방법을 쓰려고 합니다.

Windows나 ESXi 모두 커널 레벨에서 행이 발생하였을때 Reset을 해서 시스템을 재부팅하는 방법으로 문제를 해결하는 경우가 종종 있습니다. 하지만 문제가 빈번하게 재현되고 운영중인 Application이 중요한 역할을 하는 경우 원인 분석을 해야 하는 경우가 많이 있습니다. 행 현상이 발생하면 NMI를 이용해서 덤프를 수집하는 방법을 알아보겠습니다.

NMI란 무엇인가?

우선 NMI가 무엇인지 확인해보면 Wiki에 Non-maskable interrupt 라고 되어 있고 하드웨어가 발생시키는 인터럽트로 시스템이 ignore 할 수 없다고 되어 있습니다. 하지만 NMI는 하드웨어에서 발생시키는 경우만 있는 것이 아니라 행 분석을 위해서 시스템에 있는 NMI switch를 눌러(쇼트)서 수동으로 발생시키는 경우도 있습니다.

https://en.wikipedia.org/wiki/Non-maskable_interrupt

먼저 하드웨어로 인한 문제를 확인해 보겠습니다. 아래 HPE의 문서를 보면 하드웨어 이슈로 NMI가 호출되어 VMware의 ESXi에서 PSOD가 발생되었다고 합니다.

Advisory: (Revision) VMware - HPE ProLiant Gen8 Servers running VMware ESXi 5.5 Patch 10, VMware ESXi 6.0 Patch 4, Or VMware ESXi 6.5 May Experience Purple Screen Of Death (PSOD): LINT1 Motherboard Interrupt

https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-c05392947

ESXi host fails with intermittent NMI purple diagnostic screen on HP servers (2085921)

https://kb.vmware.com/s/article/2085921

ESXi host fails with intermittent NMI PSOD on HP ProLiant Gen8 servers (2149043)

https://kb.vmware.com/s/article/2149043

VMware 환경에서 하드웨어로 인한 NMI 크래시에 대해서 설명하고 있습니다.

"LINT1 motherboard interrupt" error in an ESX/ESXi host (1804)

https://kb.vmware.com/s/article/1804

Windows 환경에서도 유사하가 하드웨어(Memory) 오류로 NMI가 호출되어 시스템이 BSOD가 발생된 것이 확인됩니다.

NMI Memory Parity error received during shutdown on Windows 7 and Windows Server 2008 R2

https://support.microsoft.com/en-au/help/2845432/nmi-memory-parity-error-received-during-shutdown-on-windows-7-and-wind

물리적인 하드웨어 뿐만 아니라 가상 하드웨어로 인해서 NMI가 발생할 수도 있습니다. 

VMware ESXi 5.5.x and 6.x hosts experiences a purple diagnostic screen mentioning ALERT: NMI: 709: NMI IPI received (2149704)

https://kb.vmware.com/s/article/2149704

하드웨어로 인한 NMI가 발생한 경우 하드웨어 업체에 연락을 해서 관련 이슈가 있는지 파악을 하고 하드웨어 점검, Firmware, Driver 업데이트 등을 진행할 수 있습니다. 문제가 계속 재현되는 경우 하드웨어를 교체해야할 수도 있습니다.

시스템 행 현상이 발생하였을 때 NMI를 이용한 행 덤프 수집

시스템 행 현상은 ESXi host에 ssh 접속이 안되거나 Windows 의 경우 RDP 등이 접속안되는 상태를 이야기 합니다. 결국 시스템의 중요 프로세스가 응답하지 못하는 상태가 되어 SSH 연결이나 RDP 연결을 받아주지 못하는 경우를 이야기 합니다. 이런 경우 우선 Ping을 해서 하드웨어 레벨에서 행이 걸렸는지 확인해볼 수 있습니다. Ping은 되는데 SSH나 RDP가 안되는 경우 하드웨어가 아닌 소프트웨어 이슈로 시스템이 응답하지 않는 것입니다.

시스템 행 현상이 발생하면 일반적으로 Reset 키를 눌러서 시스템을 재부팅을 하게 되는데 기술지원 계약이 되어 있는 경우 NMI를 이용해서 Dump를 수집하면 원인분석을 의뢰 할 수 있습니다.

-------------------------------------------------------- ESXi -----------------------------------------------------------

VMware는 KB문서를 통해서 시스템 행 현상이 있을 때 덤프를 수집하는 방법을 가이드 하고 있습니다.

ESXi host fails with intermittent NMI PSOD on HP ProLiant Gen8 servers (2149043)

https://kb.vmware.com/s/article/2149043https://kb.vmware.com/s/article/1014767

문서의 내용을 살펴보면 행 현상이 어떤 것인지 정의를 먼저 하고 있습니다. 행 현상은 vSphere client 에 응답하지 않거나, Ping에 응답하지 않거나, ESXi에서 실행중인 VM이 network에 응답하지 않거나, 콘솔 명령에 응답하지 않거나, Alt+F12를 콘솔에서 눌렀을때 VMkernel log가 화면에 출력되지 않는 경우를 이야기 합니다. 행 현상이 하드웨어에 의한 것인지 확인하기 위해 NumLock 키를 눌러 보거나 디스크나 네트워크에 워크로드가 있는지 확인, Ping으로 확인하는 등의 작업을 할 수 있지만 원인 분석을 위해서는 NMI를 이용해서 덤프를 수집해야 합니다.

Determining why an ESX/ESXi host does not respond to user interaction at the console (1017135)

https://kb.vmware.com/s/article/1017135?CoveoV2.CoveoLightningApex.getInitializationData=1&r=2&ui-communities-components-aura-components-forceCommunity-seoAssistant.SeoAssistant.getSeoData=1&other.KM_Utility.getArticleDetails=1&other.KM_Utility.getArticleMetadata=2&other.KM_Utility.getUrl=1&other.KM_Utility.getUser=1&other.KM_Utility.getAllTranslatedLanguages=2&ui-comm-runtime-components-aura-components-siteforce-qb.Quarterback.validateRoute=1

NMI를 사용해서 수동으로 덤프를 수집하기 위해서는 ESXi에 설정이 필요한데 ESXi 5.0 이후로는 별도의 설정 없이 NMI 버튼을 누르면 PSOD 덤프가 수집 됩니다.

KB의 마지막 부분에는 각 하드웨어 별로 NMI를 발생시키는 방법이 가이드 되어 있습니다.

Triggering the NMI

The NMI button or switch location varies depending on the hardware. A small set of examples are available:

IBM x3650 M2 – The NMI button is on the diagnostic panel. There may also be a Send NMI button in the RSA. For more information, see the x3650 M2 Installation and Users Guide.

HP Proliant – The NMI button or jumper is on the motherboard. There is also a Send NMI button in the iLO. For more information, see Performing an HP ProLiant server NMI crash dump.

Dell R900 – The NMI button is on the front panel. For more information, see the R900 Systems Hardware Owner's Manual.

Fujitsu PRIMERGY Servers (RX/TX) - The NMI button is on the front of the server. For more information, see the Operating Manual for your PRIMERGY Servers. The manual can be found at the Fujitsu website.

Click [Industry standard servers] - [PRIMERGY Servers]

Select your PRIMERGY Servers from the pulldown menu. For example, [PRIMERGY RX Servers] - [PRIMERGY RX300 Sriese] - [PRIMERGY RX300 S7]

Download the Operating Manual and check for the NMI button location.

Cisco UCS – The NMI can be sent via IPMI or the UCS Manager command-line interface:

IPMI command – ipmitool -I lan -H <RemoteServerBMCAddress> -U <Username> -a chassis power diag

UCSM command – diagnostic-interrupt.

For more information, see the Cisco UCS command-line reference documentation for the diagnostic-interrupt command.

The preceding links were correct as of November 6, 2013. If you find a link is broken, provide feedback and a VMware employee will update the link.

ESXi 호스트가 아닌 VM에 행 현상이 발생할 경우에도 NMI를 이용해서 덤프를 수집할 수 있습니다. ESXi 에서는 Snapshot을 이용해서 메모리 파일을 덤프 파일로 변환하는 방법으로 덤프를 수집할 수 도 있지만 VM에 NMI 인터럽트를 전달해서 행 덤프를 수집할 수도 있습니다. vCenter Web Clinet를 이용하거나 VM-support 명령 또는 vmdumper 명령을 사용해서 덥프를 수집할 수 있습니다.

How to send NMI to Guest OS on ESXi 6.x (2149185)

https://kb.vmware.com/s/article/2149185

How to capture a vmcore of hung Red Hat Enterprise Linux VMware® guest system using VMware® "vmss2core" tool ?

https://access.redhat.com/solutions/411653

아래 문서는 NMI로 인해 Windows VM이 크래시 된 것에 대한 설명을 하고 있습니다.

Windows virtual machines fails with a Stop Error: Hardware Malfunction - Call your hardware vendor for support (2105345)

https://kb.vmware.com/s/article/2105345

아래 문서에서는 Red Hat 리눅스가 행 현상이 있을때 ESXi 에서 NMI를 발생하는 방법을 설명하고 있습니다.

Red Hat Enterprise Linux - How to Force a Crash on a Hung Linux Virtual Machine Running on VMware ESXi Server

https://support.hpe.com/hpsc/doc/public/display?docId=mmr_kc-0105964

------------------------------------------------------ Windows ---------------------------------------------------------

Microsoft 에서는 아래 문서에서 행 현상이 있을때 덤프를 수집하는 방법을 설명하고 있습니다.

How to generate a kernel or a complete memory dump file in Windows Server

https://support.microsoft.com/en-us/help/969028/how-to-generate-a-kernel-or-a-complete-memory-dump-file-in-windows-ser

이 문서에서 별도로 행 현상에 대해서 설명을 하고 있지는 않지만 ESXi와 비슷하게 RDP 접속해보기, Numslock 눌러보기, Ping 해보기 등으로 행 현상이 있는지 확인해볼 수 있습니다.

Windows 는 커널 덤프, 전체 덤프와 같이 덤프의 유형이 있는데 각 유형에 따라서 적절한 페이지 파일 크기를 설정해 주어야 덤프파일이 정상적으로 수집됩니다. 커널 덤프의 경우 Windows 커널이 사용하는 메모리만 덤프 파일에 저장하는 것으로 커널의 메모리 사용량에 따라서 2 ~ 16GB 정도면 충분한 크기라고 할 수 있습니다. 전체 덤프의 경우 물리 메모리의 내용을 모두 덤프 파일에 저장하는 것으로 물리메모리 크기 + 1MB 이상의 페이지 파일이 있어야 덤프를 수집할 수 있습니다. Windows 커널의 행 현상에 대해서는 커널 덤프로 분석이 가능하지만 유저모드 프로세스의 행 현상은 전체 덤프를 수집해야 분석이 가능할 수 있습니다.

Windows 시스템에서는 일반적으로 키보드 (오른쪽 Ctrl 키를 누른 상태에서 Scroll Lock 를 두번 누르기)를 이용해서 덤프를 수집할 수 있는데 별도의 설정을 키보드에 해야하기 때문에 문제가 발생하기 전에 운영하는 시스템에 모두 키보드 덤프를 설정해 두어야 합니다. 덤프 생성을 위한 키를 변경할 수도 있으며 

Forcing a System Crash from the Keyboard

https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/forcing-a-system-crash-from-the-keyboard

Windows 시스템에서도 NMI를 이용해서 덤프를 수집할 수 있습니다. 

How to generate a complete crash dump file or a kernel crash dump file by using an NMI on a Windows-based system

https://support.microsoft.com/en-us/help/927069/how-to-generate-a-complete-crash-dump-file-or-a-kernel-crash-dump-file

PowerShell을 사용해서 Hyper-V 에서 VM에 NMI 인터럽트를 발생시키는 방법도 있습니다.

Debug-VM

https://docs.microsoft.com/en-us/powershell/module/hyper-v/debug-vm?view=win10-ps

Azure 환경에서 Serial console을 사용해서 Guest에 NMI를 보내는 방법도 있습니다. AWS에서는 어떻게 NMI를 보낼 수 있는지 찾지를 못했습니다.

Use Serial Console for SysRq and NMI calls

https://docs.microsoft.com/ko-kr/azure/virtual-machines/troubleshooting/serial-console-nmi-sysrq

다음 번에는 수집된 덤프를 분석하는 방법을 써보려고 합니다.

감사합니다.

최근에 BSOD 분석을 넘어서 PSOD 분석을 하고 있습니다. 처음에는 gdb 사용법을 전혀 몰라서 고생을 했는데 이제는 간단한 분석은 회사 시스템을 통해서 할 수 있게 되었습니다.

디버깅을 하면서 느낀 것은 Windows Kernel Debugging과 원리는 비슷한데 실제 구현은 다르다는 것입니다. 비슷하면서 다른 점을 확인해보면 Windows kernel에 있는 spinlock이라는 개념이 동일하게 Linux와 ESXi에 있고 ESXi 에서는 spinlock을 오래 소유하면 시스템이 크래시 될 수 있습니다. Windows 에서는 Spinlock을 오래 소유하면 행만 말생하고 크래시가 되지는 않습니다. (시스템을 행 상태로 둘 것인지? 아니면 크래시를 해서라도 행을 해소하고 원인 분석을 할지는 업체마다 판단이 다릅니다.)

아래 VMware 문서의 설명을 보면 Spinlock을 오래 소유하고 있어서 Spinlock count가 한계에 달해서 시스템이 크래시 되었다고 합니다. 스택에 나오는 것은 Spinlock을 소유하기 위해 대기하는 Thread 이어서 원인을 찾기 위해서는 Spinlock을 소유한 Thread를 찾아야합니다. 일반적으로 원인은 ESXi 또는 3^rd party kernel driver 가 spinlock을 해제하지 않았기 때문입니다.

Microsoft는 WinDbg를 통해서 BSOD를 분석할 수 있게 공개하였지만 VMware는 디버깅 방법이 공개되어 있지 않기 때문에(아마도 공개 안 되어 있을 것 같습니다.) VMware support 부서에 연락해서 기술지원을 받아야 할 것입니다. 만약 원인 분석 보다는 문제 예방을 원하실 경우 ESXi 와 각종 드라이버를 최신으로 update 하면 좋습니다. 신규 버그가 아니라면 패치를 설치해서 기존 문제들을 해결할 수 있습니다. 그래도 문제가 재현된다면 core dump 파일을 수집해서 업체의 분석을 받아야 합니다.

Understanding a "Spin count exceeded" purple diagnostic screen (1020105)

https://kb.vmware.com/s/article/1020105

VMware ESX Server [Releasebuild-207095]

Spin count exceeded (iplLock) - possible deadlock

cr2=0xb6ea3fff cr3=0x22401000 cr4=0x6f0

frame=0x14028d4 ip=0x626265

es=0xffffffff ds=0xffffffff fs=0xffffffff gs=0xffffffff

eax=0xffffffff ebx=0xffffffff ecx=0xffffffff edx=0xffffffff

ebp=0x1402a3c esi=0xffffffff edi=0xffffffff err=-1 eflags=0xffffffff

*0:1024/console 1:1094/vmm0:M100 2:1086/vmware-vm 3:1118/mks:dby-d

4:1109/vmm0:M102 5:1116/vmm0:dby- 6:1096/mks:M1000 7:1082/vmm0:M100

@BlueScreen: Spin count exceeded (iplLock) - possible deadlock

0x1402a3c:[0x626265]Panic+0x10 stack: 0x83821c, 0x2970608, 0x4

0x1402a90:[0x634ff3]SP_WaitLock+0x1ca stack: 0x2970600, 0x1402ab8, 0x9d75ef

0x1402a9c:[0x9b1386]cosShadow+0x385 stack: 0x0, 0x2865a40, 0x2865a40

0x1402ab8:[0x9d75ef]cosShadow+0x265ee stack: 0x0, 0xa8ae9be8, 0x53ac1

0x1402af0:[0x63b947]TimerBHHandlerLoop+0x18e stack: 0x1456c98, 0x0, 0x148a798

0x1402b30:[0x63e7b1]Timer_BHHandler+0xb8 stack: 0x0, 0xdf, 0x0

0x1402b88:[0x6188c5]BH_Check+0x84 stack: 0x1, 0x1402bac, 0x1754941

0x1402bac:[0x620126]IDT_HandleInterrupt+0x85 stack: 0x1402bf8, 0x0, 0x37638000

0x1402bc0:[0x62024d]IDT_IntrHandler+0x4c stack: 0x1402bf8, 0x4028, 0x4028

0x1402c70:[0x693b7c]CommonIntr+0xb stack: 0x14897a0, 0x0, 0x1402de0

0x1402e1c:[0x763234]CpuSchedDispatch+0x487 stack: 0x2391f00, 0x14897a0, 0x0

0x1402e88:[0x765a36]CpuSchedDoWaitDirectedYield+0x351 stack: 0x0, 0x1f57f60, 0x0

0x1402ea4:[0x765b66]CpuSched_WaitIRQ+0x31 stack: 0xfedcba90, 0x6, 0x1f57f60

0x1402ec4:[0x692893]VMNIXVMKSyscall_Idle+0xe2 stack: 0x1402f6c, 0x6924e3, 0x0

0x1402ecc:[0x687538]VMNIXVMKSyscallUnpackIdle+0x7 stack: 0x0, 0x0, 0x0

0x1402f6c:[0x6924e3]HostSyscall+0xf6 stack: 0x1402fbc, 0xc03dbf98, 0x1c

0x1402fe8:[0x69187f]HostVMKEntry+0xce stack: 0x0, 0x0, 0x0

VMK uptime: 6:09:43:15.399 TSC: 1472031313725856

Starting coredump to disk Starting coredump to disk Dumping using slot 1 of 1... using slot 1 of 1... log

Windows에는 Spinlock에 의한 크래시는 없지만 인터럽트의 후속처리를 하는 DPC (Linux의 Bottom half에 해당하는 것으로 보임) 에서 너무 많은 시간 동은 실행이 되면 BugCheck 0x133이 발생합니다. 일반적으로 HW 에서 인터럽트가 발생하고 DPC 루틴을 실행할 때 너무 시간이 많이 걸려서 크래시 되는 것입니다.

Bug Check 0x133 DPC_WATCHDOG_VIOLATION

https://docs.microsoft.com/ko-kr/windows-hardware/drivers/debugger/bug-check-0x133-dpc-watchdog-violation

DPC 루틴 하나가 너무 많은 시간을 사용한 경우 콜스택만 보면 원인을 확인할 수 있으나 다수의 DPC 루틴이 실행된 경우 원인을 찾기가 힘들어집니다. 이 경우 아래 블로그를 참고해서 xPerf를 실행해야할 수도 있습니다. (꼭 Microsoft의 지원을 받으셔야 원인을 찾을 수 있습니다.)

Determining the source of Bug Check 0x133 (DPC_WATCHDOG_VIOLATION) errors on Windows Server 2012

https://blogs.msdn.microsoft.com/ntdebugging/2012/12/07/determining-the-source-of-bug-check-0x133-dpc_watchdog_violation-errors-on-windows-server-2012/

아래와 같이 HP 드라이버에서 문제가 발생할 수도 있고 Windows Kernel의 문제로 발생할 수도 있습니다.

권고: HP 네트워크 서버 어댑터 - Windows Server 2012 R2에서 ocnd64.sys v11.1.145.30 드라이버를 실행하면 Bugcheck 0x133 오류가 발생할 수 있음

https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-a00005104es_es

FIX: Stop error 0x133 or 0x9E occurs when WHEA record is not acknowledged by SMI in Windows

https://support.microsoft.com/en-us/help/2877237/fix-stop-error-0x133-or-0x9e-occurs-when-whea-record-is-not-acknowledg

Analyzing the dump showed the following stack

DPC_WATCHDOG_VIOLATION (133)

The DPC watchdog detected a prolonged run time at an IRQL of DISPATCH_LEVEL

or above.

Arguments:

Arg1: 0000000000000001, The system cumulatively spent an extended period of time at

DISPATCH_LEVEL or above. The offending component can usually be

identified with a stack trace.

Arg2: 0000000000003c19, The watchdog period.

Arg3: 0000000000000000

Arg4: 0000000000000000

Debugging Details:

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

DPC_TIMEOUT_TYPE: DPC_QUEUE_EXECUTION_TIMEOUT_EXCEEDED

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: 0x133

PROCESS_NAME: System

CURRENT_IRQL: d

ANALYSIS_VERSION: 6.13.0015.1713 (debuggers(dbg).130203-2012) amd64fre

LAST_CONTROL_TRANSFER: from fffff802145e3cb3 to fffff80214464440

STACK_TEXT:

fffff880`0c4a54f8 fffff802`145e3cb3 : 00000000`00000133 00000000`00000001 00000000`00003c19 00000000`00000000 : nt!KeBugCheckEx

fffff880`0c4a5500 fffff802`144a8774 : fffff880`0c4a5670 00000000`0042f906 fffff880`0c4a5680 fffff780`00000320 : nt! ?? ::FNODOBFM::`string'+0x14600

fffff880`0c4a5580 fffff802`14b78eca : 00000000`00000001 fffffa80`31427a01 00000000`00275f48 fffffa80`437f7000 : nt!KeUpdateTime+0x2ec

fffff880`0c4a5760 fffff802`1445d00e : 0000009f`6bc998e4 ffff7af7`41437906 fffff802`14ba2580 00001f80`004a0260 : hal!HalpTimerClockInterrupt+0x86

fffff880`0c4a5790 fffff802`14b740ba : fffffa80`437f70b8 00000000`00010008 00000000`0000e39d fffff802`14b96e80 : nt!KiInterruptDispatchLBControl+0x1ce

fffff880`0c4a5920 fffff880`00d79c88 : 00000000`00000001 00000000`00000001 fffff802`14b96e80 00000000`00000001 : hal!HalpTimerStallExecutionProcessor+0x10b

fffff880`0c4a59b0 fffff880`00d787f8 : 00000000`00000001 fffff802`14b96e80 00000000`00000700 fffff802`1456a72d : PSHED!PshedpWaitForOperationToComplete+0x1c

fffff880`0c4a59e0 fffff880`00d77539 : fffffa80`00000609 fffff802`14b96e80 fffffa80`321fb950 fffffa80`437f7010 : PSHED!PshedpWriteErrorRecordERST+0x89

fffff880`0c4a5a10 fffff802`1456ac60 : 00000000`00000001 00000000`00000000 00000000`00000000 fffffa80`437f7038 : PSHED!PshedWriteErrorRecord+0x71

fffff880`0c4a5a40 fffff802`14b83703 : fffff880`00000728 00000000`00000000 fffff880`0c4a5ba0 fffff802`14b96e80 : nt!WheaReportHwError+0x200

fffff880`0c4a5aa0 fffff802`14b831f3 : 00000000`00000001 00000000`00000000 fffff880`0c4a5c50 00000000`00000000 : hal!HalpMcaReportError+0x53

fffff880`0c4a5c00 fffff802`14bb0485 : 00000000`00000002 00000000`00000000 00000000`00000000 00000000`00000000 : hal!HalpCmcPollProcessor+0x73

fffff880`0c4a5c50 fffff802`144a22b1 : fffff802`14690110 fffffa80`3316b700 fffff802`14bb03f0 fffff802`1446dc00 : hal!HalpCmcWorkerRoutine+0x95

fffff880`0c4a5cc0 fffff802`14437045 : fffff880`0c4a5ec0 00000000`00000080 fffff802`144a2170 fffffa80`3316b700 : nt!ExpWorkerThread+0x142

fffff880`0c4a5d50 fffff802`144eb766 : fffff880`02a47180 fffffa80`3316b700 fffff880`02a53d40 fffffa80`310ba980 : nt!PspSystemThreadStartup+0x59

fffff880`0c4a5da0 00000000`00000000 : fffff880`0c4a6000 fffff880`0c4a0000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x16

감사합니다.

이미 EOS 된 Windows 2003 이 자꾸 Cash 된다고 하여 덤프 분석을 진행해 봤습니다.

제일 먼저 실행해야 할 !analyze -v를 실행해 보았습니다.

BugCheck 0x7E 라는 코드인데 시스템의 중요 스레드에서 Exception이 발생했는데 처리하지 못해서 시스템이 크래시 된 것 입니다.

3: kd> !analyze -v

*******************************************************************************

*                                                                             *

*                        Bugcheck Analysis                                    *

*                                                                             *

*******************************************************************************

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)

This is a very common bugcheck.  Usually the exception address pinpoints

the driver/function that caused the problem.  Always note this address

as well as the link date of the driver/image that contains this address.

Arguments:

Arg1: ffffffffc0000005, The exception code that was not handled

Arg2: fffffadf26a2ce30, The address that the exception occurred at

Arg3: fffffadf27925950, Exception Record Address

Arg4: fffffadf27925360, Context Record Address

Exception record를 확인하니 srv 라는 네트워크 드라이버를 담당하는 드라이버에서 Access Violation 오류가 발생한 것을 확인할 수 있습니다.

EXCEPTION_RECORD:  fffffadf27925950 -- (.exr 0xfffffadf27925950)

ExceptionAddress: fffffadf26a2ce30 (srv!memmove+0x0000000000000064)

   ExceptionCode: c0000005 (Access violation)

  ExceptionFlags: 00000000

NumberParameters: 2

   Parameter[0]: 0000000000000001

   Parameter[1]: 0000000100089458

Attempt to write to address 0000000100089458

아래의 .cxr 을 클릭하면 오류가 발생한 코드로 이동을 합니다.

CONTEXT:  fffffadf27925360 -- ( .cxr 0xfffffadf27925360 )

rax=00000000000893f0 rbx=fffffadf36263958 rcx=0000000100089458

rdx=fffffade3720f0f0 rsi=fffffadf3734cb20 rdi=00000000000893f0

rip=fffffadf26a2ce30 rsp=fffffadf27925b78 rbp=0000000000000000

 r8=0000000000000018  r9=0000000000000003 r10=0000000000000012

r11=0000000100089458 r12=0000000000000000 r13=0000000000000018

r14=00000000ffffff84 r15=0000000000000000

iopl=0         nv up ei pl nz na po nc

cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00010206

srv!memmove+0x64:

fffffadf`26a2ce30 488901          mov     qword ptr [rcx],rax ds:002b:00000001`00089458=????????????????

Resetting default scope

오류가 발생한 코드로 이동을 해보니 rcx 레지스터에 잘못된 값이 들어 있어서 문제가 발생한 것입니다. [rcx] 는 rcx 의 값에 해당하는 주소에 접근한다는 의미 입니다.

3: kd> .cxr 0xfffffadf27925360

rax=00000000000893f0 rbx=fffffadf36263958 rcx=0000000100089458

rdx=fffffade3720f0f0 rsi=fffffadf3734cb20 rdi=00000000000893f0

rip=fffffadf26a2ce30 rsp=fffffadf27925b78 rbp=0000000000000000

 r8=0000000000000018  r9=0000000000000003 r10=0000000000000012

r11=0000000100089458 r12=0000000000000000 r13=0000000000000018

r14=00000000ffffff84 r15=0000000000000000

iopl=0         nv up ei pl nz na po nc

cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00010206

srv!memmove+0x64:

fffffadf`26a2ce30 488901          mov     qword ptr [rcx],rax ds:002b:00000001`00089458=????????????????

콜스택을 확인해보니 다른 드라이버 모듈은 안 보이고 SRV만 보입니다. 아마도 네트워크 드라이브에 대한 요청을 받은 후 네트워크 요청을 처리하던 중으로 보입니다.

3: kd> k

  *** Stack trace for last set context - .thread/.cxr resets it

 # Child-SP          RetAddr           Call Site

00 fffffadf`27925b78 fffffadf`26ae24c9 srv!memmove+0x64

01 fffffadf`27925b80 fffffadf`26a2c8f7 srv!SrvSmbNtTransactionSecondary+0x3e9

02 fffffadf`27925c40 fffffadf`26a2c853 srv!SrvProcessSmb+0x19f

03 fffffadf`27925ca0 fffffadf`26a8d0f2 srv!SrvRestartReceive+0xca

04 fffffadf`27925d10 fffff800`0124f932 srv!WorkerThread+0x144

05 fffffadf`27925d70 fffff800`01020556 nt!PspSystemThreadStartup+0x3e

06 fffffadf`27925dd0 00000000`00000000 nt!KiStartSystemThread+0x16

어떤 시스템 중요 프로세스인지 확인해 봅니다.

3: kd> !process -1 0

PROCESS fffffadf38bf85a0

    SessionId: none  Cid: 0004    Peb: 00000000  ParentCid: 0000

    DirBase: 23be01000  ObjectTable: fffffa8000001bd0  HandleCount: 2717.

    Image: System

어셈블리로 분석을 해 보았지만 특이한 점이 확인되지 않아서 SrvSmbNtTransactionSecondary 함수를 인터넷에서 검색해 봅니다.

DELL 문서에서 KB2696547에 해당하는 이슈라고 확인됩니다.

Stop Code 0x50 srv.sys caused by EternalBlue Exploit

https://www.dell.com/support/article/kr/ko/krdhs1/sln306200/stop-code-0x50-srvsys-caused-by-eternalblue-exploit?lang=en

Microsoft released a Security Bulletin regarding SMBv1.0. External Link The most severe of the vulnerabilities could allow remote code execution if an attacker sends specially crafted messages to a Microsoft Server Message Block 1.0 (SMBv1) server.

You can identify that this issue is occuring by analyzing the Stack on the Memory Dump and finding this specific lines:

ffffd001`078b0700 fffff801`71252360 nt!KiPageFault+0x12f

ffffd001`078b0890 fffff801`712522a5 srv!SrvOs2FeaToNt+0x48

ffffd001`078b08c0 fffff801`7127369b srv!SrvOs2FeaListToNt+0x125

ffffd001`078b0910 fffff801`7127c8ba srv!SrvSmbOpen2+0xc3

ffffd001`078b09b0 fffff801`7127fb2e srv!ExecuteTransaction+0x2ca

ffffd001`078b09f0 fffff801`7120d84f srv!SrvSmbTransactionSecondary+0x40b

ffffd001`078b0a90 fffff801`7120da20 srv!SrvProcessSmb+0x237

ffffd001`078b0b10 fffff801`7124cac8 srv!SrvRestartReceive+0x114

ffffd001`078b0b50 fffff800`13591306 srv!WorkerThread+0x5248

ffffd001`078b0bd0 fffff800`1317f280 nt!IopThreadStart+0x26

ffffd001`078b0c00 fffff800`131d89c6 nt!PspSystemThreadStartup+0x58

ffffd001`078b0c60 00000000`00000000 nt!KiStartSystemThread+0x16

좀더 검색을 해보니 MS SMB 취역점인 MS17-010을 분석한 문서가 보입니다. 아마도 MS17-010 취약점에 대한 공격이 들어왔는데 srv 드라이버가 이를 잘 처리하지 못해서 시스템이 크래시 된 것으로 보입니다.

https://github.com/nixawk/labs/issues/9

===============

Bug5: Transaction secondary request is accepted and processed after transaction execution is started

===============

If we send a transaction secondary request to a transaction that AllDataReceived member has already been set, a server will

send back an error without processing the request.

For multipiece transaction, AllDataReceived is set (in SrvSmbTransactionSecondary()/SrvSmbNtTransactionSecondary()) before

executing transaction. But AllDataReceived is NOT set (in SrvSmbTransaction()/SrvSmbNtTransaction()) when transaction is

completed in 1 SMB message. This allow us to send a transaction secondary request to modify InParamter/InData buffer and

ParameterCount/DataCount while server is executing a transaction or sending a reply.

Windows Server 2003은 이미 EOS 되어 보안 취약점에 대해서도 패치를 제공하지 않은 상태입니다. 하지만 SMB 취약점은 영향도가 커서 특별히 패지가 만들어져 있습니다. 혹시 아직 Windows 2003을 운영하고 계신다면 꼭 아래 패치를 설치해주세요

Security Update for Windows Server 2003 (KB4012598)

https://www.microsoft.com/en-us/download/details.aspx?id=55248

감사합니다.

ESXi의 패치를 설치하고 제거하는 방법과 Windows (Hyper-V)는 어떻게 다른지 확인해 보았습니다.

-------------------------------------------------------- ESXi -----------------------------------------------------------

1. ESXi 의 Build number 확인 합니다.

2. https://kb.vmware.com/articleview?docid=2143832&lang=en_US 에서 설치할 Build number 확인 합니다.

  현재 설치된 ESXi 는 10302608로 ESXi 6.7 U1 이고 상위 버전인 Build number 10764712를 설치할 것입니다.

  ESXi 에서 같은 버전에서는 Build number가 더 높은 것이 상위 버전 입니다. 6.7 U1 보다 EP 05가 Build number가 더 높으니 상위 버전 입니다.

  6.5 P03의 Build number가 더 높다고 하실 수 있는데 Build number로 구분하는 것은 같은 버전에서만 해당 됩니다. (ESXi는 누적패치 입니다.)

3. https://my.vmware.com/group/vmware/patch#search 를 연 후 VMware에 로그온 합니다.

  Product을 ESXi 그리고 버전을 6.7로 맞춘 후 Build number 10764712 로 검색을 하면 아래와 같이 다운로드 가능한 경로가 나옵니다.

4. ESXi host client로 접속을 한 후 스토리지 -> 적절한 데이터스토어 선택 -> 데이터스토어 브라우저 -> Patch 디렉토리 생성 -> 업로드 클릭하여 Patch 업로드

5. 아래 명령을 실행해서 ESXi 를 Maintenance mode로 변경 합니다.

# vim-cmd hostsvc/maintenance_mode_enter 

6. 패치 파일이 있는 데이터스토어로 이동해서 패치 파일이 잘 업로드 되었는지 확인 합니다.

7. 다음 명령을 실행해서 패치를 설치 하고 재부팅을 합니다. (Host Client로 접속을 해 보면 Build number가 바뀐 것을 알 수 있습니다.)

  esxcli software vib update -d "/vmfs/volumes/5c1daaa4-d1f39d97-acc4-000c29d43d4f/patch/ESXi670-201811001.zip" 

8. 아래 명령을 실행해서 Maintenance mode에서 빠져 나옵니다.

  vim-cmd /hostsvc/maintenance_mode_exit

9. Patch 에 문제가 있어서 이전으로 돌아가려면 ESXi를 재부팅 하면서 부팅 화면에서 Shift+R을 누른 후 Y 를 눌러서 Patch 설치 이전 커널로 돌아갈 수 있습니다. 이전 버전이 아니고 더 예전으로 돌아하는 방법은 해당 버전의 해치를 설치해 주면 된다고 들었는데 관련 자료를 아직 찾지 못했습니다.

<추가>

패치에 어떤 내용이 수정되었는지 확인 하려면 설치 하려는 패치의 정보를 아래 웹 사이트에서 선택을 합니다.

https://esxi-patches.v-front.de/

이 사이트에서는 아래와 같이 VMware의 공식 사이트로 링크되어 있어 어떤 수정이 있었는지 확인할 수 있습니다.

https://docs.vmware.com/en/VMware-vSphere/6.7/rn/esxi670-201811001.html

<참고>

How to download patches in MyVMware (1021623)

https://kb.vmware.com/s/article/1021623

Build numbers and versions of VMware ESXi/ESX (2143832)

https://kb.vmware.com/articleview?docid=2143832&lang=en_US

“esxcli software vib” commands to patch an ESXi 5.x/6.x host (2008939)

https://kb.vmware.com/s/article/2008939

esxcli software profile or esxcli software vib?

http://byounghee.me/2017/04/28/esxcli-software-profile-or-esxcli-software-vib/

Reverting to a previous version of ESXi (1033604)

https://kb.vmware.com/s/article/1033604

-------------------------------------------------------- Windows -----------------------------------------------------------

1. 현재 설치된 버전을 확인 합니다.

  CMD를 사용할 경우는 Systeminfo 를 사용하고 GUI라면 Winver를 사용하면 됩니다.

2. 아래 웹 페이지에서 17134 Build와 관련된 version이 무엇인지 확인 합니다. 17134 Build 는 Windows 10 1803 빌드라는 것을 확인할 수 있습니다.

  (Windows 10 1607은 Windows Server 2016 이고 Windows 10 1809는 Windows Server 2019 입니다.)

  https://docs.microsoft.com/en-us/windows/windows-10/release-information

3. 아래 웹 페이지에서 설치해야 할 패치를 선택 합니다. December 19, 2018이 가장 최신 패치 입니다. (최신 Windows는 누적 패치 입니다.)

  Windows 10 version 1803을 선택 한 후 

  https://support.microsoft.com/en-us/help/4099479/windows-10-update-history

설치할 패치를 선택하면 어떤 수정이 있었는지 확인 가능 합니다.

4. 인터넷에 Windows가 연결되어 있다면 Windows update를 통해서 설치 할 수 있겠지만 오프라인으로 설치 하려면 Windows update 카탈로그를 통해 다운 받아야 합니다.

  http://www.catalog.update.microsoft.com/home.aspx

5. 설치 방법은 다운로드한 .msu 파일을 아래와 같은 명령으로 설치 하면 됩니다.

  wusa windows10.0-kb4471324-x64_delta_ffcf11ca79d79a6fc03aca53c7a00e6106d66f07.msu /quiet /nostart

6. 설치된 결과는 wmic qfe 명령으로 확인 가능 합니다.

<참고>

설치된 KB는 아래 명령으로 삭제할 수 있습니다.

wusa.exe /quiet /uninstall /kb:1212121 /promptrestart

Windows의 Windows Update 독립 실행형 설치 프로그램에 대한 설명

https://support.microsoft.com/ko-kr/help/934307/description-of-the-windows-update-standalone-installer-in-windows

Windows 소프트웨어 업데이트 패키지의 명령줄 스위치

https://support.microsoft.com/ko-kr/help/262841/command-line-switches-for-windows-software-update-packages

오늘은 디스크 공간을 다 써버리는 문제에 대해서 살펴 보도록 하겠습니다.

윈도우, 리눅스 등의 운영체제에서 디스크 공간을 다 써버려서 특정 애플리케이션이 오동작 하거나 시스템 파티션의 공간이 부족해져서 시스템이 멈추는 현상을 본 적이 있을 것 입니다. 윈도우, 리눅스 모두 디스크 공간을 확인하는 방법이 있는데 아무래도 리눅스 쪽이 좀 더 강력합니다.

-------------------------------------------------------- Linux -----------------------------------------------------------
리눅스 에서는 마운트 되어 있는 모든 파티션의 크기, 사용 중인 공간, 사용 가능한 공간을 df 명령을 통해서 확인할 수 있습니다.

출력 결과를 보면 바로 디스크 공간이 얼마나 남아 있는지 확인할 수 있습니다. 그런데 /dev/sda2를 보면 전체 크기 20G에서 사용량 4G를 빼면 16G가 나와야 할 것 같은데 15G가 나오는 것을 확인할 수 있습니다. 리눅스가 긴급 상황을 위해서 Reserved block을 따로 만들어 놓는다고 합니다. (tune2fs 명령을 사용해서 Reserved block의 크기를 확인할 수 있습니다.)

Red hat 문서를 보면 Reserved block을 5% 할당하게 되어 있는데 파일 시스템이 큰 경우 이 크기를 줄일 수 있다고 합니다.

https://access.redhat.com/solutions/1189733

디스크 공간이 많이 사용된 것을 확인했으먼 어떤 디렉토리가 많이 사용하고 있는지 확인해야 합니다. 이 때 사용할 수 있는 명령이 du 입니다.

일반적으로 많이 발생하지는 않지만 df 명령을 실행했을때 충분한 디스크 공간이 있는데 공간이 부족하다는 오류가 발생하는 경우 입니다. 이 경우에는 inode가 고갈되었는지 확인해봐야 합니다. inode의 사용률은 df -i 명령을 통해서 확인할 수 있습니다. /dev/sda2 파티션은 1,310,720 개의 inode가 있고 그중 109,878 개가 사용되었습니다.

inode가 부족한 현상이 발생하면 해당 파티션의 파일을 지우는 작업을 통해서 inode를 확보할 수 있으며 문제 해결을 위해서는 inode가 충분히 할당되도록 파일 시스템을 새로 만들어야 합니다.

https://access.redhat.com/solutions/641333

리눅스는 부팅 시점에 자동으로 파일 시스템 체크 명령인 fsck를 실행 합니다. 파일시스템이 손상된 경우 해당 파이션을 umount 한 후 fsck 명령으로 조치를 취합니다.

-------------------------------------------------------- Windows --------------------------------------------------------

Windows 에서는 df 명령이 없고 GUI를 사용하거나 WMI를 사용해서 Win32_logicaldisk의 정보를 확인해야 합니다. WMI는 WMIC 라는 명령을 사용해서 확인할 수도 있고 PowerShell을 사용할 수도 있습니다. 안타깝게도 Windows 에서는 사용률을 %로 보여주지는 않습니다.

디스크 공간이 많이 사용되었을 때 du 명령을 사용하여 어떤 디렉토리나 파일이 공간을 차지하는지 확인할 수 있는데 Windows에 기본 명령에는 du가 없고 sysinternals에서 du 를 다운 받아야 합니다.

https://docs.microsoft.com/en-us/sysinternals/downloads/du

sysinternals의 du 는 리눅스의 du 와는 다르게 동작하고 리눅스에 있는 sort, tail 등의 명령이 Windows에는 없기 때문에 PowerShell을 사용해서 비슷하게 만들어 보았습니다. (du 에서 배너를 없애는 -q 를 사용했지만 배너가 출력되고 있습니다. )

Windows 에서 Disk 공간이 부족할 때 확인해봐야 할 것은 2가지가 있습니다. 첫째 백업을 위해 사용되는 새도 복사본 저장소의 사용률 입니다. 새도 복사본은 각 디스크에 "System Volume Information" 이라는 디렉토리 아래에 있는데 이 디렉토리는 System 만 접근할 수 있게 설정되어 있어 du가 크기를 확인할 수 없습니다. (vssadmin 명령으로 사용량을 확인해야 합니다.), 둘째 du를 사용하는 계정이 접근할 수 없는 디렉토리 (Admin도 사용자 전용으로 설정된 디렉토리에 접근할 수 없습니다.) 또는 디렉토리 또는 파일이 배타적인 접근 속성을 가지고 있는 경우 크기를 확인할 수 없습니다.

Windows 에서 사용하는 NTFS에는 inode와 같은 개념이 없고 최대 4,294,967,295 개까지 파일, 디렉토리를 만들 수 있습니다.

http://www.ntfs.com/ntfs_vs_fat.htm

Windows에서도 부트 시점에 autochk 가 실행되어 손상된 파일 시스템을 치료할 수 있습니다. 그리고 chkdsk 명령을 사용해서 볼륨를 검사 및 오류를 수정할 수 있습니다. /F 옵션을 사용해서 오류를 수정하려고 할 경우 볼륨을 분리 한 후 실행할 수 있습니다. 

볼륨의 크기가 클 경우 chkdsk를 실행하여 오류를 수정하는데 많은 시간이 걸리는데 Windows 2008 부터 Self-healing, Spot fix 라는 기능이 들어가서 오류가 발생할 경우 바로 fix를 하고 있습니다. (새로운 파일 시스템인 REFS에는 Chkdsk가 필요 없다고 합니다.)

https://blogs.technet.microsoft.com/doxley/2008/10/29/self-healing-ntfs/

https://blogs.msdn.microsoft.com/b8/2012/05/09/redesigning-chkdsk-and-the-new-ntfs-health-model/

감사합니다.

VMware 에서 실행되는 Windows VM이 시스템 행 현상이 있다고 하여 분석을 진행해 보았습니다.

먼저 !vm 명령을 싱행해서 메모리 상태를 확인해 보았는데 별다른 문제가 확인되지 않았습니다.

0: kd> !vm

Page File: \??\C:\pagefile.sys

  Current:   1048576 Kb  Free Space:    807844 Kb

  Minimum:   1048576 Kb  Maximum:     10485500 Kb

Physical Memory:          4194156 (   16776624 Kb)

Available Pages:          3479978 (   13919912 Kb)

ResAvail Pages:           4063051 (   16252204 Kb)

Locked IO Pages:                0 (          0 Kb)

Free System PTEs:      4294989313 (17179957252 Kb)

Modified Pages:             13432 (      53728 Kb)

Modified PF Pages:          12747 (      50988 Kb)

Modified No Write Pages:        0 (          0 Kb)

NonPagedPool    0:             33 (        132 Kb)

NonPagedPoolNx  0:          32181 (     128724 Kb)

NonPagedPool    1:              0 (          0 Kb)

NonPagedPoolNx  1:              0 (          0 Kb)

NonPagedPool Usage:           168 (        672 Kb)

NonPagedPoolNx Usage:       40172 (     160688 Kb)

NonPagedPool Max:      4294967296 (17179869184 Kb)

PagedPool  0:               79908 (     319632 Kb)

PagedPool  1:               51553 (     206212 Kb)

PagedPool  2:                   0 (          0 Kb)

PagedPool Usage:           131461 (     525844 Kb)

PagedPool Maximum:     4160749568 (16642998272 Kb)

Processor Commit:             917 (       3668 Kb)

Session Commit:             16179 (      64716 Kb)

Syspart SharedCommit 0

Shared Commit:              51347 (     205388 Kb)

Special Pool:                   0 (          0 Kb)

Kernel Stacks:               8889 (      35556 Kb)

Pages For MDLs:               342 (       1368 Kb)

Pages For AWE:                  0 (          0 Kb)

NonPagedPool Commit:        38599 (     154396 Kb)

PagedPool Commit:          131461 (     525844 Kb)

Driver Commit:               9397 (      37588 Kb)

Boot Commit:                50253 (     201012 Kb)

System PageTables:            997 (       3988 Kb)

VAD/PageTable Bitmaps:       6871 (      27484 Kb)

ProcessLockedFilePages:        12 (         48 Kb)

Pagefile Hash Pages:          206 (        824 Kb)

Sum System Commit:         315470 (    1261880 Kb)

Total Private:             473164 (    1892656 Kb)

Misc/Transient Commit:       4291 (      17164 Kb)

Committed pages:           792925 (    3171700 Kb)

Commit limit:             4456300 (   17825200 Kb)

커널에서 동기화 객체를 기다리는 것이 있는지 확인해 보았지만 없었습니다.

0: kd> !locks

**** DUMP OF ALL RESOURCE OBJECTS ****

KD: Scanning for held locks.........

89274 total locks

그렇다면 CPU가 바빠서 발생하는 이슈일지 모른다고 생각해서 CPU의 상태를 확인해보았으니 IDLE 상태 였습니다.

0: kd> !cpuinfo

CP  F/M/S Manufacturer  MHz PRCB Signature    MSR 8B Signature Features

 0  6,79,1 GenuineIntel 2295 0b00002a00000000                   311b3fff

 1  6,79,1 GenuineIntel 2295 0b00002a00000000                   311b3fff

 2  6,79,1 GenuineIntel 2295 0b00002a00000000                   311b3fff

 3  6,79,1 GenuineIntel 2295 0b00002a00000000                   311b3fff

                      Cached Update Signature 0b00002a00000000

                     Initial Update Signature 0b00002a00000000

0: kd> !running

Process PID Thread           Id Pri Base Pri Next CPU CSwitches User          Kernel State              Time Reason

======= === ================ == === ======== ======== ========= ==== =============== ======= =============== ==============

Idle      0 fffff8035d3d5940  0   0        0        0  24448367    0   23h:56:06.250 Running 1d.00:48:53.796 Executive

Idle      0 ffffdf005f631000  0   0        0        1  20088217    0   23h:48:42.703 Running          3s.984 WrCalloutStack

Idle      0 ffffdf005f6b9000  0   0        0        2  18610602    0   23h:58:19.172 Running 1d.00:48:53.796 Executive

Idle      0 ffffdf005f741000  0   0        0        3  25365439    0 1d.00:00:03.219 Running 1d.00:48:53.796 Executive

Count: 4 | Show Unique Stacks

0: kd> !mex.us -cpu

4 threads: ffffdf005f6b9000 ffffdf005f741000 fffff8035d3d5940 ffffdf005f631000

    fffff8035d223ff1 nt!PpmIdleGuestExecute+0x15

    fffff8035d109eac nt!PpmIdleExecuteTransition+0xcbc

    fffff8035d10903a nt!PoIdle+0x33a

    fffff8035d17afac nt!KiIdleLoop+0x2c

1 stack(s) with 4 threads displayed (4 Total threads)

lpc의 상태를 확인해보니 svchost.exe가 explorer에 lpc message를 보내고 기다리는 것이 확인 됩니다.

0: kd> !lpcwait

Server Process ffffab06`b8137800  Connection Port ffffab06`b853c540  (\Device\HarddiskVolume1\Windows\explorer.exe)

    Client Thread        Client Wait Time     Client Message       Server Thread   

    =================    =================    =================    =================

    ffffab06`b1b28800           1:25.406      ffffce0e`5b04dcf0                                                          (\Device\HarddiskVolume1\Windows\System32\svchost.exe)

    1 thread waiting

svchost.exe의 Thread를 확인해보니 logoff를 처리하던 것으로 보입니다.

0: kd> kc

  *** Stack trace for last set context - .thread/.cxr resets it

 # Call Site

00 nt!KiSwapContext

01 nt!KiSwapThread

02 nt!KiCommitThreadWait

03 nt!KeWaitForSingleObject

04 nt!AlpcpSignalAndWait

05 nt!AlpcpReceiveSynchronousReply

06 nt!AlpcpProcessSynchronousRequest

07 nt!NtAlpcSendWaitReceivePort

08 nt!KiSystemServiceCopyEnd

09 ntdll!NtAlpcSendWaitReceivePort

0a RPCRT4!LRPC_BASE_CCALL::DoSendReceive

0b RPCRT4!I_RpcSendReceive

0c combase!CMessageCall::CallI_RpcSendReceive

0d combase!ThreadSendReceive

0e combase!CSyncClientCall::SwitchAptAndDispatchCall

0f combase!CSyncClientCall::SendReceive2

10 combase!SyncClientCallRetryContext::SendReceiveWithRetry

11 combase!CSyncClientCall::SendReceiveInRetryContext

12 combase!DefaultSendReceive

13 combase!CSyncClientCall::SendReceive

14 combase!CClientChannel::SendReceive

15 combase!NdrExtpProxySendReceive

16 RPCRT4!NdrpClientCall3

17 combase!ObjectStublessClient

18 combase!ObjectStubless

19 combase!RemoteReleaseRifRefHelper

1a combase!RemoteReleaseRifRef

1b combase!CStdMarshal::DisconnectCliIPIDs

1c combase!CStdMarshal::Disconnect

1d combase!CStdIdentity::{dtor}

1e combase!CStdIdentity::CInternalUnk::Release

1f netprofmsvc!ATL::IConnectionPointImpl<CImplINetworkListManager,&IID_INotifyNetworkGlobalCostEvents,ATL::CComDynamicUnkArray>::Unadvise

20 netprofmsvc!CImplINetworkListManager::UnadviseAndRemoveSessionCookie<&IID_INotifyNetworkGlobalCostEvents>

21 netprofmsvc!CImplINetworkListManager::PurgeClients

22 netprofmsvc!EnterPurgeClientsCallback

23 combase!EnterForCallback

24 combase!SwitchForCallback

25 combase!PerformCallback

26 combase!CObjectContext::InternalContextCallback

27 combase!CObjectContext::ContextCallback

28 combase!CContextSwitcher::ContextCallback

29 netprofmsvc!NetProfileManUserLogOff

2a ntdll!TppSimplepExecuteCallback

2b ntdll!TppWorkerThread

2c KERNEL32!BaseThreadInitThunk

2d ntdll!RtlUserThreadStart

Explorer는 파일을 닫는 중이었는데 백신 프로그램의 필터 드라이버인 TmXPFlt가 IO가 더 진행되지 못하게 막고 있었습니다.

0: kd> !us -p ffffab06b8137800

1 thread [stats]: ffffab06b8121080

    fffff8035d17e576 nt!KiSwapContext+0x76

    fffff8035d0d74fd nt!KiSwapThread+0x17d

    fffff8035d0d6f9f nt!KiCommitThreadWait+0x14f

    fffff8035d0d8d77 nt!KeWaitForSingleObject+0x377

    fffff8022e82bce3 TmXPFlt+0x1bce3

    fffff8022e814884 TmXPFlt+0x4884

    fffff8022e814d65 TmXPFlt+0x4d65

    fffff8022e814f65 TmXPFlt+0x4f65

    fffff8022e4b3f8d TmPreFlt!TmpQueryFullName+0x1e85

    fffff8022e4b40d8 TmPreFlt!TmpQueryFullName+0x1fd0

    fffff8022c603d15 FLTMGR!FltpPerformPostCallbacks+0x2a5

    fffff8022c603756 FLTMGR!FltpPassThroughCompletionWorker+0x76

    fffff8022c605299 FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x239

    fffff8022c603146 FLTMGR!FltpDispatch+0xb6

    fffff8035d4e75a0 nt!IopCloseFile+0x150

    fffff8035d5142c5 nt!ObCloseHandleTableEntry+0x245

    fffff8035d43098b nt!NtClose+0xcb

    fffff8035d187503 nt!KiSystemServiceCopyEnd+0x13

    00007ffe863c5ce4 ntdll!NtClose+0x14

    00007ffe83335aa2 KERNELBASE!CloseHandle+0x62

    00007ffe82f02560 SHCORE!CGenericFileHandle::Release+0x160

    00007ffe82f02082 SHCORE!CFileStream::~CFileStream+0xd2

    00007ffe82f00d35 SHCORE!CFileStream::Release+0x35

    00007ffe84b0d273 SHELL32!IconCacheSave+0x18965b

    00007ffe84983a05 SHELL32!SHDesktopMessageLoop+0x45

    00007ff694781468 Explorer!wWinMain+0x714

    00007ff694810727 Explorer!__wmainCRTStartup+0x1c7

    00007ffe83ce8364 KERNEL32!BaseThreadInitThunk+0x14

    00007ffe8638e851 ntdll!RtlUserThreadStart+0x21

1 stack(s) with 1 threads displayed (1 Total threads)