Fantasy

xl shutdown 게스트id

보통은 이렇게 종료가 된다. 그래도 안 될 경우에는

xl destroy 게스트id

이거 한 방이면 된다.

domU가 실행중인 상태에서 USB를 꽂아 인식시키기.

xl list

게스트의 id 확인

xl block-list 게스트id

그러면 Vdev 번호들을 잘 확인해두자. 나중에 어떤 번호가 추가되는지 유심히 볼 것.

이제 fdisk -l을 이용해서 USB가 무슨 이름으로 인식되어 있는지 확인한다.

/dev/sdc로 되어 있다. 그리고 파티션은 sdc1 하나만 있다.

필요한 정보는 이 sdc1이라는 이름이다.

이제 이 USB를 domU에 attach한다.

그 전에, domU에서 안 쓰고 있는 device 이름을 지어줘야 한다.

domU에서 /dev/ 아래 파일들을 확인해보자.

나는 xvda1, xvda2, xvda3 이렇게 세 개를 쓰고 있다.

xvdb라는 이름은 안 보인다. 새 이름은 xvdb로 지어주면 되겠다.

참고로 paravirtualized VM일 경우는 반드시 xvd로 시작하는 이름이어야 한다.

아래와 같이 명령을 내려서 attach한다. 명령은 dom0에서 내린다.

xl block-attach 게스트id phy:/dev/sdc1 xvdb w

짠! 이제 domU에서 /dev/ 아래 파일들을 확인해보자. xvdb가 새로 생겼다.

이제 mount한다.

mkdir /tmp/mount

mount /dev/xvdb /tmp/mount

이제 mount가 되었으니 USB 안의 파일들을 보라.

cd /tmp/mount

ls

보인다. 인식되었다.

일이 끝나면 다시 안전하게 unmount하고 detach해야 데이터를 안전하게 보존할 수 있다.

umount /tmp/mount

마지막으로 detach하자. 

그런데 그 전에 dom0에서 확인할 것이 있다.

xl block-list 게스트id

새로 추가된 한 줄이 보이는가? 아까 Vdev 번호를 잘 봐두라고 하였다. 새로 추가된 Vdev 번호가 바로 USB의 번호이다. 이 번호를 이용해서 detach한다.

xl block-detach 게스트id Vdev번호

이제 제대로 detach 되었는지 확인해본다.

xl block-list 게스트id

성공적으로 한 줄이 사라졌을 것이다. detach 되었다.

끝.

  Xen의 프로파일링을 위해 guest의 kernel에 trace point를 넣어서 빌드했다. 수정한 커널을 domU에 설치해야 하는데, 직접 데비안 패키지를 VM에 복사하는 것은 할 줄 몰라서 SCP(secure copy)를 이용하기로 했다. 서버에 linux-image-3.15.8_3.15.8_amd64.deb 파일을 올려두고, VM에서 그 파일을 다운로드받았다.

  VM에는 데비안 7(wheezy)가 설치되어 있었다. 새 커널을 적용해 보았다.

  이제 설치가 끝났으니 VM을 halt한 뒤 호스트에서 다시 VM 을 생성하여 새로운 커널을 적용하려고 했다. 그러나 부팅이 되지 않았다.

  원인을 검색해보니 다음과 같다. 데비안 계열은 새로운 커널을 설치할 때 기존의 커널을 지우지 않고 그대로 남겨두어 사용자가 부팅 시 커널을 선택할 수 있게 하는데, XEN의 pygrub은 어떤 커널을 선택할 지 알 수 없어 에러를 내고 멈춘다는 것이다.

  일단 VM의 부팅이 안 되니까, 어떻게든 부팅을 시켜야 해결을 할 수 있다. 임시 방편으로 Dom0의 커널을 빌려서 DomU를 부팅한다.

  스크립트에 kernel, ramdisk, extra 추가 (자기 시스템의 설정에 맞게 적절히 고칠 것)

  호스트의 커널을 빌려서 일단 VM 부팅에 성공했다. 이런 꼼수를 알려주신 외국의 능력자에게 감사를 드리며...

  이제 부팅이 되었으니, 옛날 커널을 제거해야 한다. 
  자동 제거를 원하면 apt-get autoremove를 사용하고, 수동 제거를 하려면 직접 검색해서 지워야 한다.

  이렇게 설치된 데비안 패키지 중에서 옛날 커널 패키지의 이름을 발견할 수 있다.

  이제 제거가 끝났으면, update-grub을 한 뒤 /boot/ 아래를 찬찬히 살펴본다. 오직 하나의 커널만 검색되는지 확인한 뒤, halt 명령으로 VM을 종료한다.

  다시 VM 부팅 설정을 원래대로 복원한다.

  이렇게 하면 문제 없이 VM이 부팅되어야 한다. 그러나 여전히 pygrub 에러가 발생한다. 아마 update-grub의 버그인 것 같은데 정확한 원인은 알 수 없다. 어쩌면 apt-get autoremove를 안하고 수동 제거를 해서 발생한 문제일지도 모른다.

  일단 다음과 같이 해결했다.

  이런 식으로 꼼수를 썼다. 이렇게 하면 호스트 커널의 도움을 받아서 XEN 부팅 스크립트의 오류를 피해가고, 그 뒤에는 pygrub을 사용해서 게스트의 커널을 정상적으로 실행하게 된다. 이렇게 한동안은 잘 돌아갔다. 내가 VM에 파티션을 추가할 때까지...

  요약하면 다음과 같다. fio 실험을 할 때 ftrace가 섞이는 문제가 발생했다. fio 실험을 하면서 동시에 ftrace 결과를 trace.txt에 저장한다고 할 때, ftrace를 파일에 쓰는 것 자체가 ftrace로 기록되었던 것이다. 순수하게 fio에 관련된 trace만을 뽑기 위해서, fio가 실행되는 디스크 파티션과 ftrace 파일이 기록되는 디스크 파티션을 분리해야 했다. 그래서 VM에 새로운 파티션을 추가했는데, 그 이후로는 또 부팅이 되지 않았다. 위의 해결책이 먹히지 않자, 그래도 일단 부팅은 시켜야 하니까, 다시 원점으로 돌아가기로 했다.

  호스트의 커널을 빌려서 부팅에 성공은 했지만, 이렇게 하면 내가 수정한 커널이 아니라서 실험에 사용할 수 없다. 

  그 순간 깨달았다. 

  게스트 VM의 커널과 ramdisk를 호스트에 복사해두고 부팅할 때마다 이용하면 될 것 같다. 그래서 VM에서 /boot로 이동하여 "/boot/vmlinuz-3.15.8"와 "/boot/initrd.img-3.15.8"를 발견하고는 얘들을 호스트로 가져오기로 했다. 그런데 어떻게? VM에서 호스트로 바로 파일 복사를 할 수 있나? 그냥 아까 하던대로 SCP를 사용하기로 했다. 두 파일을 서버에 올려두고, 호스트에서 SCP로 다운로드 받았다. 그리고 다시 스크립트를 고쳤다.

  이제 된다. 이제 domU 부팅도 잘 되고, 내가 수정한 커널도 잘 적용이 되어 있다.

원글: http://linuxsysadminblog.com/2012/11/xen-add-extra-partitions-to-guest-os/

XEN Guest VM의 partition을 추가할 필요가 생겼다.

VM의 커널에서 I/O trace point를 잡고 ftrace로 출력하는 것을 trace.txt로 저장하는데,

ftrace 파일 저장 자체의 trace가 다른 I/O trace와 섞이기 때문에 문제가 되었다.

fio를 이용해서 실험하는 중에 나오는 I/O trace와 ftrace를 저장하는 과정에서 나오는 I/O trace가 섞여버린다면, 실험은 엄밀하게 보았을 때 잘못되는 것이다.

그리고 fio 실험을 할 때 100GB를 write하는데, VM에 할당된 용량은 8G 뿐이므로 fio 실험시 디스크 용량을 꽉 채우고도 몇 바퀴나 overwrite하게 된다. 그래서 trace 파일을 동시에 저장할 용량은 부족하게 된다.

하지만 ftrace 파일 저장을 위한 별도의 파티션을 추가한다면, 이 모든 문제가 해결된다.

파티션을 나누는 방법은 원글에서 참고하여 정리한다.

1) 새로운 논리 파티션을 생성하고 포맷한다. 보통 자신의 XEN VM을 /dev/vg0에 설치했을 것이다. 아래 예제는 ftrace_storage라는 이름으로 2GB를 할당하는 것이다.

2) 자신의 guest VM xen config를 수정해서 guest OS에 새로운 파티션을 추가한다. "xvda3"와 같이 새로운 device name을 할당한다. 그리고 VM을 halt했다가 새로 create하여 새로운 파티션을 인식시킨다. 단순히 VM에서 reboot하는 것으로는 새로운 xen config를 읽을 수 없다.

3) VM을 새로 생성하면, VM에 로그인하고 새 파티션을 mount한다. 새 파티션은 아까 추가한 것처럼 "/dev/xvda3"에 있다.

fstab을 보면, 기존에 있던 xvda2의 설정이 있다. 이것을 그대로 참고하여 xvda3를 추가하면 된다. 그 중 noatime, nodiratime과 같은 설정도 그대로 가져왔는데, 아직 무슨 뜻인지는 모른다. fstab에 대해 자세히 공부하면 알 수 있을 것 같다.