2019年3月20日 星期三

vswitch若uplink有多張pnic又用混亂模式會重複收到封包的問題已解決

解決辦法在這 -> https://kb.vmware.com/s/article/59235

架構大概如下
圖中的vSwitch實體對外線路有兩張網路卡互做備援, 很常見的作法, 甚至三張四張都有可能.
其中一個PortGroup, LAN-promiscuous 的設定中, security的部份有允許混亂模式, 以讓VM可以運作bridge功能性.
在上面的連結所給的解決辦法之前, 若VM開啟混亂模式, 再去看收到的封包, 就會發現:
1. 自己發出去的封包會立刻再收到
2. 外面進來的同一個封包會收到超過1個
這樣的狀況會造成bridge功能運作失常, bridge會搞不清楚哪個mac addr是在哪個界面.
依照連結所述, 變更vSphere(ESXi) server設定後, 即避免此問題.
舊的解決辦法就是閹割, 改teaming設定為active/stanby ->  https://kb.vmware.com/s/article/2147616

2018年5月30日 星期三

中年大叔重拾直排輪之歷程-古董直排輪爆胎啦


是的, 古董還是古董, 溜了兩週後, 常受力的輪子的輪圈爆了, 還好只是卡死, 沒摔到一身老骨頭, 倒是之前溜新鞋太激烈操作反而滑倒兩次.

怎麼辦呢? 該不該救這雙古董鞋? 是否還有足夠的價值去救?
最後,  考量兩點, 一是懷舊, 另一是這雙鞋才有後煞車, 比較能示範給大女兒看如何使用這個煞車, 就救吧.

輪子一定要換, 而且要全換比較安全. 軸承呢? 目前覺得還好, 溜起來沒啥不順, 只是休閒溜, 就繼續操吧.
輪子要繼續用74mm小輪嗎?  還是換大點的? 能換到多大的呢?

乾脆, 拿新鞋的輪子換上看看好啦!


好像還...還ok耶? 全都不會卡到! 喔有! 有卡到原始設計的煞車輔助, 就是這塊


它的設計是固定在右上方的螺絲軸上, 當壓下煞車塊時整個煞車套會上推, 然後這塊會因上面的螺絲軸往輪子推動, 而同時對後輪煞車, 但新輪子從74mm變成84mm, 半徑多了5mm, 結果這塊煞車皮還沒踩下去就已經是卡死後輪的狀態, 乾脆切掉~

八顆輪子都換完, 舊的輪子就跟他說掰掰啦, 我們懷念它~
是說拆下八顆後才發現, 有幾顆輪圈部份也有細細的裂痕了.


啊你說新鞋沒輪子怎麼辦? 等我想溜時再買過新輪子裝上去就好啦!(喜舊厭新?)

中年大叔重拾直排輪之歷程-撿回古董直排輪

話說在保養新直排輪的前幾週, 老爸老媽竟然傳來訊息說在完全想不到的地方翻到了我的古董直排輪, 本來都想說20年了, 找到應該也都粉化裂光光了, 結果看照片看起來好像還好?


連說明書都還在!


查了一下這牌子, 是奧地利進口貨, 基本款休閒鞋, 輪子72mm 82A, 好小啊......
之後有回老家, 就將它帶回來了, 初步檢查沒啥問題, 太厲害了, 連軸承都沒有卡死現象.


接著就是軸承大保養: WD-40清洗、去漬油清洗、上潤滑油.
結果卡關的是有個輪子的固定螺絲拆不開, 對向的螺帽會跟著轉, 出動各種工具卡住螺帽後才解開來, 另有幾個C型環很難勾出來, 差點想直接擊穿防塵蓋硬拆.

保養完後測試, 嗯, 有一個不太順......不管了

組裝回去

週末試溜, 還不錯.



2018年5月29日 星期二

中年大叔重拾直排輪之歷程-保養篇

默默地也滑了3個多月了, 該來保養直排輪了, 首要工作就是清潔軸承.
對, 我不喜歡叫它培林, 培林是bearing的音譯, 軸承才是中文對它正式的稱呼.

首要工作就是準備器具: 合適大小的六腳版手、刀片或小一字起子、去漬油、潤滑油、淘汰牙刷、玻璃或陶瓷杯子(不可用塑膠容器, 去漬油會滲入塑膠分子而破壞結構造成滲漏)、防水手套、抹布或紙巾.
防水手套可用醫療用那種矽膠手套會最好操作, 啃雞肉的塑膠袋手套也是可以,  不過上述兩種因為去漬油都會緩緩滲入而破壞結構造成破裂, 因此要多準備幾雙更換. 最耐用就是洗碗用的橡膠手套, 不過我遍尋不著男生大隻手能戴得進去的...

然後就開始拆輪子拆軸承, 可以看到輪子已經被操成梯形狀, 因此順便交換左右輪, 平衡磨損.


網路上很多教拆出軸承的資訊, 因此跳過.
新鞋的軸承是2RS, 代表防塵蓋是橡膠蓋, 很好拆, 用刀片尖端的刀背或小一字起子插入中間環與蓋子縫隙挖起來即可, 我的習慣是兩邊都拆掉, 清洗比較徹底, 反正很好拆裝防塵蓋.
想當年那雙古董直排輪是2RZ, 防塵蓋是金屬片加上C型環固定, 要拆蓋要先挖出C型環, 很不好挖出來, 相當麻煩.

全都拆完後, 軸承丟杯子加去漬油蓋過, 然後拔出鞋子的軟墊放網子丟洗衣機洗, 拿抹布沾水(不要沾去漬油欸!)清潔輪子、輪架、硬殼部份.

接著帶起防水手套, 伸進杯子拿起軸承, 盡量在去漬油裡轉動軸承, 讓髒污掉出來, 並適度用牙刷刷一刷, 但要注意不要讓刷毛被軸承內的滾珠卡到而斷在裡面, 每顆完成後取出放在抹布上晾乾, 剩餘的去漬油若沒有想再利用, 就混入水與清潔劑讓它乳化後倒掉, 我是順便拿來擦一擦被小孩亂畫的地墊牆壁桌椅, 再乳化倒掉.

因為去漬油會連軸承內原本的潤滑油都洗掉, 因此軸承都晾乾後(去漬油揮發性很強, 不用等很久)就可以開始加新的潤滑油進去, 一個軸承只要加一兩滴即可, 太多會在之後轉起來時流出來, 然後開始亂黏灰塵. 加好後轉一轉軸承讓油散佈到各處, 並確認轉動順不順, 不順的話除非有卡到東西, 不然就是已經磨損了, 若再次清洗後還是一樣, 就該考慮更換軸承.
潤滑油的部份我是用汽機車用的機油, 黏度比針車油高, 但不到黃油那麼黏, 對於需要滑順又要承重的直排輪來說我覺得最適合.

完成後就可以組裝回去啦, 不過內襯軟墊就要等洗好晾乾了.

裝回去再測試, 就發現每個軸承滑順度已經不一樣了, 算啦, 下此保養再說~~(逃避)

接著保養小孩的鞋子, 嗯, 軸承用料較差些, 不過還好轉動都還算順暢, 等女兒溜得順後再考慮換較滑順的軸承.

中年大叔重拾直排輪之歷程-陪女兒練習之漫漫長路

大女兒買到直排輪後, 先在家練習站穩與緩慢前進, 過年時也帶回老家繼續練, 終於到能穩定站著與緩慢前進的程度後, 在週末有空就帶去家附近的空地練習.

這是距離買直排輪2個月後的情況, 勉強會前進, 不過有單腳出力的情況, 然後不會煞車...

期間也遇到其他溜直排輪的同伴, 有些技術已經很好, 有些則也只是會動的程度.


時間很快地來到購買後3個月, 進展不太快, 就更穩定些這樣, 然後繼續遇到各式各樣的溜友.


中年大叔重拾直排輪之歷程-大女兒購鞋之爸爸跟風

大女兒四歲多時, 去巨城看到其他人溜直排輪, 就開始不定時地說也想溜直排輪. 不過查詢資料都顯示, 除非體能特異, 不然大多建議女生5歲後再練,  此時腿部肌肉才有力把直排輪拉起來.

期間爸爸我也很想再溜直排輪, 這大概是我少數喜愛的運動之一,詢問高堂父母是否在老家還有看到我20年前買的直排輪,經老人家翻箱倒櫃後,找到的只有一袋護具,直排輪就此失蹤, 還蠻可惜的.

直到大女兒近五歲的某天,  再次到巨城時, 大女兒再次提到想溜直排輪, 經過媽媽的同意後, 就前往購買了,詢價後媽媽著實驚嚇不小, 經一再跟大女兒確認她想溜,之後也會願意練習後,就買下去了.

但, 小女兒看到姊姊脫鞋在試穿直排輪時, 也覺得她應該也會得到一雙, 急得也跟著脫了鞋, 跟她說它還太小沒辦法買給她之後, 就大哭了! 店員很給了她一個氣球棒後不哭了, 不過仍不願穿上鞋子.


大女兒選好鞋子後, 媽媽加買了一堂新手課程當場開始教學, 先在軟墊上練習, 小女兒就依然脫鞋狀態在旁邊湊熱鬧.
  

然後爸爸我呢心很癢,就很小心謹慎小聲地詢問老婆大人我可以不可以也買一雙,本預期是會被否決的, 畢竟大女兒一雙的價格已經讓老婆驚訝到,但沒想到老婆大人答應了!!!!!
考量年事已高(?), 避免軟鞋造成腳踝受傷, 因此還是選了雙硬殼鞋,樣式美醜就完全忽略啦,這個年紀有新鞋能溜已經很好了.


大女兒繼續練習時, 我在旁邊繞圈圈找回感覺, 畢竟上次溜是20年前的事情啊.
不過還蠻快就找回感覺,最後還抱著又眼紅爆哭的小女兒溜,讓老婆大人膽顫心驚.
大女兒練完軟墊上的部份後,就實際到木質地板上繼續後續的教學,當然免不了摔啦.


小女兒此時心情恢復平靜,終於肯把鞋子穿回,然後在旁邊看姊姊跌倒~(欸)


經過大約40分鐘,大女兒宣告沒力氣了,信心應該也被打擊到歸零,因此只好浪費20分鐘的課程時間,提早結束回家.

之後的兩週,爸爸我整個超熱衷,連上班都帶去溜,中午吃飯時還表演上下樓梯給同事看,嚇到沒溜過的同事.


至於新直排輪好不好溜, 坦白說無從比較, 上一雙是20年前買的, 在之後出車禍, 膝蓋開過刀後就沒溜了, 也早已忘了當時的感覺, 總之理論上應該是比當年的好溜吧~

2013年11月12日 星期二

調整ESXi5.5的硬體要求限制

硬體要求檢查僅在安裝時進行, 因此於安裝時修改即可避開, 安裝好之後能不能正常運作就不得而知, 不過其實安裝時載入運作的系統其實跟要安裝的系統根本一樣, 所以基本上你能看得到安裝畫面就代表基本上的運作應該沒有問題.


  1. 開始安裝時的第一個畫面不要管他, 按ALT+F1用root與無密碼直接登入
  2. cd /usr/lib/vmware/weasel/utils
  3. 找到一個叫做upgrade_precheck.py的檔案, 這是我們的目標
  4. 先刪除掉 upgrade_precheck.pyc, 這是一個複製檔
  5. 因為一些系統旗標的關係, 無法修改我們要動手腳的檔案, 且此精簡OS沒有修改旗標的執行檔, 故用另一種手法處理掉.
    1. mv upgrade_precheck.py upgrade_precheck.py.old 
    2. cp upgrade_precheck.py.old upgrade_precheck.py
  6. 使用vi 編輯目標檔案, 應該可以找到錯誤訊息的前幾個關鍵字, 像是CPU_CORES、MEMORY_SIZE之類的,找尋第二次出現此關鍵字的地方, 修改需求值例如XXX_MIN= ? 之類的, 存檔離開
  7. ps -c | grep weasel 找到正在執行中的安裝指令, kill掉
  8. 此時ALT+F2會重新執行安裝程式, 應就能順利安裝。
附註: ESXi 5.5 hypervisor OS 就要吃掉1095MB的記憶體, 因此請不要試圖安裝於低於此記憶體大小的機器上,會慢得想揍人或運作不正常。

2012年12月24日 星期一

FreeBSD with vmtools in vsphere VM 收到shutdown guest沒有進行ACPI off關機的解決方式

修改 /usr/local/etc/rc.d/vmware-tools.sh, 加上紅色字串部分即可


# Start the guest OS daemon
vmware_start_guestd() {
  cd "$vmdb_answer_SBINDIR" && "$vmdb_answer_SBINDIR"/vmware-guestd \
    --background "$GUESTD_PID_FILE" --halt-command "/sbin/halt -p"
}

2011年7月20日 星期三

Vsphere啟用HA的cluster要調整網路時一定要記得先關閉HA

要調整網路時, 一定要記得把HA功能關掉, 不然很可能會發生慘劇: VM全都被shutdown了!!

原因是, HA功能中, 對於避免同時有兩個同樣的VM在運作, 自己發現斷線的那台ESX在預設上是直接將身上的VM都power off(也可設定成shotdown, 而雖可調整成維持power on, 但這樣就很有可能兩個同樣的VM同時運作中而造成衝IP等等問題)

而若調整線路時把ESX網路都斷掉, 那麼他們都會把自身的VM power-off/shutdown, 此時沒有其他台ESX能接手, 所以等於所有VM都被關機了.........

雖然HA是獨立於VC之外自行運作, 但調整線路時仍難保不會斷到ESX之間的連線, 故仍記得調整網路時一定要先關閉HA功能.

2011年7月7日 星期四

啟用vmware cluster的HA要注意的部份

vSphere4的HA要啟用, 除了大部分會注意到的之外, 還有很多很多因素都有可能導致啟用失敗, 或啟用成功但某台ESX重開機後又再度跟你抱怨HA啟動失敗, 因此稍微列一下要檢查的事項, 大致照明顯到比較難注意到的部份依序列出.

2011年7月5日 星期二

自製DNS load balance(正確說只有sharing)

前情提要: 因client DNS query是走UDP, 免費套件中比較好的load balance是HAproxy, 但只支援TCP, 所以只好自製. 作法大致上是用pf(pakcet filter)防火牆中的nat+rdr去達成分送後端的功能, 再配合table可動態增刪, 加上自製的一些shell script與一些小軟體, 即可做到DNS load balance server.

所需機器: 一台用作load balance server(簡稱LB), 三台DNS server(簡稱DNS-A, DNS-B, DNS-C), 當然後端要幾台是隨意...

架構: 類似NAT+private ip的網路


2011年7月4日 星期一

自動重啟動停掉的服務 shell script

rcd_service_mon.sh


程式碼:


#!/bin/sh
export PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:/root/bin


if [ "$1" = "local" ];
then
  rcd="/usr/local/etc/rc.d"
  service="$2"
else
  rcd="/etc/rc.d"
  service="$1"
fi


status=` $rcd/$service status|grep 'is not running' `
if [ "$status" ];
then
  echo "$1 is not running, auto restart..."
  $rcd/$1 start
fi

用法:
rcd_service_mon.sh service_name 或 rcd_service_mon.sh local service_name

例:
1. 對named作用: rcd_service_mon.sh named
2. 對 apache 2.2 作用: rcd_service_mon.sh local apache22

詳細解說:
簡單說就是把手動的事情變成自動, 程式自動呼叫rc.d下的啟動用shell script, 並加上 status以得知狀態, 然後過濾輸出確認是否為沒在運作的狀況, 若沒在運作就嘗試啟動之.

2011年7月3日 星期日

免費文字辨識軟體-JOCR

公司網址:EverRex Software
讀取來源皆為畫面抓圖, 不讀取檔案的.
另外需要配合安裝office 2003以上的 Document Imaging 功能, 建議將之選為全部由硬碟執行,
office 2003的安裝圖解步驟如下:

unix epoch time 用date指令轉換

epoch time 是unix常用的一種時間, 為自從1970/1/1 0:0:0 開始到指定時間
所經過的秒數, 但閱讀不易, 可透過下面的指令轉換

date -j -f '%s' 1273075362 '+%Y/%m/%d %H:%M:%S'

顯示結果為
2010/05/06 00:02:42

其中 
-j 不因執行此指令設定系統時間
-f '%s' 指定輸入的時間格式, 在此即為秒
1273075362 即為epoch time
'+%Y/%m/%d %H:%M:%S' 顯示的格式



被freebsd 7.X以前的版本的fdisk寫過dd(dangerously dedicated)的硬碟處理

昨日幫朋友重灌起來的系統在其他硬碟上重新建立資料碟, 發生了fdisk那關寫入成功但再次讀取卻啥都沒有的狀況,
經過一夜(?)思考後, 想到應該是mbr有什麼東西被dd模式改寫掉造成, 解決辦法是使用
fdisk -B /dev/adX
並於第一個問題回應 y 之後問要不要寫入當然也要回 y, 即可重寫mbr的boot code, 之後再去sysinstall的fdisk就可以看到之前切出來的partition,
且/dev/adXs1 s2也都跑出來了.

其他失敗的嘗試有
1.dd if=/dev/zero of=/dev/adX bs=1m count=10
無效, 因為存取mbr磁區需另外跟硬碟溝通
2. fdisk -i /dev/adX
無效, 後來發現跟這東西完全無關...

開機狀態的snapshot的VM不建議到其他機器上使用

經測試, 開機狀態的snapshot很難在不同型的機器上使用, 會出現cpu type要求不合的狀態, 然後該VM就被停在一個暫停模式下怎樣也開不起來, 調整什麼cpu mask等等都沒有用, 且就算是搬移回做snapshot的機器上也開不了, 這是比較麻煩的部份, 若沒有進ESX console或ssh去直接調整該VM狀態, 那這個VM就等於陣亡了, 除非有更早的power off狀態的snapshot可用, 不然在GUI介面僅就只能刪除掉該VM一途.

除了將VM搬家會遇到這狀況之外, 另外就是clone VM時也要注意是否有power on的snapshot, 有的話clone過去後建議刪除掉以免誤觸此問題. 若一定要用該snapshot, 請於clone前先用該power on的snapshot開機, 然後關機, 做一次power off的snapshot, 這樣到其他機器就依然可以用該snapshot.

其實開機狀態的snapshot在不同型機器上要使用本來就很容易出問題(如cpu不同->指令集不同), 但為何搬回原機器仍無法使用就很奇怪了, 這部份算是碎碎唸吧.

可以當做ESX 的 iscsi share storage 軟體

免費:
Open-E 的 DSS V6 Lite (一個帳號可申請10個serial), 容量限制2TB

付費:
StorMagic的 SvSAN (前一個版本還不用錢說...哭哭~)

很流行的 FreeNAS跟OpenFiler就不要考慮了, 他們沒辦法處理多台同時存取同一個iscsi LUN的狀況, 很可能是因為沒有實作 lock - queue - release 的機制, 所以同時存取同一個LUN就會把檔案系統搞爛掉.

其他的iscsi software有興趣測試的話, 請至少掛兩個ESX上同一個iscsi LUN, 然後放個測試用的VM上去, 並作VMotion, 沒問題的話就算是初步通過了測試, 通常不支援的iscsi target會在這步爛給你看.

然後再放一個VM上去(與前一個VM不同台ESX), 兩個VM同時在寫入檔案動作時同時做VMotion, 然後VM關機, ESX重開機(重掛iscsi測試), 再開啟VM測幾次VMotion, 仍沒問題才能信任.