VMware 의 NAT 설정과 패킷캡쳐시 promiscuous 모드 설정

VMware 의 NAT 기능을 이용하면서 네트워크 설정에 문제를 겪는 분들이 있어 내용을 공유하고자 한다. NAT 설정을 있는 그대로 사용하면 크게 문제는 발생하지 않는데, 자체적으로 IP 를 설정하는 경우 네트워크 통신이 안되는 경우가 발생한다. 이런 경우는 가상 머신에 설정된 IP 대역과 호스트쪽 네트워크 인터페이스 내용이 일치 하지 않아 나타나는 경우가 많다. 즉, 가상머신 IP 는 바꾸었지만 호스트쪽은 이전에 설정된 내용 그대로 이용하면서 네트워크가 안되는 경우다.

리눅스 사용자라면 다음의 경로로 들어가 보자. 윈도우 사용자도 리눅스 경우와 크게 다르지 않다. (가상 머신에 설정된 IP 와 호스트에서 이용하는 NAT 어뎁터를 살펴보자)

# cd /etc/vmware

# ls -l
total 24
-rw-r--r-- 1 root root  226 2012-08-23 10:44 bootstrap
-rw-r--r-- 1 root root  526 2012-08-24 09:50 config
lrwxrwxrwx 1 root root   19 2012-08-23 10:44 icu -> /usr/lib/vmware/icu
lrwxrwxrwx 1 root root   56 2012-08-23 10:45 installer.sh -> /usr/lib/vmware-installer/2.0/vmware-uninstall-downgrade
-rw-r--r-- 1 root root   54 2012-08-23 10:45 locations
-rw-r--r-- 1 root root  462 2012-08-23 11:37 networking
drwxr-xr-x 3 root root 4096 2012-08-23 10:44 vmnet1
drwxr-xr-x 4 root root 4096 2012-08-23 10:44 vmnet8

vmnet8 이 보일 것이고 바로 기본 설정되는 이 vmnet8 이 NAT 로 이용되는 인터페이스 이다.
# cd vmnet8 

# ls -l

total 12

drwxr-xr-x 2 root root 4096 2012-08-24 11:00 dhcpd

drwxr-xr-x 2 root root 4096 2012-08-23 11:39 nat

-rw-r--r-- 1 root root   18 2012-08-24 11:10 nat.mac

nat 설정파일을 한번 들여다 보자.

# more nat

# VMware NAT configuration file

[host]

# NAT gateway address
ip = 192.168.70.1
netmask = 255.255.255.0

# VMnet device if not specified on command line
device = /dev/vmnet8

NAT gateway 주소 설정이 보인다. 여기에 설정된 IP 는 다를 것이고, 본인이 원하는 특정 IP 주소를 (여기서는 192.168.70.X 대역 이용) 기록해 주면 된다. 설정파일을 변경한다고 바로 적용되지는 않는다. VMware 네트워크를 재 시작해 주거나 또는  ifconfig 를 통해 vmnet8 의 IP 를 주소를 바꿔주면 된다. 다음은 ifconfig 로 IP 를 변경하고 ifconfig 로 살펴본 내용으로 vmnet8 의 주소가 192.168.70.1 이 되었다. 가상머신에서 192.168.70.X 로 설정하고 게이트웨이 주소를 192.168.70.1 로 잡아주면 네트워크는 잘 될 것이다.

# ifconfig vmnet8

vmnet8    Link encap:Ethernet  HWaddr 00:50:56:c0:xx:xx

          inet addr:192.168.70.1  Bcast:192.168.70.255  Mask:255.255.255.0

          inet6 addr: fe80::250:56ff:fexx:x/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:235 errors:0 dropped:0 overruns:0 frame:0

          TX packets:100 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000 

          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

가상머신에서 와이어샤크를 이용해 패킷 덤프를 하는 경우 아래 그림과 같은 메시지가 나타날 수 있다. 보안상의 이유로 이더넷 인터페이스에 promiscuous 모드를 설정할 수 없다는 것이다.

이에 대한 해결책으로는 해당 디바이스의 퍼미션을 변경해 주면 된다.

# ls -l /dev/vmne*
crw------- 1 root root 119, 0 2012-08-24 10:13 /dev/vmnet0
crw------- 1 root root 119, 1 2012-08-24 10:13 /dev/vmnet1
crw------- 1 root root 119, 8 2012-08-24 10:13 /dev/vmnet8

/dev 밑에 vmnet* 이라는 문자열들을 볼 수 있고, NAT 에서 사용하는 /dev/vmnet8 에 rw 퍼미션을 추가해 주면 된다.

# chmod a+rw /dev/vmnet8
# ls -l /dev/vmne*
crw------- 1 root root 119, 0 2012-08-24 10:13 /dev/vmnet0
crw------- 1 root root 119, 1 2012-08-24 10:13 /dev/vmnet1
crw-rw-rw- 1 root root 119, 8 2012-08-24 10:13 /dev/vmnet8

rw 퍼미션이 추가된 후에는 패킷캡쳐 동작시 위와 같은 메시지는 다시 나타나지 않는다.

[참고]
1. Using Virtual Ethernet Adapters in Promiscuous Mode on a Linux Host
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=287

VMware Workstation 설치 컴파일 오류(SPIN_LOCK_UNLOCKED)

VMware 7.1.4 리눅스 버전을 설치하면서 발생하는 에러에 대해 공유하고자 한다. VMware Workstation 최신 버전은 9 이다. 그러나, 정식적으로 사용 가능한 라이센스는 7 버전을 보유하고 있기에 7.1.4 를 설치하였다. (물론, 많은 경우는 무료로 사용 가능한 VirtualBox 를 사용하지만..)

설치하는 도중에 아래 그림과 같이 Error 메시지를 출력한다.

자세한 에러 메시지를 보면

"Unable to build kernel module.
See log file /tmp/vmware-root/setup-29550.log for details"

와 같았다. 로그파일을 살펴보면 특정 파일을 컴파일 하는 과정에서 발생하는 것이고, 이것을 수동으로 컴파일 해보면 다음과 같은 과정이다.

root@:/tmp/vmware-root# /usr/bin/make -C /tmp/vmware-root/modules/vmmon-only auto-build SUPPORT_SMP=1 HEADER_DIR=/lib/modules/3.0.0-22-generic/build/include CC=/usr/bin/gcc GREP=/usr/bin/make IS_GCC_3=no VMCCVER=4.6.1
Using 2.6.x kernel build system.
make: Entering directory `/tmp/vmware-root/modules/vmmon-only'
make -C /lib/modules/3.0.0-22-generic/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. \
 MODULEBUILDDIR= modules
make[1]: Entering directory `/usr/src/linux-headers-3.0.0-22-generic'
  CC [M]  /tmp/vmware-root/modules/vmmon-only/linux/driver.o
/tmp/vmware-root/modules/vmmon-only/linux/driver.c:783:59: error: ‘SPIN_LOCK_UNLOCKED’ undeclared here (not in a function)
make[2]: *** [/tmp/vmware-root/modules/vmmon-only/linux/driver.o] Error 1
make[1]: *** [_module_/tmp/vmware-root/modules/vmmon-only] Error 2
make[1]: Leaving directory `/usr/src/linux-headers-3.0.0-22-generic'
make: *** [vmmon.ko] Error 2
make: Leaving directory `/tmp/vmware-root/modules/vmmon-only'

SPIN_LOCK_UNLOCKED 가 선언되지 않았다고 계속 나타나는 문제였다. 관련 내용을 구글링 해보고 다음 패치파일을 찾을 수 있었다.

패치파일 다운로드 받기 : http://weltall.heliohost.org/wordpress/wp-content/uploads/2011/08/fullvmwarelinux310patch.tar.gz

패치를 실행해 보았다. 그러나 다음과 같은 메시지만 계속 출력된다.

# ./patch-modules_2.6.39.sh
Sorry, this script is only for VMWare WorkStation 7.1.5 or VMWare Player 3.1.5. Exiting

분명 패치파일에는 7.1.4 버전도 분명 명시되어 있었다. 스크립트 파일을 살펴보니

[ "$vmver" == "workstation$vmreqver2" ] && product="VMWare WorkStation"
[ "$vmver" == "player$plreqver2" ] && product="VMWare Player"

와 같이 vmreqver2 를 참고하는 변수가 있지만 실제 스크립트에는 없다. 아래와 같이 스크립트가 변경이 필요하다.

vmreqver=7.1.4
plreqver=3.1.4
vmreqver=7.1.5
plreqver=3.1.5

를 다음과 같이 변경하였다.

vmreqver=7.1.4
plreqver=3.1.4
vmreqver2=7.1.5
plreqver2=3.1.5

그리고 다시 패치 스크립트를 실행하면 깔끔하게 실행이 된다.

# ./patch-modules_2.6.39.sh
patching file vmblock-only/linux/dentry.c
patching file vmblock-only/linux/filesystem.c
patching file vmci-only/linux/driver.c
patching file vmmon-only/linux/driver.c
patching file vmmon-only/linux/hostif.c
patching file vmmon-only/linux/iommu.c
patching file vmnet-only/compat_netdevice.c
.
.
.
Built vsock module
Starting VMware services:
   VMware USB Arbitrator                                               done
   Virtual machine monitor                                             done
   Virtual machine communication interface                             done
   VM communication interface socket family                            done
   Blocking file system                                                done
   Virtual ethernet                                                    done
   Shared Memory Available                                             done


All done, you can now run VMWare WorkStation.
Modules sources backup can be found in the '/usr/lib/vmware/modules/source-workstation7.1.4-2012-10-09-15:04:41-backup' directory


자, 이제 패치가 완료되었으니 VMware 를 다시 재 설치 진행해 주면 에러 발생없이 깨끗하게 설치가 진행된다. 참고로 VMware 7.1.6.744570 버전도 해당 패치를 반영하여 사용이 가능하다. 패치 적용시 후반에 약간의 오류가 있긴 하지만 VMware 를 실행하면 커널 컴파일 하는 GUI 화면에서 제대로 진행이 계속된다.

참고로, VMWare 를 설치한 파일은 "VMware-Workstation-Full-7.1.4-385536.x86_64.bundle" 이며, 커널은 3.0.0-22 이었다. (64비트)

혹시, 같은 에러를 경험할 사용자를 위해 해결책을 공유한다.

VMWare 에서 지정한 스냅샵이 동작하지 않는 경우

VMWare 가상 머신 중 하나가 동작이 이뤄지지 않았다. 에러메시지는 아래와 같았다:

Detected an invalid snapshot configuration

File <unspecified filename>was not found

아무 문제없이 잘 동작하던 가상 머신에 왜 이런일이 나타난 것일까? 콘솔로 로그인 하여 검토하던 중 vmx 파일에서 문제를 발견하였다.

vmx 파일 내용중 가상머신 파일인 vmdk 를 지정한 부분이 있다.

scsi0:0.fileName = "VirtualMachine-000001.vmdk"

실제 존재하는 vmdk 는 000002 였으나, 어찌된 영문인지 000001로 되어 있었다.  000002로 변경하고 가상머신을 동작시키니 정상적으로 동작한다.

무슨 이유에서인지, fileName 에 지정한 vmdk 가 존재하지 않는 것으로 변경이 되어 있었던 것이다.
혹시 위와 같은 메시지를 보게되면 살펴보기 바란다.

VMWare ESX 볼륨 디스크를 변경하는 경우, 이미지 재 설정하기

VMWare ESX 를 사용하는 도중, 마운트된 볼륨 한개의 하드디스크를 교체할 이유가 있었다. 단순한 생각으로는, 새로 들어가는 디스크에 똑같이 그대로 복사해 주면 일단 동작할 수 있지 않을까 생각했다. 새로 다시 이미지를 생성하는 일은 힘들기 때문에 어찌되었든, 기존 이미지를 그대로 유지해야만 했다.

이미지를 카피만 한 후, vSphere 클라이언트에서 확인해 보면 기 존재했던 가상머신 리스트들이
Unknown (inaccessible) 하고 흐릿하게 되어 있었다. 즉, 실행을 시킬 수 없다. 일단,
콘솔로 로긴하여 볼륨을 확인했다.

아래것은 기존에 존재하던 볼륨의 출력화면인데, Storage4 가 교체된 디스크이다.
drwxr-xr-t 1 root root 4060 Dec  2 11:49 4cf5def9-58109560-9ac8-0022196ba845
lrwxr-xr-x 1 root root   35 Dec  6 13:59 Storage1 -> 4bdad755-e0b14358-4a7f-00[삭제]843
lrwxr-xr-x 1 root root   35 Dec  6 13:59 Storage2 -> 4bdfd27b-72617197-994f-00[삭제]845
lrwxr-xr-x 1 root root   35 Dec  6 13:59 Storage3 -> 4bdeccc2-cb8a6f83-4f2a-00[삭제]845
lrwxr-xr-x 1 root root   35 Dec  6 13:59 Storage4 -> 4cf5def9-58109560-9ac8-00[삭제]845

아래와 같이 확인해 보면 새로 구성한 볼륨의 UUID 값이 변경되었다.

# ls -l /vmfs/volumes/
total 4096
drwxr-xr-t 1 root root 5460 Dec  2 19:09 4bdad755-e0b14358-4a7f-00[삭제]843
drwxr-xr-t 1 root root 2940 Dec  6 14:15 4bdeccc2-cb8a6f83-4f2a-00[삭제]845
drwxr-xr-t 1 root root 5740 Dec  2 12:14 4bdfd27b-72617197-994f-00[삭제]845
drwxr-xr-t 1 root root 1120 Dec  6 15:41 4cfc855d-9bad2bdf-bb1b-00[삭제]845
lrwxr-xr-x 1 root root   35 Dec  6 16:11 Storage1 -> 4bdad755-e0b14358-4a7f-0[삭제]843
lrwxr-xr-x 1 root root   35 Dec  6 16:11 Storage2 -> 4bdfd27b-72617197-994f-0[삭제]845
lrwxr-xr-x 1 root root   35 Dec  6 16:11 Storage3 -> 4bdeccc2-cb8a6f83-4f2a-0[삭제]845
lrwxr-xr-x 1 root root   35 Dec  6 16:11 Storage4 -> 4cfc855d-9bad2bdf-bb1b-0[삭제]845

Storage4 번에 있던 이미지들이 제대로 엑세스 할 수 없는 환경임을 추정해 볼 수 있다.
아래 경로의 xml 파일을 확인해 보면, 각 가상머신에 대한 경로가 기록되어 있다.

/etc/vmware/hostd/vmInventory.xml

해당되는 디스크에 속해있던 디스크 UUID 값으로 변경해주고,

  <ConfigEntry id="0084">
    <objID>2864</objID>
    <vmxCfgPath>/vmfs/volumes/4cfc855d-9bad2bdf-bb1b-00[삭제]845/Image110/Image110.vmx</vmxCfgPath>
  </ConfigEntry>

다시 재 반영해 주기 위해 mgmt-vmware 를 통해 재시작을 시켜주었다.

# ./mgmt-vmware restart
Stopping VMware ESX Management services:
   VMware ESX Host Agent Watchdog                          [  OK  ]
   VMware ESX Host Agent                                   [  OK  ]
Starting VMware ESX Management services:
   VMware ESX Host Agent (background)                      [  OK  ]
   Availability report startup (background)                [  OK  ]

이후 vSphere Client 프로그램을 통해 보면 기존에는 접근할 수 없었던 이미지가 이제 접근이 된다. 파워온을 하면 한가지 confirm 을 요청하는 것을 물어보고

OK 를 해주면 이제 정상적으로 동작이 된다. 디스크를 교체하게 되면서, 빠르게 기존 이미지를 그대로 복구할 수 있는 방법을 찾다보니 그냥 이렇게 간단히 문제가 해결될 수 있다.

비슷한 경우를 겪는 분들이라면 참고하길 바란다.

ESXi 4.x 패스워드 길이 조절하기

VMWare ESX 3 버전대에서 패스워드 길이를 짧게 사용하고 있었다면 4.1 에서는 난관에 부딪히게 될 것이다. 보안이 좀더 강화되어, 패스워드를 좀더 복잡하게 사용하여야 하기 때문이다.

짧은 패스워드를 입력하게 되면 아래와 같은 메시지를 보게된다.

Weak password: not enough different characters or classes for this length.

Try again.

패스워드를 안전하게 사용하는 것이 바람직 하지만, 굳이 그렇지 않게 사용되는 시스템도 있다. ESX3 버전대와 마찬가지로 간단하게 패스워드를 이용할 수는 없을까? 물론, 방법은 있다. 다음의 경로를 찾아 파일을 열어보자

/etc/pam.d/system-auth

아래와 같은 내용을 볼 수 있는데, min=8,8,8,7,6 과 같은 부분이 보일것이다. 그렇다 딱 이부분만 봐도 추측이 되지 않는가? 유닉스 시스템을 많이 접해본 사용자라면 이것이 무엇인지는 알 것이다.

#%PAM-1.0

auth       required     /lib/security/$ISA/pam_access.so

auth       required     /lib/security/$ISA/pam_per_user.so  /etc/security/login.map

account    required     /lib/security/$ISA/pam_per_user.so  /etc/security/login.map

session    required     /lib/security/$ISA/pam_per_user.so  /etc/security/login.map

password   requisite    /lib/security/$ISA/pam_passwdqc.so retry=3 min=8,8,8,7,6

password   sufficient   /lib/security/$ISA/pam_unix.so use_authtok nullok shadow

password   required     /lib/security/$ISA/pam_deny.so

패스워드의 최소 길이등을 지정한 것을 변경 해 주면 되는 것이다.  일단 이 파일을 수정전에 아래와 같이 +t 옵션을 추가해 주어야 한다.

# chmod +t /etc/pam.d/system-auth

# ls -l /etc/pam.d/system-auth

-r--r--r-T    1 root     root                623 Dec  2 02:25 system-auth

그리고 파일을 수정하는데, 다음과 같이 변경해 주면 된다.


password   requisite    /lib/security/$ISA/pam_passwdqc.so retry=3 min=0,0,0,0,0

이후 패스워드를 변경해 보면, 이전과 같는 달리 좀더 짧은 패스워드를 사용할 수도 있다.

/etc/pam.d # passwd

Changing password for root

You can now choose the new password or passphrase.

A good password should be a mix of upper and lower case letters,

digits, and other characters.  You can use a 0 character long

password.

A passphrase should be of at least 3 words, 0 to 40 characters

long, and contain enough different characters.

Alternatively, if noone else can see your terminal now, you can

pick this as your password: "pengr-vaphe_ohggba".

Enter new password:

Re-type new password:

passwd: password updated successfully

ESX 의 파일명은 system-auth-generic 로 약간 다르다. 좀다 자세한 것은 아래 참고를 살펴보기 바란다.

[참고]
1. ESX and ESXi 4.x password requirements and restrictions

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1012033

ESXi 4.1 에서 SSH 기능 사용하기

얼마전 VMWare ESXi3 에서 SSH 접근하여 사용할 수 있는 방법에 소개했다. ESX 4 버전대에서는 이런 방식이 조금 달라졌다. ESXi 4 버전을 설치했다면, vSphere Client 를 통해 접속후
Configuration -> Security Profile -> Properties 를 보면 아래와 같은 화면을 볼 수 있다.

Remote Tech Support 를 클릭하여 시작해 주면 상태가 Running 으로 변경된다. 이외 콘솔화면에서는 Troubleshooting Mode 를 클릭하면 다음과 같은 화면을 볼 수 있고 마찬가지로 Remote Tech Support 를 Enable 해 주면 된다. (아래 화면은 현재 Enable 되어 있는 상태이다)

SSH 로 접근은 필요에 따라 유용하게 사용될 수 있을 것이다.

[참고]
1. Using Tech Support Mode in ESXi 4.1
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1017910

2. VMWare ESX3i 에서 SSH 로 접근하여 사용하기!
http://www.packetinside.com/2011/01/vmware-esx3i-ssh.html

VMWare ESX3i 에서 SSH 로 접근하여 사용하기!

VMWare ESXi 는 무료로 사용가능한 가상화 솔루션이다. VMWare Workstation 과 달리 안정적으로 대량의 가상 머신을 운영하기에는 적절한 방법이다. 리눅스 커널을 기반으로 만들어진 것이며, 최근버전은 ESXi 4.1 버전이다. 3i 버전도 필요에 따라 유용하며, 이에 ESXi 3 버전에 대한 루트 접근 방법을 소개한다.

이미 ESXi 를 사용하는 사용자라면 루트권한을 획득하기 위한 방법을 많이 알고 있을 것이다.
가상화를 이용한 프로젝트도 진행하고 있으며, 개인적으로 관심도 많기 때문에 앞으로 패킷인사이드에서는 가상화에 대한 부분도 다뤄볼까 한다.

ESXi 는 원격에서 클라이언트 프로그램을 통해 접속을 하게 되며, 직접적으로 쉘로 접근하는 방법은 제공하지 않는다. 하지만, 접근할 수 있는 방법이 있으므로 이를 이용하면 여러분들이 원하는 형태로 제법 운영 가능하다.

루트로 접근하기 위해서는 다음과 같은 방법을 사용한다.

1. 구동된 화면 ESXi 콘솔 에서 (회색과 노란색 화면) ALT + F1 을 누른다.
2. 여기서 unsupported 라고 입력한다. 이때 타이핑 하는 것은 나타나지 않는다.
3. 올바르게 입력하면 다음과 같은 접속 화면을 볼 수 있다.

4. SSH 를 enable 하기 위해 /etc/inetd.conf 를 수정해야 한다.

vi /etc/inetd.conf

5. ssh 를 서치해 보면 ssh 가 # 으로 주석처리 되어 있다. 이 주석을 제거해 주면 된다.

#ssh   stream   tcp   nowait   root   /sbin/dropbearmulti   dropbear

6. 저장하고 빠져 나간다음 서비스를 재 시작해 준다. SSH 가 enable 되었으므로, 원격지에서

VMWare ESXi 가 설치된 IP 로 접속을 시도하면 된다. ( ssh root@esxi ip )

/sbin/services.sh restart

* 업데이트 버전에 따라서 달라질 수 있는데, 만약 접속이 제대로 이루어 지지 않는다면

ps | grep inetd 

로 inetd 프로세스를 찾아 kill -HUP 로 inetd 를 재 구동해준다.

7. ALT + F2 를 누르면 다시 원래의 GUI 화면으로 이동한다.

자! 이제 쉘로 접근하여 원하는 형태대로 동작시켜보면 된다. 커맨드로 제어할 수 있는 명령어 등이 있으므로, 필요에 따라 적절하게 사용하면 된다.