作者：火柴不靠譜
專業菜農。電動工具狂熱愛好者。
本職：IT民工 副職：民工——修理改裝各種電器，打牆鑽孔，家具安裝。。。
創作立場聲明：本文過於偏技術向，感謝耐心看完。也感謝所有的讓我站在他們的肩膀上的大神。
前言
這個春節因為新冠肺炎的原因，成為我有生以來過的最為特殊的一個春節。因為宅在家裡實在是無聊，就把家裡的無線+NAS系統整個重新弄了一遍。
一、無線優化：華碩AC86U+華碩AC1750 B1組Ai-Mesh家裡的無線原本是用的華為Q2子母套裝+小米路由器R2D的組合，組合的方案是Q2母路由放在A點的弱電箱內，子路由放在B點插座，小米路由器R2D通過LAN口接在C點當AP使用。
家裡的WIFI設備主要包括：小米淨水器、客廳空調、手機5臺、iPad 2臺、MacBookPro、明基GV1、風行電視、愛奇藝電視果4K、小米智能插座等。其中小米淨水器固定在廚房的櫥櫃內，因為遮擋較多，是個弱信號設備。
Q2子母套餐的SSID為SSID-A，小米路由器R2D的SSID為SSID-B，兩套路由器的SSID並有設置一致，因為主臥的小米路由器R2D主要是給自己臥床打王者用的，所以為了避免出現切換失敗之類的情況，設置不同的SSID，每次進主臥之後檢查一下連的是不是SSID-B，如果不是的話，手動切換一下再玩。
SSID-A則是給家裡人用，但是有一個問題：因為Q2的子母路由器是通過電力線進行連接，母路由因為放在弱電箱裡，所以是插在弱電箱內的插座上，然後因為家裡的房子是精裝修的，估計用的電線也不是特別的好，電力線只能跑到70M左右，如果遇上用電高峰，還會降到10幾M這樣，並且電力線的延遲也比較高，這就造成了在主臥內，如果連的SSID-A，無線的體驗並不是特別好。同時，Q2子母套裝的本質其實是母路由跟子路由使用同一個SSID，但並不是mesh，WIFI切換隻能靠無線終端自己根據信號強度來判斷，因此切換很慢，有時甚至出現WIFI信號在很差的水平上維持著一直不切，嚴重影響體驗。
同時，在這個方案裡，與主臥僅一牆之隔的次臥2莫名的WIFI信號特別特別的差，究其原因，可能是因為B點的華為Q2子母路無線功率不夠，C點的小米路由器R2D往D點的方向正好被臺式主機擋住信號。目前次臥2是我父親在住，老人家平時用在客廳用明基GV1投影儀看劇，晚上便直接把投影連三角架拿到房間接著看，還好明基GV1的WIFI比較給力，雖然信號差，但勉強能看視頻。
最後要提一下的是E點的衛生間，作為一個現代人，蹲馬桶刷抖音是每天必做的功課之一。但是，因為E點位置的問題，ABC三個點到達E點的直線路程上都要穿好幾道牆，特別是B點，還是以近30度角穿過去，所以E點只能連上A點的2.4G WIFI勉強使用。
原本我覺得這個方案也是勉強可用沒問題的，但是家人經常跟我吐槽WIFI卡，呃，WIFI卡我自己分析了一下，主要是這兩個原因：華為Q2路由本身的性能較低，而且可能還不支持MU-MIMO（官方宣傳跟說明文檔都沒提），所以在10+的WIFI帶機量之下，性能有點吃力，而且終端裡還有小米淨水器這樣的弱信號設備，所以會出現即使WIFI信號滿格還是卡頓的情況。實際測試中，我用手機蹲在A點的弱電箱邊上通過5G連Q2母路由，實際下載速度為230Mb/s，跑不滿家裡的300M寬帶（在主臥測速能到340Mb/s）。
1.2、無線優化方案於是，在經過多方綜合考慮之後，決定購入華碩AC86U+AC66U B1/AC1750 B1的組合。
天貓精選ASUS 華碩 RT-AC86U 2900M雙頻千兆無線路由器749元包郵（需用券）去購買
活動
滿849.0減80.0
查看更多商城
AC86U是先入手的，當時考慮的是，如果AC86U的WIFI能夠實現全屋覆蓋，那就可以省下一個AC66U B1的錢了。入手渠道天貓，湊單用了88VIP的滿1000-100數碼券，加上店鋪優惠，實際入手價格為699.81元（就按700算吧）。算是好價。
京東ASUS 華碩 RT-AC1750 B1 雙頻無線路由器594元起
實時價格53分鐘前已更新
去購買優惠
滿600元減10元
掃碼領取
查看更多商城
AC86U買回來一加電，我就意識到自己還是太想當然，主臥幾乎無信號，不得以，還是得再買臺路由器組mesh。華碩支持Ai-Mesh的最便宜的路由器是AC66U B1跟AC1750 B1（這兩個其實是同一個產品的換殼版），當時京東AC1750 B1比AC66U B1便宜50塊，就下單了AC1750 B1，用了Plus會員的500-20券，然後正好趕上光大信用卡的499-50，最終入手價是479元，也是好價了。
AC86U的個頭很大，把天線放平之後，非常勉強地擠進去了客廳A點的弱電箱。當然這樣做AC86U的WIFI信號多少會受到影響，但是為了美觀+便於收納便只好進行取捨了。
AC1750 B1目前是直接放在B點的電視機移動支架下邊，現在家裡太擠，電視機基本就是長期放在主臥，移動支架有點投資浪費了 。線有點亂，拖延症患者還沒打定決定去收拾。
最終的WIFI系統的TOPO如下：
兩臺路由器的使用方案為：AC86U刷Koolshare改版梅林固件，AC1750 B1使用原廠固件，然後組有線回程方式Ai-Mesh。華碩Ai-Mesh的配置方式非常簡單，主路由LAN口插節點路由WAN口，然後在主路由上搜索節點即可一鍵完成配置，限於文章篇幅，就不詳述了。
1.3無線升級效果這個截圖時間是晚上8點，正好是家裡的WIFI使用高峰，可以看到總用戶數22個，其中Mesh節點路由用戶數12個。
家中無線方案升級為華碩Ai-Mesh系統之後，客餐廳、主臥、次臥1、次臥2均實現了5G信號覆蓋。其中，客餐廳、主臥、次臥1均可跑滿300M寬帶（實測340Mb/s），次臥2可以跑到280Mb/s（老父親看劇綽綽有餘）。但是衛生間的E點實在是位置太差，做不到5G信號覆蓋，只能跑2.4G，實測速度70-80Mb/s，但是好在延遲也在10ms內，刷抖音足夠了。
家中基本實現全屋5G無線覆蓋，本次無線優化也算是比較成功的。總共花費為700+479=1179元。
二、J1900主機安裝PVE+群暉+LEDE（附NAS數據恢復）2.1不太成功的群暉6.2.2版本升級家中的無線折騰完之後，我便在vultr租了個VPS玩，搭了ss+ssr+v2ray全套。。。結果發現AC86U跑v2ray有點費勁，於是便開始想解決方案。原本想在J1900的黑群上用VMM裝LEDE做旁路由，結果家裡的黑群還是史前的DS3617xs 6.1.1版本，並不支持VMM，然後折騰了一番Docker無果，便頭鐵直升6.2.2，結果當然是喜聞樂見的掛了。
折騰了老半天的6.2.2引導U盤，始終不是很順利，最後終於解決了：不能使用UEFI引導，只能Legacy引導。
方案：
使用引導文件：DS3617_boot_1.03b_6.22.img
用Win32DiskImager將引導文件寫入U盤，通過chipeasy查看U盤的vid跟pid，通過DiskGenius訪問U盤的EFI文件夾，將其中的grub.cfg中的vid跟pid改為自己U盤的vid跟pid（洗白的話，也是在這裡修改sn跟mac）
將U盤插入J1900主機的USB口，通過Legacy方式進行引導。如果引導還有問題的話，可以考慮通過DiskGenius訪問引導U盤的第二個隱藏分區，下載大神做的擴展驅動包extra.lzma進行替換以排除驅動問題。
引導成功之後，因為我的群暉是從6.1.1升級上來到6.2.2最新版本的，還遇上了登陸DSM時提示「您沒有權限使用本項服務」的問題。在手機上試了一下safari可以正常登陸，於是嘗試使用Firefox、Chrome等不同的瀏覽器進行登陸，最終在Chrome上成功登陸。
不過，這個問題沒有完全解決，因為我遇上了另一個問題：J1900主機重啟之後，依然發生失聯的情況。接上顯示器後發現主機重啟之後又自動進入了UEFI引導方式，然後在BIOS中也沒找到這塊主板關閉UEFI引導的選項，看來是解決不了了。（寫文章寫到這裡，突然起來還有一個方案可以試一下：將U盤的分區表從GUID改為MDR或許可以解決，妹的，當時怎麼沒想到啊！現在已經遲了 )
2.2、NAS數據恢復因為U盤引導的問題當時無法解決，所以DSM登陸問題也沒來得及解決了。再加上黑群用了這麼久了，想換個方式換個玩法，於是便決定用PVE+群暉+LEDE的方案。而且，我的J1900主機是一個比較奇葩硬碟組合：1T+2T組了一個Raid1（最終空間只有1T）——嗯，因為當時剛裝黑群的時候想著1T空間先用著，以後空間不夠用了再把1T的那個硬碟換成2T的，這樣就有2T的Raid1了，結果因為小主機用的是筆記本硬碟，眼睜睜看著希捷2T硬碟在購物車裡放了快2年了價格依然堅挺，貧窮讓我理智，還是繼續等吧。正好趁著換方案不再用Raid1了，改用Basic方案吧，這樣NAS空間就不用那麼捉襟見肘了。
不過，在換方案之前，我得先把群暉盤裡的數據先恢復出來。因為是Raid1，所以只需要拆下來其中一塊硬碟即可完成數據恢復。
恢復方案
下載一個ubuntu的ISO，使用rufus製作一個ubuntu啟動U盤。
將拆下來的NAS硬碟直接裝到臺式機主機中。
通過ubuntu啟動U盤引導，選擇Live方式直接啟動進入ubuntu（因為是U盤啟動系統，比較慢要耐心等待一下）。
進入ubuntu系統之後打開terminal進行NAS盤的掛載操作：
首先修改root密碼
sudo passwd root
然後切換到root權限
su root
然後安裝mdadm組件
apt install mdadm
通過mdadm掛載RAID（命令執行完後會提示NAS盤的RAID信息，我是的md2）
mdadm -Asf && vgchange -ay
然後隨便建個目錄
mkdir /mnt/nas1t
再將RAID掛上去
mount /dev/md2 /mnt/nas1t
然後後續就可以在圖形界面下將NAS的數據導出來了。
還好我的NAS裡面的數據不是很多，因為除了小姐姐之外，主要是自己macbook的TimeMachine以及通過DS Cloud Station備份的工作文件。TimeMachine跟Cloud Station的文件都可以直接放棄了，等新系統搞好之後重新備份一次就好了——於是我一番猛如虎的操作最後成果是救出了幾百G的小姐姐
2.3、安裝PVE+群暉+LEDE安裝過程其實不複雜，主要是在裝群暉時遇到些問題。對於在網上能夠很容易就找到相關教程的部分，我這裡限於篇幅就從簡了。這裡主要是大致介紹一下過程，以及把自己遇到並解決的坑說出來。
2.3.1、PVE安裝PVE的安裝比較簡單，下載最新的ISO，用rufus製作啟動盤，然後U盤引導按提示一路下一步安裝即可。
安裝完PVE之後，即可通過https://ipaddr:8006來訪問控制臺。這裡要提一下，因為PVE在安裝時默認只使用一塊硬碟，所以其他的硬碟需要根據自己的情況手動進行添加。不過，因為我打算把另一塊硬碟直通給群暉，所以就不需要在PVE中進行掛載了。（備註一下：PVE中有帶Ceph組件，估計開發組的想法是除了PVE的系統盤，其他的硬碟使用Ceph做分布式存儲，不過，我就2塊盤，所以這裡沒打算嘗試了）
進入PVE控制臺之後，在右上角創建一個虛擬機，注意一下VM ID，這個涉及到後面的命令行操作，可以自己定義也可以用自動生成的那個。
作業系統選擇「不使用任何介質」
系統默認即可
硬碟總線要選SATA，默認的SCSI會導致引導不起來。我在這裡走了一晚上彎路
CPU這裡，按照習慣我選的2核（這裡有坑，後面會講一下如何優化）
內存我分了1G，NAS夠用了。
網卡要選E1000，不然沒驅動。
詳細安裝教程可以參考值友文章：
基於ProXmoX VE的虛擬化家庭伺服器（篇三）—黑裙6.2安裝，硬碟直通上篇我們成功的安裝了ikuai和lede，本篇我們講下如何在proxmox中安裝群暉虛擬機。首先網頁登陸proxmox，點創建虛擬機，名稱隨意，記住VMID名稱隨意，記住VMID，下一步選擇不使用任何介質，其他默認選擇不使用任何介質，其他默認，下一步我們後面要硬碟直通給群暉，這裡我們意思一下，磁碟大ClegeA|贊139評論377收藏1k查看詳情然後下載最新的DS918+_6.21-23824-1.04b引導文件（嗯，以前裝的是ds3617xs，這次想換換口味裝ds918，結果後來裝完了數據都恢復完了發現918不能洗白 ），安裝過程如下。
通過winscp將DS918+_6.21-23824-1.04b引導文件跟img2kvm上傳到PVE中。
進入上傳所在目錄
chmod +x img2kvm
然後將引導文件掛到群暉虛機上，我這邊VM ID是100，請注意修改
./img2kvm DS918.img 100 vm-100-disk-1
然後安裝lshw組件
apt-get install lshw
使用lshw查看硬碟的disk id
ls -l /dev/disk/by-id/ | grep ata
然後將之前創建虛機時的硬碟分離並刪除掉
qm set 100 --sata2 /dev/disk/by-id/HGST_HTS541010A9E680_JDD030CCKXNJVH
回到PVE控制臺，把虛機下未使用硬碟掛上去（我這裡是sata1），再到虛機選項中設置引導順序從sata1引導。然後虛機開機，即可通過find.synology.com或者Synology Assistant發現群暉，然後使用本地安裝方式安裝DS918+_6.21-23824.pat即可。
因為我下載的pat文件版本較早，安裝完pat進入DSM之後就發現可以升級6.2.2，直接在線升級了，沒有問題。然後就可以正常使用了。
LEDE安裝就更簡單了，跟群暉一樣，在PVE中建個虛機，然後將創建虛機時的硬碟分離並刪除。
然後直接去https://firmware.koolshare.cn/下載最新的LEDE固件：https://firmware.koolshare.cn/LEDE_X64_fw867/openwrt-koolshare-mod-v2.31-r10822-50aa0525d1-x86-64-combined-squashfs.img.gz
下載成功之後將img解壓出來，通過winscp上傳到PVE裡。在命令行下將img掛給虛機，然後用這個硬碟引導即可。
./img2kvm lede.img 200 vm-200-disk-1
詳細安裝配置也可以參考值友文章：
基於ProXmoX VE的虛擬化家庭伺服器（篇二）—虛擬化軟路由上篇我們已經安裝好了PVE的基礎，這篇我們來講一下如何安裝軟路由，我這裡是ikuai+lede旁路ikuai的安裝首先我們先到網絡部分把網絡埠配置一下編輯一下vmbr0，修改備註為lan，方便維護新建一個埠橋接埠填eth1(這裡每個人不一定，要看你上面的兩個網絡設備，填其中不活動的那個)，備註ClegeA|贊67評論115收藏634查看詳情LEDE我主要是用來裝v2ray client，然後ddnsto也是在LEDE上裝的。旁路由主要的目的還是用來裝插件減輕主路由的負擔啊
三、免費實現群暉內網穿透首先在這裡介紹一下我群暉NAS的用途：
1、使用群暉自帶的Download Station當下載機使用；
2、使用Cloud Station Server，在macbook上安裝cloud station客戶端，將重要工作文件跟NAS同步備份；
3、Cloud Sync，將上面步驟2中同步過來的重要工作文件同步到百度雲；
4、File Station建個TimeMachine文件夾，用作macbook的TimeMachine。
因為J1900小主機有2塊硬碟，其中2T的那塊裝了PVE系統，1T的那塊直通給了群暉。然後在PVE下建了個1.5T的虛擬硬碟分給了群暉。以上用途中，1-3的部分是使用直通的1T硬碟，4的部分是放在1.5T的虛擬硬碟中（實際上在2T的物理盤上）。根據數據備份的三二一原則：三份數據，兩種介質，一份異地，我這也算是滿足甚至超出了：macbook+CloudStation+百度雲+TimeMachine共計四份數據，TimeMachine從某個角度上勉強算第二種介質，然後百度雲算異地
因為PVE裡的群暉裝的DS918，在不能用qc的情況下，我得解決內網穿透的問題了，不然做不到出差的時候隨時隨地進行CloudStation同步，而且，我有頻繁通過手機DS File APP訪問NAS上重要工作文件的需求，這些都是內網穿透的剛需。
內網穿透一般有兩種方案：DDNS跟VPN。這裡兩種方案都用上了。
3.1、DDNS——ddnsto方案DDNS主要是解決遠程管理DSM以及手機遠程訪問DS File的需求。因為DSM管理、DS File都是用的5000埠（http）跟5001埠（https），我這裡只用的http5000埠（要相信群暉的安全性 ）
因為DDNS是在LEDE上做，所以直接採用的ddnsto方案。在LEDE上安裝ddnsto插件，然後到https://www.ddnsto.com微信掃碼登陸獲取token，將token複製到ddnsto插件中並開啟插件即可。
然後在https://www.ddnsto.com上配置動態域名指向群暉即可。
因為我家寬帶沒有公網IP，所以只能內網穿透，ddnsto免費而且速度還算不錯，對於我通過手機用DS File訪問NAS工作文件的需求來說，還是完全可以滿足的。
此外，順便遠程訪問DSM、DS Download等需求也一併解決了（因為都是同一個埠）
3.2、VPN——zero tier方案因為DDNS內網穿透需要流量轉發無論是速度還是數據量都受限於DDNS供應商，所以像CloudStation這樣流量很大的應用就不太適用DDNS了，一個可以直通的VPN非常重要。
zero tier方案就非常適合這個需求：免費、並且VPN節點之間數據直通無需經過轉發。
註冊並登陸https://my.zerotier.com/，在Network選項中Create一個Network，獲得一個Network ID。
然後設置一下VPN的私網網段，可以選現成的，也可以跟我一樣自定義。我是自定義的192.168.188.0/24
然後下一步先別急著用，得分別在群暉跟終端中安裝zerotiear客戶端。
群暉client下載地址：https://download.zerotier.com/dist/synology/
macOS client下載地址：https://download.zerotier.com/dist/ZeroTierOne.pkg
群暉直接在套件中心裡手動安裝，上傳下載的spk文件即可。
然後在群暉中打開ZeroTier組件，複製左下方的Node ID到https://my.zerotier.com中進行添加，然後複製Network ID加入網絡即可。
my.zerotier.com中的client端管理如下：
然後macOS端直接運行pkg安裝即可。然後再在zerotier中通過Network ID加入VPN網絡即可。通過netstat -rn可以看到VPN網段已經成功加入路由表。
然後，在macOS的CloudStation中通過VPN地址添加群暉NAS：
至此，CloudStation的需求完美解決。
前面的工作做完之後，我在設置TimeMachine時發現不能順利訪問NAS了。思考了一下，應該是群暉在LAN跟VPN上都響應了Bonjour導致的。這裡先簡單介紹一下Bonjour協議：
Bonjour是蘋果為基於組播域名服務(multicast DNS)的開放性零設置網絡標準所起的名字，能自動發現IP網絡上的電腦、設備和服務。Bonjour 使用工業標準的 IP 協議來允許設備自動發現彼此，而不需輸入IP 地址或配置DNS 伺服器。
採用 Bonjour 技術的電腦和設備可以自動傳播它們自己的服務，並探尋其他設備提供的服務。你的電腦能夠看到可以列印的印表機，可以聽的 iTunes 播放列表，以及可以視頻聊天的 iChat 好友。設置可以進行文件共享的另一臺電腦。
嗯，是的，macOS是通過Bonjour去發現區域網設備的，雖然在Finder下可以直接通過afp://ipaddr來訪問群暉，但是TimeMachine的設置裡只能使用通過Bonjour發現的磁碟。Bonjour協議是使用mdns去進行設備發現，埠號為5353。
知道原因就好處理了，直接在群暉裡面把VPN接口的Bonjour跟AFP之類的禁用掉不就完了？
進入DSM，在控制面板->安全性中，啟用防火牆。
然後編輯規則，在右上角選擇區域網 51（我的VPN接口），為了穩妥起見，我先建了一條允許192.168.188.0/24訪問6690埠（CloudStation使用的埠）的條目，然後再建了一條拒絕192.168.188.0/24訪問Bonjour、AFP、CIFS、NFS、find DS的條目。然後應用即可。
然後在macOS上再次查看狀態，先ping一下域名，嗯，返回的是LAN地址。
然後再通過netstat確認一下mac到群暉的連接，非常棒，CloudStation的6690埠走的VPN地址，AFP的548埠走的LAN地址。完美解決。
最後匯總一下本章節一共實現的內容：
1、通過ddns，實現手機使用DS File APP訪問NAS；
2、通過zero tier，實現macbook通過VPN與NAS進行文件夾同步；
3、通過在DSM上設置防火牆，實現macbook通過區域網訪問NAS進行TimeMachine（當然，也包括普通AFP訪問了）。
四、群暉CPU優化好了，終於所有功能都實現了，然後我就開始了緊張的原NAS數據導回、macbook通過CloudStation進行同步、macbook通過TimeMachine進行備份等工作。
然後，我發現群暉虛機的CPU佔用特別高！要知道以前物理機裝群暉時，CPU再怎樣高也就10%多點，但是這次虛機的CPU利用率長期保持在50%以上，而且動不動就90%+，特別是macbook通過CloudStation進行同步時，因為zero tier跟CloudStation兩個組件都在運行，一度出現DSM的web端卡爆掉的情況。
哪怕NAS在空載的時候，CPU也一直在50%左右，查看進程發現zero tier一直佔著30%左右的CPU。。。而且在PC上往NAS傳文件，只能跑到50MB/s多點，此時CPU已經90%以上了。。。
於是我認真閱讀了PVE的幫助文件：
A CPU socket is a physical slot on a PC motherboard where you can plug a CPU. This CPU can then contain one or many cores, which are independent processing units. Whether you have a single CPU socket with 4 cores, or two CPU sockets with two cores is mostly irrelevant from a performance point of view. However some software licenses depend on the number of sockets a machine has, in that case it makes sense to set the number of sockets to what the license allows you.
Increasing the number of virtual cpus (cores and sockets) will usually provide a performance improvement though that is heavily dependent on the use of the VM. Multithreaded applications will of course benefit from a large number of virtual cpus, as for each virtual cpu you add, Qemu will create a new thread of execution on the host system. If you’re not sure about the workload of your VM, it is usually a safe bet to set the number of Total cores to 2.
Resource Limits
In addition to the number of virtual cores, you can configure how much resources a VM can get in relation to the host CPU time and also in relation to other VMs. With the cpulimit (「Host CPU Time」) option you can limit how much CPU time the whole VM can use on the host. It is a floating point value representing CPU time in percent, so 1.0 is equal to 100%, 2.5 to 250% and so on. If a single process would fully use one single core it would have 100% CPU Time usage. If a VM with four cores utilizes all its cores fully it would theoretically use 400%. In reality the usage may be even a bit higher as Qemu can have additional threads for VM peripherals besides the vCPU core ones. This setting can be useful if a VM should have multiple vCPUs, as it runs a few processes in parallel, but the VM as a whole should not be able to run all vCPUs at 100% at the same time. Using a specific example: lets say we have a VM which would profit from having 8 vCPUs, but at no time all of those 8 cores should run at full load - as this would make the server so overloaded that other VMs and CTs would get to less CPU. So, we set the cpulimit limit to 4.0 (=400%). If all cores do the same heavy work they would all get 50% of a real host cores CPU time. But, if only 4 would do work they could still get almost 100% of a real core each.
CPU Type
Qemu can emulate a number different of CPU types from 486 to the latest Xeon processors. Each new processor generation adds new features, like hardware assisted 3d rendering, random number generation, memory protection, etc … Usually you should select for your VM a processor type which closely matches the CPU of the host system, as it means that the host CPU features (also called CPU flags ) will be available in your VMs. If you want an exact match, you can set the CPU type to host in which case the VM will have exactly the same CPU flags as your host system.
This has a downside though. If you want to do a live migration of VMs between different hosts, your VM might end up on a new system with a different CPU type. If the CPU flags passed to the guest are missing, the qemu process will stop. To remedy this Qemu has also its own CPU type kvm64, that Proxmox VE uses by defaults. kvm64 is a Pentium 4 look a like CPU type, which has a reduced CPU flags set, but is guaranteed to work everywhere. In short, if you care about live migration and moving VMs between nodes, leave the kvm64 default. If you don’t care about live migration or have a homogeneous cluster where all nodes have the same CPU, set the CPU type to host, as in theory this will give your guests maximum performance.
重點部分標粗了，大意就是，理論上，虛機的CPU核數越多性能會越好，但是同時要考慮做CPU資源限制以免虛機佔用過多CPU時間，此外，CPU默認類型kvm64是為了虛機遷移時的最大的兼容性，而為了更高性能的話，建議設置為host。
OK，明白了就好，按道理來講，群暉上跑了一堆組件，對多核肯定是有要求的，立馬在PVE控制臺上把群暉虛機的CPU改為4核，資源限制250%，類型為host。
然後在PC機上找了個大文件進行測試——MHW的chunk0文件，17G夠大吧，哈哈！
速度平均在70MB/s左右，偶爾會掉速（因為J1900不支持VT-D，I/O延遲要差一點）
在DSM中可以看到實時速度、CPU使用率、進程佔用CPU情況。主要是DSM內部服務跟SMB佔用較高。
然後打開資源監控看看詳細數據，CPU佔用基本保持在80%左右（如果我不開DSM的話應該還能低點）
內存倒是挺穩定的，使用率很低。
然後就是傳輸速度，峰值能跑到121MB/s，但是上下起伏挺大的，嗯，畢竟不支持VT-D，沒辦法。
經過CPU優化，NAS在日常空載時CPU使用率保持在10%以下，滿負荷時CPU保持在80%左右。好了，我已經挺滿足的了。如果想再提升一下的話，應該是可以考慮CPU資源限制提升到300%-350%，不過想想算了，就這樣吧，夠用就好。
以上就是本技術宅在這個每天呆家自我隔離的春節中幹的最大的一件事。
嗯，對了，J1900主機還是以前那個主機，從17年5月裝DS3617xs 6.1.1洗白用到現在，然後接著裝PVE+群暉+LEDE繼續服役，也算是值回票價了 。
從目前這兩天的使用來看，J1900平臺在PVE+群暉+LEDE方案下，依然可以滿足需求（自我安慰的同時順便對GEN8土豪們表示羨慕）
本文主要是提供自己的一些方案跟思路，順便把自己遇到的坑提一提，避免值友們走彎路（我熬過的夜，你們不用再熬了），如果是新手司機需要手把手帶路的話，可以考慮百度一下網上大把的現成教程。
最後，謝謝各位看完我的萬字長文。。。