pve 的vm停不掉
不曉得原因為何? 我的pve server總是會有新建立vm的時候, 停都停不掉的問題
只好下指令停調
0. ps aux | grep "/usr/bin/kvm -id <VM ID>" kill -9 <ps id> 1. qm unlock <VM ID> 2. qm stop <VM ID>
不曉得原因為何? 我的pve server總是會有新建立vm的時候, 停都停不掉的問題
只好下指令停調
0. ps aux | grep "/usr/bin/kvm -id <VM ID>" kill -9 <ps id> 1. qm unlock <VM ID> 2. qm stop <VM ID>
前陣子使用兩台PC安裝pve, 做成cluster方便管理, 但遇到其中一台只要使用zfs就會出錯, 另一台是正常的.
可是有一天遇到停電. 重開機之後, 另一台原本zfs正常,居然出現找不到zfs的錯誤訊息.
當時我登入到第一台查看, 系統出現zfs硬碟正常的, 但總是無法透過GUI介面新增回來, 最後發現, 我應該要登入第二台,才可讓zfs重新回來, 原來這兩台是合作, 又保有各自隱私呢.
哈!, 使用storage server習慣了, 遇到沒有storage server就手忙腳亂一番, 因此記錄下來.
最近遇到pve 6.2 某硬碟解除lvm後, 發現還無法另作他用, 系統出現device mapper的狀態, 代表系統還認為正在使用中,
爬了一下文, 發現一個好用的指令 dmsetup status可以看出所有lvm狀態,
確認那些不再使用後, 使用 dmsetup remove 移除, 該硬碟才算是真正自由
先前遇到一件事情, 其實說來話長, 也是因為covid-19造成的
因為無法親自到公司越南廠處理pve server, 偏偏又遇到pve不穩的狀況, 只好移除一些當時手動掛載的硬碟.
這下好了, 請當地的電腦公司人硬是移除手動掛載的硬碟 , 重開機後發現總是進入maintenance mode,
搞了好久才發現必須把/etc/fstab 的手動掛載硬碟資訊移除, 才能正常開機, 因此紀錄一下,以免重蹈覆轍.
我自己在pve 6上使用zfs的經驗不是很順利;有遇到慢的、不穩的,現在可能還需要調整zfs的快取大小,才能讓zfs順利使用。
新增一個檔案 /etc/modprobe.d/zfs.conf
並修改如下:
範例為最小4G, 最大16G, 可自行依照主機實力設定,千萬不可多。 修改後重開機, 可下arcstat 查詢是否成功。
options zfs zfs_arc_min=4294967296 options zfs zfs_arc_max=17179869184 options zfs zfs_flags=0x10
PVE8 注意事項(2023-8-11)
1. 修改 /etc/apt/sources.list.d/ceph.list #若沒有訂閱,請全部加上 # #deb https://enterprise.proxmox.com/debian/ceph-quincy bookworm enterprise 2. 修改/etc/apt/sources.list.d/pve-enterprise.list #deb https://enterprise.proxmox.com/debian/pve bookworm pve-enterprise #deb http://enterprise.proxmox.com/debian/pve bookworm pve-no-subscription deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription deb http://ftp.debian.org/debian bookworm main contrib deb http://ftp.debian.org/debian bookworm-updates main contrib deb http://security.debian.org/debian-security bookworm-security main contrib
接下來執行apt update;apt upgrade就可以了
PVE 6 注意事項
在這虛擬化盛行的年代, 偏偏就有很多軟體開發商, 還在抗拒虛擬化, 害怕一旦虛擬化後,將更容易被盜用,造成損失.
他們的做法主要有二,
一是綁定usb key , 讓你虛擬化後,還是得依賴usb key;
另一是軟體自行偵測是否處在虛擬環境, 若是就拒絕運行,有些則是偵測後,最後還是綁定一台實體主機, 進行授權檢查.
其實在我看來, 他們就是打著反盜版侵權的旗幟, 實際上強力控制客戶.
以台灣最有名的ERP廠商為例子 , 朋友10年前購買workflow GP 3.1 , 當時並沒有告知會鎖定實體主機, 直到朋友公司因為主機老舊,需要重新安裝, 卻出現安裝到虛擬伺服器上, 無法使用的情形, 詢問後, 才知道必須另外在一台實體主機上安裝授權程式, 並且支付ERP廠商”產生“授權序號的費用, 才能使用.
ERP廠商說得好聽就是請記得購買維護, 這些都可以免費協助, 說難聽就是要綁架,要控制這家公司的, 強力取得維護.
其實老實說, 大部分的公司都願意購買維護, 大可不需要用這種手段, 讓IT難為.
萬一實體主機壞了, 系統就停擺, 要等他們處理, 但他們卻沒有想過, 萬一產品停產, 不再維護, 或公司倒了怎麼辦?
後來我跟朋友在一個場合遇到, 才聊到他的問題, 於是我就幫忙檢視一下, 朋友公司使用ESXi 6.5 , 真的無法運行, 仿間小技巧都無法騙過ERP軟體的偵測.
我左思右想,居然橫空出現一個想法, 2010那個年代, 大部分的IT只知道vmware出的虛擬伺服器, 因此我猜測ERP廠商大概也就只會偵測vmware, 並不會偵測qemu , promox ve.
嘿嘿, 於是我立馬安裝了promox ve這個虛擬伺服器系統, 再重建workflow erp系統, 果然成功了, erp軟體一點都沒發現身處虛擬環境, 運行正常.
後話, 我還是建議朋友購買維護, 畢竟他們的ERP專業很夠, 但系統建置這方面就小鼻子小眼睛, 就讓人非常不認同.
會用到這類軟體的公司, 營收都是億來億去, 豈會虛擬化後, 還複製到別處使用, 況且這樣的軟體,一般還要經過上課, 顧問輔導, 系統開帳才有辦法使用, 會願意這樣做的公司, 還會盜用?
系統移轉在驚喜中完成,有promox ve真好!又推坑一家公司了.
jitsi 大名鼎鼎, 我們公司用了10年的openfire內部即時通訊(xmpp server), 用戶端就是用jitsi(我都簡稱神燈巨人).
多年前發現 jitsi 有meet套件可以套用在openfire裡面, 使用結果好爛幾乎不能用, 用ubuntu安裝,也一直很不穩定, 改版很頻繁.
隨著新冠病毒出現, 節神 丟出開源視訊這個議題,我才想起應該是時候,要再測試看看了, 試用結果還不錯,可以讓公司的人使用.
**經過多次測試, 建議使用 “虛擬機加單個對外ip網卡” (非docker,無nat) 才能真正穩定 – 2020/05/06
https://github.com/jitsi/docker-jitsi-meet # 先想好要用哪個主機名稱, 先把letsencrypt搞定 certbot-auto certonly --standalone --preferred-challenges http -d <full host name> 1. # root # 下載最新的版本, 複製預設的設定檔案 git clone https://github.com/jitsi/docker-jitsi-meet && cd docker-jitsi-meet cp env.example .env 1.1 安全性增加了 ./gen-passwords.sh 2.修改 .env , 視自己docker狀況調整以下參數 CONFIG=~/.jitsi-meet-cfg # Exposed HTTP port HTTP_PORT=8000 # Exposed HTTPS port HTTPS_PORT=8443 # System time zone # 這我調整taipei TZ=Asia/Taipei # Public URL for the web service # 這我是沒調整,因為我是用httpd reverse proxy #PUBLIC_URL=https://<full host name> ENABLE_LETSENCRYPT=1 # 告訴 jitsi 說我的letsencrypt是什麼 LETSENCRYPT_DOMAIN=<full host name> 3.依照.env的 CONFIG 參數, 建立相關目錄 mkdir -p ~/.jitsi-meet-cfg/{web/letsencrypt,transcripts,prosody,jicofo,jvb} 4.視情況修改 docker-compose.yml volumes: - ${CONFIG}/web:/config - /etc/letsencrypt:/etc/letsencrypt - ${CONFIG}/transcripts:/usr/share/jitsi-meet/transcripts 5.上線兼啟動(這部份讓人產生錯覺,很快網頁可以連線,但實際上要5分鐘才正常,畢竟用了4個container) docker-compose up -d 6.修改解析度(這我沒怎麼測試,預設是720,為了頻寬著想,所以改480) # ~/.jitsi-meet-cfg 這個目錄依剛開始安裝的.env設定而不同 cd ~/.jitsi-meet-cfg/web vi config.js ## constraints: { video: { aspectRatio: 16 / 9, height: { ideal: 480, max: 480, min: 240 } } },
Optional
1. 啟用認證 # 修改 .env 啟用登入認證(我使用最基本的內部認證, ldap怎麼都不成功...XD) # Enable authentication ENABLE_AUTH=1 # Enable guest access ENABLE_GUESTS=0 # Select authentication type: internal, jwt or ldap AUTH_TYPE=internal 1.1 啟用內部認證後,如何新增使用者 # 進入container docker exec -it docker-jitsi-meet_prosody_1 bash # 建立使用者,後面那串meet.jitsi不需要修改哦 prosodyctl --config /config/prosody.cfg.lua register <使用者名稱> meet.jitsi
2. 增加google日曆功能
1 先想好使用哪個google 帳號讓大家能自由存取,可個人帳號也可使用g suite帳號 建議該帳號的calendar只用來預約會議室使用 2 登入進入 https://console.cloud.google.com/apis/dashboard 新增project,進入Credentials新增 OAuth 2.0 client IDs , 新增後會給你一個client id,記下來 xxxx.apps.googleusercontent.com 3 進入 AAuth consent screen , 設定該 auth 的使用範圍 4 修改 vi ~/.jitsi-meet-cfg/web/config.js 啟用google calendar , 加上先前的client id, enableCalendarIntegration: true, googleApiApplicationClientID:”xxx.apps.googleusercontent.com”, 5.重啟 cd ~/docker-jitsi-meet/ ; docker-compose restart 6 登入jitsi meet 進行相關授權, 若出現未經允許存取calendar,就不管了,允許吧. https://github.com/jitsi/jitsi-meet/blob/master/doc/integrations.md
sudo vi /etc/ssh/sshd_config # 加上以下設定 PermitRootLogin yes # 重啟sshd sudo systemctl restart sshd.service