댕댕이화정큐삼님이 쓰신 dsm 7.1 설치 강좌와 Pocopico님이 만든 tinycore-redpill 부트로더 덕분에 esxi 7.0 환경에서 dsm 7.1 설치해서 잘 쓰고 있습니다.
한 가지 단점은 dsm 7 버전부터 인증 받지 않은 제3자 프로그램의 root 권한을 막기 때문에 vm-tools가 정상적인 방법으로 설치가 불가능하다는 점입니다.
vm-tools가 없으면 vmxnet3 드라이버에서 다중 대기열, RSS, 소프트웨어 LRO 사용이 불가능한데 가장 치명적인건 vswitch 내에 있는 호스트끼리 통신할 때 vm-tool 없이 리눅스 vmxnet3 드라이버 모듈에 LRO가 활성화된 상태면 수신 패킷 로스 문제가 발생합니다.
쉽게 말해 가상 호스트끼리의 통신에서 LRO 활성화 상태면 vmware가 가상 스위치라는 걸 인지하고 초대형 버퍼를 보내서 초고속으로 데이터를 주고 받는 것인데 vm-tools가 없는 헤놀로지는 이를 인지하지 못합니다.
현재 제가 겪고 있는 문제는 esxi 내에서 윈도우 서버와 헤놀로지의 파일 전송 문제인데 윈도우 서버에는 vm-tools가 설치된 상태이기 때문에 헤놀->윈도우로는 10g 속도가 나오지만(동일 하드 리눅스에서는 40g 이상) 윈도우->헤놀로는 120mbps 정도로 대부분의 대형 버퍼 패킷이 로스되고 있습니다. 외부 통신은 TSO없이 하드웨어 빨로 헤놀로지에서 10g 정도는 밀어붙일 수 있는데 호스트간 통신에서 속도 저하 문제 때문에 LRO disable이 필요합니다.
예전에 올린 omnios+xpenology 글에서 헤놀로지에서 omnios nfs 원격경로 마운트 했을 때 CPU가 100프로로 치솟으면서 먹통되는 문제도 Software LRO 문제였습니다.
vmtools가 없기 때문에 ethtool 명령은 불가능하고 일반적인 리눅스 커널은 rc.local 스크립트 실행으로
modprobe -r vmxnet3
modprobe vmxnet3 disable_lro=1
lro 비활성화가 가능한데
DSM 7은 커널단에서 드라이버 모듈 적재를 막기 때문에
modprobe -r vmxnet3 부터 거부해서
/usr/local/etc/rc.d 스크립트 실행으로 rmmod vmxnet3 했다가 모듈 언로드 후에 드라이버 modprobe이 안 돼서 vmxnet3 연결 끊어지고 망한 상태입니다.
스냅샷 백업본 있어서 복구하면 그만이라고 생각했는데 복구하면 돌아오는데 데이터 저장된 가상디스크 붙이면 동기화 되면서 vmxnet3 드라이버를 복구하는게 아니라 둘다 지워버려서 망했습니다. Redpill DS3617xs 부트로더 올려서 마이그레이션 해서 복구해야 할 판입니다.
결국 부트로더 단에서 modprobe -r vmxnet3 modprobe vmxnet3 disable_lro=1 으로 로드하면서 LRO disable 과정이 필요합니다.
Pocopico 님께 부탁드려서 lro disabled로 parameter 수정해서 vmxnet3 커널 드라이버를 다시 빌드해야 할 것 같습니다.
제가 redpill 부트로더에 대해 잘 몰라서 이쪽에 전문가이신 화정큐삼님께 도움 요청드립니다. 등 떠밀기..?
그냥 이것저것 삽질하는거 좋아하는데 아는건 별로 없습니다 ^^;;
성능 개선이나 버그를 잡는 레벨이라면 직접 문의를 올리시는 방법이 좋을것 같습니다.
아래 두 사이트에 가입을 하시고, 번역기는 경험상 구글번역기가 가장 오역이 적은것 같습니다.
요령은 문구 맨 앞에 항상 "나는"을 붙여주시는게 좋습니다.
우리나라 말처럼 주어를 생략하면 기본이 You 가 되어 버립니다.
아마, 포코피코님이 대부분 많은 로그 정보를 요청하실겁니다.
그에 맞는 로그를 제공하시고 답변을 주셔야 하는데, 단순히 동작이 되고 안되고의 레벨이 아니라서 상당한 노력이 들어갈것 같습니다.
전문적인 내용이 너무 많아서 제가 모두 이해를 못하고 있고 다시 이부분을 전달 드리기 어려울것 같습니다.
다시 전문적인 질문이 들어오면 다시 대답이 가야 할것 같구요.
저는 네이티브 중심으로만 테스트를 해서, VM은 지식이 짧은것도 도움드리기가 어려운 부분입니다.
아래 질문란 활용하시면서 어려우신점 있으시면 언제든지 질문주시면 그부분은 도움드리겠습니다.
깃헙과 헤놀포럼 둘중에 한곳만 활용하시면 될것 같은데, 저는 빨리 알아보시라고 양쪽에 올리긴합니다.
https://github.com/pocopico/rp-ext/issues
https://xpenology.com/forum/topic/49226-redpill-extension-drivermodules-request/page/8/
https://translate.google.co.kr/?hl=ko&tab=iT
역시 제가 직접 포코피코님께 문의하는게 좋을 것 같습니다.
커널 모듈 로드 단계에서 쉘 스크립트만 조금 추가하면 될 것 같은데 체크섬으로 함부로 ext 수정을 못하게 막아놨더군요.
dev문서 읽어보니까 개발 과정이 이전과 다르게 굉장히 체계적으로 느껴졌는데 ext 로드에 자체 pocopico 규격? 이 있는 것 같습니다.
영어는 문제가 없는데 실은 저도 빠삭하게 아는게 아니라서 pocopico님 질문에 제대로 답할 수 있을지 조금 걱정됩니다.
일단 guthub에 request 올릴 생각입니다.
제가 수정 도와드릴수도 있습니다.
저도 포크한 rp-ext 가 있긴한데요.
댕댕이님도 깃헙 repo 가 없으신가요?
없으시다면 제 repo 에 수정해 드리겠습니다.
https://github.com/PeterSuh-Q3/rp-ext/tree/main/vmxnet3/src
변경 원하시는 스크립트 전달 주십시요.
sha256sum 다시 gen 하고 값 수정해서 넣으면 됩니다.
그정도는 저도 할 수 있습니다.
몽동이님도 필요하신 ext 의 기능은 포크하셔서 직접 수정해서 TC 에 수동으로 로드해서 사용하시고 계십니다.
pocopico님이 상당히 보수적으로 코딩에 접근하셔서, 안정성을 조금이라도 영향을 주는 경우는 충분한 테스트 없이는 적용을 안해주시거든요.
echo -n "Loading module vmxnet3 -> "
if [ `/sbin/lsmod |grep -i vmxnet3|wc -l` -gt 0 ] ; then
echo "Module vmxnet3 loaded succesfully"
modprobe -r vmxnet3
modprobe vmxnet3 disable_lro=1
else
echo "Module vmxnet3 is not loaded "
fi
스크립트 내용의 변경이 다시 필요하시면 말씀해 주십시요.
아래처럼 build action 전에 vmxnet3 ext 를 사전에 추가해 주십시요.
이후에 오토 빌드 과정에서 pocopico님 vmxnet3 ext는 pocopico.vmxnet3 가 이미 존재하므로 overwrite 가 불가하고 스킵됩니다.
DS918+ 를 예로 든것이고 TC 7개 모델 모두 준비되어 있습니다.
(JUN MODE 7.0.1-42218 용)
./rploader.sh ext apollolake-7.0.1-42218 add https://raw.githubusercontent.com/PeterSuh-Q3/rp-ext/master/vmxnet3/rpext-index.json
(JOT MODE 7.1.0-42661 용)
./rploader.sh ext apollolake-7.1.0-42661 add https://raw.githubusercontent.com/PeterSuh-Q3/rp-ext/master/vmxnet3/rpext-index.json
제가 esxi 환경은 테스트용으로 간신히 하나 있는데, 10G 랜카드가 없어서 시험을 해드릴 환경이 안되네요.
DSM 설치를 물어보는 junior 모드로 진입하게 되시면 아래 ttyd 접속하셔서 로그 하나만 제게 보내 주십시요.
잘 수행된건지 분석해 보겠습니다.
http://<youripaddr>:7681/
id : root / pw : ( no password )
cat /var/log/*rc*
와 이렇게까지 신경 써주셔서 정말 감사합니다 ^^
체크섬 과정에서 모듈을 언로드 했다가 다시 로드해도 되려나 모르겠네요.
문제는 현재 esxi에서 Net.Vmxnet3SwLRO 설정을 바꿔서 모든 호스트의 소프트웨어 LRO를 끈 상태임에도 변화가 없어서 LRO 문제가 아닌가 하고 있습니다. 일단 테스트해보고 로그 보내드리겠습니다.
START /linuxrc.syno.impl
Insert basic USB modules...
:: Loading module usb-common ... [ OK ]
:: Loading module usbcore ... [ OK ]
:: Loading module xhci-hcd ... [ OK ]
:: Loading module xhci-pci ... [ OK ]
:: Loading module usb-storage ... [ OK ]
:: Loading kernel modules from extensions ...
Loading kmod #0 "vmxnet3.ko" for pocopico.vmxnet3 (args: )
:: Loading kernel modules from extensions ... [ OK ]
:: Executing "on_boot" custom scripts ...
Running "check-vmxnet3.sh" for pocopico.vmxnet3->on_boot
Loading module vmxnet3 -> Module vmxnet3 loaded succesfully
/exts/exec.sh: ./check-vmxnet3.sh: line 9: modprobe: not found
/exts/exec.sh: ./check-vmxnet3.sh: line 10: modprobe: not found
Ran "check-vmxnet3.sh" for pocopico.vmxnet3->on_boot - exit=127
Running "boot-wait.sh" for redpill-boot-wait->on_boot
Confirmed a valid-looking /dev/synoboot device
Ran "boot-wait.sh" for redpill-boot-wait->on_boot - exit=0
Running "install_rd.sh" for redpill-misc->on_boot
Starting ttyd, listening on port: 7681
Ran "install_rd.sh" for redpill-misc->on_boot - exit=0
ERROR: Some of the scripts failed! See above for any with exit != 0
:: Executing "on_boot" custom scripts ... [ OK ]
Exit on error [99] rp ext init exec failure...
Sun Jun 19 19:07:25 UTC 2022
none /sys/kernel/debug debugfs rw,relatime 0 0
DiskStation>
새로 가상시스템 만들어서 ds918+로 테스트 해봤는데 modprobe가 먹히지 않네요.
안되는 이유는 github FAQ에도 설명되어있는데 결국 커널 드라이버를 다시 빌드하는 것 말고는 방법이 없을 것 같습니다.
https://github.com/pocopico/redpill-load/blob/master/FAQ.md
What's the deal with fake modprobe?
Loading kernel modules is complex. However, in short there are two distinct ways for them to load: from userspace or from kernel space. The latter is kind of misleading since the kernel, after doing some checks, calls /sbin/modprobe to actually load the module (see kmod.c). This path is hardcoded in the kernel. Usually it's a symlink to a kmod utility which uses userspace syscalls to load the module.
Here comes the less-intuitive part. RedPill LKM is loaded on the kernel's request. It happens because we specify the elevator=elevator boot param. This causes kernel to, very early in the boot process (in fact still being in the formal init-before-boot stage), request module named elevator-iosched. There's nothing special in that name - it can be anything as long as the userspace and cmdline agree on the name. Our fake modprobe checks (very loosely) if the requested module is elevator-iosched and triggers the standard force-insmod, then deletes itself. Keep in mind that our "modprobe" isn't actually overriding anything - preboot environment contains no modprobe as it has no concept of depmods (=modprobe would be useless).
[ preboot 환경에는 depmod의 개념이 없기 때문에 modprobe가 포함되어 있지 않습니다(=modprobe는 쓸모가 없을 것입니다). ]
ESXi 7.0 에선 해당사항이 없는 내용일까요?
https://www.dell.com/support/kbdoc/ko-kr/000140785/esxi-4-x-5-x%EC%97%90%EC%84%9C-lro-large-receive-offload-%EB%A5%BC-%EB%B9%84%ED%99%9C%EC%84%B1%ED%99%94%ED%95%98%EB%8A%94-%EB%B0%A9%EB%B2%95
헤놀로지는 vm-tool 자체가 없다는게 문제네요..