Platform Engineer

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)