最近花了一段時間在研究怎麽把Google Drive (Google雲端硬碟)跟Zotero與Proxmox伺服器整合。整合之後可以運作，但是可能是因為檔案處理速度過慢或是Google Drive API配額的限制，最後都無法順利運作。這篇記錄一下到目前為止的研究進度。
(more...)建立一個應用系統已經不需要從基本的作業系統開始安裝起，現在流行的是使用虛擬應用範本(Virtual Appliance)來建立開箱即可用的應用系統。當然，在不同的虛擬機器管理器(Hypervisor，或稱為Virtual Machine Monitor, VMM)上，使用虛擬應用範本建立虛擬機器的操作方式都有所不同。以前我介紹的大多都是偏伺服器管理的Proxmox VE，這次要為大家介紹的在較為流行的VirtualBox中匯入OVF格式虛擬應用範本（在VirtualBox中，稱為虛擬應用裝置）的做法。
(more...)繼前幾天開始研究Proxmox VE 4.2，我也試著將Proxmox VE 4.2以VirtualBox虛擬機器架設，並且測試看看新的虛擬化技術lxc跟新的高可用叢集Proxmox VE HA Manager，然後看看有沒有其他的功能好用。結果很遺憾，我未能順利成功使用這些功能。我想在這邊記錄一下這些失敗的過程，也許未來的我知道怎麼操作的話，也許看了會有些不同的感觸吧。
(more...)最近發現Proxmox VE已經推出了4.2版，跟我主要使用的3.2跟3.4已經相差已久。4.2版不僅採用了較新的Sencha Ext JS 6，而且還新增了很多功能。我想一邊在回顧Proxmox VE從3.4改版的內容之外，也一邊在這裡做個記錄。
(more...)Proxmox VE預設採用qcow2作為虛擬機器的硬碟格式，如果要改用vmdk格式的話，建立虛擬機器時就要調整cache的設定為「Write through」才能讓虛擬機器正常開啟。
經過多台虛擬機器的架設，我發現以vmdk作為硬碟影像檔格式架設的虛擬機器總是有較好的執行效率與壓縮率，不論是VirtualBox還是Proxmox VE都是如此。
而且qcow2預設不開啟動態配置模式，因此創建影像檔時，檔案大小就會是設定的硬碟大小。例如我建立一顆80GB的硬碟，即使尚未安裝任何作業系統，qcow2硬碟影像檔依然會佔實體硬碟80GB的空間。相較之下，vmdk或是設定了動態配置的vdi格式，一開始的檔案大小通常不會超過10MB，開始安裝作業系統、增加檔案之後，影像檔才會逐漸變大。
再考量到現在很多可以直接掛載vmdk的工具，例如WinMount (也可以掛載vdi，但這是一個付費軟體)，這樣子要從備份資料中取回需要的資料也很方便。
總而言之，VMware不愧是虛擬技術界的龍頭老大，他們家的vmdk的確是比較好。
我們可以用預設值建立好虛擬機器，而虛擬機器的硬碟是用vmdk格式。但是這時候開啟虛擬機器時，卻會發生類似以下錯誤訊息：
「TASK ERROR: start failed: command '/usr/bin/kvm -id 106 -chardev 'socket,id=qmp,path=/var/run/qemu-server/106.qmp,server,nowait' -mon 'chardev=qmp,mode=control' -vnc unix:/var/run/qemu-server/106.vnc,x509,password -pidfile /var/run/qemu-server/106.pid -daemonize -smbios 'type=1,uuid=eece4916-f5e4-49de-a043-d2e77af96a53' -name test-vmdk -smp '1,sockets=1,cores=1,maxcpus=1' -nodefaults -boot 'menu=on,strict=on,reboot-timeout=1000' -vga cirrus -cpu qemu64 -m 512 -k en-us -cpuunits 1000 -device 'piix3-usb-uhci,id=uhci,bus=pci.0,addr=0x1.0x2' -device 'usb-tablet,id=tablet,bus=uhci.0,port=1' -device 'virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3' -iscsi 'initiator-name=iqn.1993-08.org.debian:01:0a39bcb174' -drive 'if=none,id=drive-ide2,media=cdrom,aio=native' -device 'ide-cd,bus=ide.1,unit=0,drive=drive-ide2,id=ide2,bootindex=200' -drive 'file=/var/lib/vz/images/106/vm-106-disk-1.vmdk,if=none,id=drive-ide0,format=vmdk,aio=native,cache=none,detect-zeroes=on' -device 'ide-hd,bus=ide.0,unit=0,drive=drive-ide0,id=ide0,bootindex=100' -netdev 'type=tap,id=net0,ifname=tap106i0,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown' -device 'e1000,mac=FE:CE:E5:CC:F3:C4,netdev=net0,bus=pci.0,addr=0x12,id=net0,bootindex=300' -machine 'accel=tcg'' failed: exit code 1」
這是因為在KVM虛擬技術中，預設快取寫入硬碟的方式為「Default (No cache)」，但是vmdk必須使用「Write Through」設定，因此只要調整硬碟快取寫入方式就可以解決這個問題。
建立虛擬機器的時候，在設定硬碟的這一個步驟中可以找到快取寫入的設定。(註：Proxmox VE不同版本在這一部上有很大的不同，這是3.4的版本) 預設是使用「Default (No cache)」，請把他修改成「Write through」即可。
其實上面的Bus/Device改成VIRTIO的話，一般來說效能會更好，因為這是虛擬裝置原生的通道，而非模擬出來的IDE或SATA。
如果是已經建立完成的虛擬機器，那也可以修改硬碟的相關設定。首先我們先開啟該虛擬機器的硬體頁面(hardware)，找到vmdk的那一顆硬碟。
選擇該硬碟，按下編輯按鈕(edit)。
在這邊修改硬碟設定。讓我們把原本的「Default (No cache)」設定改成「Write through」，然後按下OK。
這樣子就能夠正常啟動vmdk囉。
我是在自己電腦上以VirtualBox架設Proxmox VE來測試。在這種情況下，一般來說是不能啟動KVM的。這時候得要在「Options」中關閉「KVM hardware virtualization」選項，然後就能順利開啟。當然，這種情況下只能測試用，不能運作實際的作業系統。
如果我們虛擬機器已經是以qcow2架設了，那難道就沒辦法使用vmdk的好處嗎？
別擔心，我們可以用qemu-img convert指令可以讓你把qcow2格式轉換成vmdk格式。首先我們要先切換到映像檔所在的目錄，Proxmox VE存放在local的資料夾，路徑為：
/var/lib/vz/images/[VMID]/
如果虛擬機器的VMID為106，則路徑為：
/var/lib/vz/images/106/
qemu-img convert指令用法如下：
$qemu-img convert -f qcow2 –O vmdk vm-106-disk-2.qcow2 vm-106-disk-2.vmdk
硬碟越大，轉換所需要的時間越久。轉換完成之後，可以看到原始的qcow2大小為33GB，而轉換成vmdk之後只剩下4.1MB。這就是vmdk的優勢。
如果要運作虛擬機器的話，要記得在虛擬機器的硬體(hardware)中把硬碟改為轉換後的vmdk那一顆硬碟，並且設定快取寫入為「Write through」，就可以正常開啟囉。確認運作正常之後，原始的qcow2就可以刪除了。
Proxmox VE使用的KVM，以及VirtualBox這兩種虛擬化技術都有提供對vmdk的相容。因此我們不僅可以用Turnkey Linux提供的虛擬應用範本，也能夠在VMware的Virtual Application???找到其他的虛擬應用範本。就算是容器虛擬化技術OpenVZ，也能用一些比較複雜的步驟將虛擬機器轉換成vmdk來輸出(雖然是這樣想，但其實難度跟P2V一樣，並沒有真的如上面用qemu-img轉換來得容易)。如果沒有特別的考量的話，以vmdk架設傳統的虛擬機器應該是不二首選，不過這還是無法跟容器虛擬化的OpenVZ與Docker相比就是了。
(more...)這篇發佈我在2014年6月底的「雲端科技與圖書館行動服務研習班」中課程「雲端平台基礎設施建置實務──DLLL-CIAS介紹」的課程投影片。
This article is the slide of my course “Cloud Technology and Library Mobile Service Workshop” in July, 2014. Finally is my thought of this workshop.
DLLL-CIAS是政大圖檔所數位圖書館與數位學習實驗室中我所開發的開放原始碼雲端平台方案。主要目的是希望能夠讓經費不多的中小型單位也能夠用現有伺服器資源架設好用的IaaS雲端平台。其他介紹請看「DLLL-CIAS雲端平台架設與使用專題目錄」。
另外值得一提的是，這篇投影片是一開始是以Google Drive投影片製作。
雖然Google Drive投影片製作起來並不如Power Point一般的精緻（另一方面也是因為這個版本是供列印用的，所以特別以高對比黑白相間的範本製作），但是Google Drive投影片製作功能卻是相當足夠使用。更重要的是，Google Drive的協同製作跟註解(comment)完全贏過Windows的OneDrive。
這學期我大量使用Google Drive的協同編輯功能，像是跟人一起編修論文計劃書、規劃投影片內容，這份投影片也是從Google Drive開啟編輯起。我先規劃投影片大綱，記錄每一張投影片欲講述的內容，以及相關參考資料的來源。然後各張投影片的內容則是跟實驗室各位助理一起填寫資料，接著我再重整資料內容。當投影片內容確定之後，最後我再下載成Power Point檔案作進一步的排版美化。
最後排版而成的版面就是這樣子了。
使用Google Drive製作投影片跟Power Point製作投影片有幾個重點差異需要注意：
有機會我再詳細聊一下Google Drive協同編輯的心得吧。
這份投影片發佈之後，研習班的工作總算是告一段落了。
這次研習班跟其他研習班最大的差異，就是在於有很多實作的內容，而不是一直坐著聽老師授課。這次研習班主要兩個實作課程，一個是KALS合作標註閱讀學習，另一個則是這個DLLL-CIAS實作，這兩個實作都讓我煞費苦心。DLLL-CIAS要架設許多虛擬機器伺服器這點顯而易見，而KALS要弄到讓學員能夠在系統上順利操作，這背後其實也修改了許多細節。之前去IMLF 2014時就已經拖延了許多工作，然後之後投入在這研習班上，課程的部分就有點顧不住了，真是對不起老師啊。
雖然期末與這研習班整個像是災難一樣鋪天蓋地而來，但最後總算能夠過去。上課過程中有些兵荒馬亂，感謝各位助理大力相挺，沒有你們我一個人真的完成不了這些東西，這也包括了之前寫的幾篇DLLL-CIAS的細部操作文章。
研習班上課過程中，我本來以為這麼硬的內容，應該會讓大家聽到一片瞌睡。結果時候聽完還蠻多人跑來跟我比較他們圖書館使用的VMware方案之間的差異，也有平時不碰技術的人跟我表達這堂課讓他獲益，有些人甚至想要在自己家裡架起這套方案。即使是客套話，我也覺得很開心。
希望下次能夠吸取這次的經驗，然後再帶給大家更好的課程內容吧。
(more...)這篇記錄一下最近研究RemoteApp的記事。由於不是很正式的教學，所以格式上比較隨意，請大家見諒。
This article is the memo about RemoteApp research.
在講RemoteApp之前，我先講一下什麼樣的情況，個人會須要用到這種方案。
現代人的生活很多時候會跟多臺電腦打交道。以我為例，先不論機房有一堆孩子(伺服器)要顧，我自己在實驗室有一臺桌機、平時在外面移動時則是有一臺筆電，回到宿舍時也還是用那一臺筆電工作。因此我自己就有兩臺電腦在使用。
在這個情景底下，我主要使用的是實驗室效能比較好的桌機，而筆電通常是利用遠端桌面連線回到桌機操作。大部分的檔案也是存放在桌機為主。
Windows的遠端桌面連線是Windows少數幾個偉大的設計之一。在網路頻寬允許的情況下，可以讓你的連線裝置彷彿就像是在遠端操作一樣。
但是實際上，遠端桌面連線因為功能太過龐大，有時候我只是想要使用某個應用程式，像是Photoshop，這時候我還是得連線到整個遠端桌面，然後才能開啟Photoshop操作，說來也是一種麻煩。
這就讓我興起了「我可只連線到遠端其中一個應用程式嗎？」的想法，因此就開始進行RemoteApp的小小研究。
這篇所講的RemoteApp，一開始是指Windows伺服器版本提供的功能。RemoteApp是遠端桌面連線的延伸應用，自從Windows Server 2008 R2之後才能夠使用。RemoteApp的特色在於透過遠端桌面連線的控制，把要顯示的資訊傳送到客戶本地端，由客戶本機端的Windows來負責產生畫面。
實作時是由伺服器端提供RemoteApp連線設定檔.rdp、或是包裝成.msi的安裝檔案，然後交給客戶端去做安裝與配置，例如放在桌面上提供使用者點選。這個RemoteApp連線設定檔本身已經包含了遠端伺服器的連線位置與登入資訊，以及要開啟的應用程式設定。客戶端只要開啟這個連線設定檔.rdp，等待連線，然後就會出現有如本機上運作的RemoteApp。
RemoteApp是伺服器類型的Windows才有提供的功能，但是Windows 7之類的個人電腦也可以作為RemoteApp伺服器。做法是使用RemoteApp Tool。
RemoteApp Tool適用於Windows XP SP3、Windows 7、Windows 8，幾乎目前常用的Windows都可以運作。
RemoteApp Tool不需要安裝，開啟之後就能夠設定要提供連線的應用程式。我自己馬上就建立了一個Line試試看。
從Properties裡面可以設定應用程式的執行細節，最主要的是設定應用程式的執行路徑 Path。設定好RemoteApp之後，接著你可以使用Generate RDP file產生.rdp的遠端連線設定檔，再傳送到客戶端來連線。客戶端只要開啟.rdp，就會連線到這臺伺服器，然後開啟Line的應用程式。
雖然設定很簡單，但實際上運作時卻有許多問題。第一個是遠端連線速度不是很通順。開啟RemoteApp的時候，基本上就跟開啟遠端桌面連線一樣，但還要加入開啟應用程式的時間，因此連線時的時間會有不小的延遲。特別是當我們習慣開啟本地端的應用程式之後，再來跟RemoteApp開啟速度相比，就會覺得不甚理想。
然後是我使用Line的時候遇到了不少問題。也許是Line本身用了特殊的框架，導致開啟時不太順暢之外，一使用輸入法就會造成應用程式當機。
此外，這個RemoteApp Tool的另一個問題在於一次只能一個session連線。就跟一般Windows使用遠端桌面連線一樣，RemoteApp連線時就是佔了一個使用名額。當有別人開啟RemoteApp的時候，就算我來到伺服器的本地端，我看到的會是一個需要登入的畫面。而當我登入的時候，別人正在使用的RemoteApp則會被踢出去。
如果這些電腦都只有你個人使用的話，這倒沒什麼問題。但是在企業內希望使用RemoteApp共享安裝軟體的話，這問題就相當致命。由於Windows Server 2008等伺服器版本可以提供同一帳號多重遠端桌面，所以才能夠提供RemoteApp正常使用吧。不過如果Windows 7強制設定單一帳號多重登入的話，那也許也能夠提供一樣的功能也說不定。我稍微找了一下，不同的Windows版本有不同的設定方式：
但是因為RemoteApp感覺還是不太好用，所以我就嘗試找找看有沒有其他的替代方案，然後找到了Winflector。
Winflector是一個類似RemoteApp的替代方案。免費版本可以提供兩個客戶端同時連線。
一開始一樣是先安裝Server版本，安裝完之後要重新開機。然後接著設定應用程式，這些設定類似RemoteApp。再來設定可以登入的使用者的帳號與密碼，這部分跟Windows的帳戶是分開獨立的。另外連接埠要修改掉被佔用的80，改為其他連接埠之後，才能正常連線。
Winflector並不會產生像是RemoteApp這樣的連線設定檔，客戶端必須開啟Winflector客戶端程式，輸入伺服器端的IP連線資訊，接著就能夠在Applications看到伺服器端提供的應用程式，點選兩下就能夠直接開啟了。
開啟應用程式的速度不僅很快，而且輸入法、剪貼簿、視窗整合等操作都很流暢，彷彿真的就像是在本機端運作的程式一樣。而Winflector的連線也不會佔用遠端桌面連線的名額，不會把本機端使用者踢掉。
只是有幾點要注意的是事情：
此外，Line開起來會一片空白，還是無法使用。
總而言之，Winfector意外地讓我很滿意，於是我最近會試著在桌機常駐Winfector的服務，讓筆電來連線使用看看。再試試看有沒有什麼問題。
個人使用的話，Winfector應該就能夠滿足需求了。就算是遠端檔案無法直接儲存在客戶端，也可以利用Dropbox來同步檔案。可是要在團隊裡面使用的話，這樣子的架構還不能算是完整。
為什麼團隊會需要使用RemoteApp？最大的原因仍然是因為軟體授權不足，或是軟體需要在高等級機器上運作，不方便安裝在筆電等效能較差的電腦上。
現在學校大多是使用Citrix的XenApp方案，這個方案其實也挺不錯的。它類似RemoteApp，但是運作RemoteApp的伺服器是以XenServer建構而成的Windows虛擬機器，而非實體的Windows。在每次要使用XenApp的時候，伺服器端會自動建立一個可以運作應用程式的虛擬機器，提供XenApp連線。然後在關閉XenApp之後把虛擬機器移除掉。因此每次開啟XenApp，看到的都會是預設軟體的樣子，使用者無法自訂軟體。
在檔案傳輸方面，XenApp會在連線時，把使用者本機端的硬碟作為網路上的芳鄰連線過去。使用XenApp開啟檔案時會看到磁碟機有幾個是網路上的硬碟，這才是本機端的硬碟。至於XenApp裡面看到的桌面跟C磁碟機都是虛擬機器本身的裝置，關閉XenApp之後就會消失。
在這樣的架構下，XenApp一樣有連線人數的限制，端看學校購買的授權數量，決定可以同時可以使用的連線人數。另一方面，XenApp的架構也是一個付費方案，所以就不是我的優先選擇。
說到遠端桌面，大家是不是太專注在Windows上，而忘記了Linux本身就有強大的X Window呢？
其實X Window所提供的X11 Forwarding本身就能達到「只開啟應用程式」的效果。這篇SSH X11 Forwarding介紹的很詳細當然，鳥哥則是對X Window System則有較詳細的介紹鳥哥則是對X Window System則有較詳細的介紹。我也在Ubuntu上運作成功。做法是：
雖然步驟繁多，但是能在Windows開啟Linux的應用程式這點還是挺令人感到新奇的。不過實際上操作一下，發現問題有幾點：
儘管如此，由於X Window並沒有限制連線數量，只要硬體效能足夠，應該可以提供大量使用者連線操作才是。
如果要走X Window的方式提供遠端應用程式服務，那另一個問題在於，我們平常用的還是Windows的應用程式，而不是Linux的應用程式。
事實上，Linux有許多可以運作Windows應用程式的方法，以下兩個方案是最常見的做法：
這兩種方案都是使用轉換技術，講Windows的架構轉換成可以在Linux執行的環境，以在Linux開啟Windows的應用程式。雖然Wine是開放原始碼的軟體，但是使用上似乎有諸多問題。不同Wine版本、不同的Linux發佈版、不同的Windows應用程式版本之間對應會有許多問題。反觀CrossOver似乎評價就比較正面（也許是因為付費了，稱讚一下也好？）。
如果有這些軟體搭配的話，我在想可能的架構就可以變成：
這樣子理想上就能達到不限人數的遠端應用程式的目標。不過我們還有其他問題還沒解決，一個是輸入法，另一個是檔案傳輸。輸入法的部分，這是另一個世界，我還得去研究看看；但是檔案傳輸的部分則比較簡單，我想可以用SFTP或是ownCloud來解決。
最簡單的做法是使用SFTP連線到Linux伺服器。也就是說，連線到Linxu伺服器時，我們同時使用了三種服務：
這三種都是走SSH連線，這樣做最單純。
總歸上述，目前比較可能可以使用的方案有兩個：
不論是那一種方案，其實都不甚理想。市面上也有許多付費的VDI應用方案，但我還是希望先能找到以自由軟體發佈的替代方案為主。
再等等看吧。
(more...)當ownCloud掛載NFS時，資料夾權限會被設定為777，違反ownCloud所限制的770權限，而導致ownCloud無法順利運作。本篇文章修改了ownCloud的util.php來避免權限檢查問題。
When mounting NFS for ownCloud, the mounted folder’s permission will be changed to 777. Due to security reason, 777 permission is not allowed by ownCloud and it will not work while this permission. This article try to modify util.php to disable the permission check and let ownCloud work properly.
ownCloud是一種類似Dropbox的開放原始碼網站系統，我們最近也嘗試在自己單位中架設ownCloud來提供雲端硬碟的服務。
ownCloud的系統基礎是由PHP與MySQL組成，但是對於已經具備雲端平台的我們來說，當然不會從頭開始架設，而是直接選擇Turnkey Linux的ownCloud OpenVZ虛擬機器來架設，ownCloud版本是4.90.8。
用Turnkey Linux架設虛擬機器很快，首先先把樣板上傳到Proxmox VE，開啟Console或用SSH登入到虛擬機器上，做一些密碼設定及取消Turnkey Linux自動更新的設定之後，就能夠用網頁直接連接了。
以下是啟用ownCloud之後遇到的問題與解法。
由於ownCloud運作於虛擬機器上，我不想讓單一虛擬機器擁有過大的檔案，造成備份及還原時的困擾。因此我決定將ownCloud儲存使用者資料的資料夾掛載到另外的NFS伺服器上。整個架構圖如上圖所示，但是細節部分需要注意的事情很多，以下一一敘述。
Proxmox VE這種OpenVZ虛擬機器(container)要掛載NFS，必須在主機端(host)為虛擬機器開啟nfs:on的設定。細節請看我之前寫的介紹。
至於ownCloud擺放使用者資料的資料夾，Turnkey Linux預設的位置是在「/var/www/owncloud/data」。因此只要掛載這個資料夾即可。
接著開啟ownCloud的時候就會遇到上圖的錯誤，錯誤訊息如下：
Data directory (/var/www/owncloud/data) is readable for other users
Please change the permissions to 0770 so that the directory cannot be listed by other users.
這是因為掛載NFS之後，data資料夾的權限會被改成777，而非預設的700。基於安全性限制，在data資料夾為777的權限之下，ownCloud將無法正常運作。
我們試著找了些方法，可是並沒辦法順利迴避資料夾權限檢查的問題。最後索性直接修改ownCloud的程式碼來略過權限檢查的問題。
最後我們找到了ownCloud權限檢查的位置，這是在/var/www/owncloud/lib/util.php當中的一段敘述。我們將util.php關於資料夾權限檢查的部份註解掉之後，ownCloud就能夠順利運作了。
util.php已經上傳到GitHub，註解的行數介於241行～283行，請自行下載，替換原本ownCloud的/var/www/owncloud/lib/util.php吧。
安裝ownCloud的過程中，除了這個NFS的問題之外，我們還遇到另一個伺服器位址需要加上連接埠才能正常使用的問題。但那個問題似乎是因為我們使用了反向代理伺服器(reverse proxy)，導致同步用戶端不是正常連線到ownCloud，而只是連到反向代理伺服器，因此無法運行。
另外還有一個問題是在於同步工具上。ownCloud的桌面版同步工具提供了Windows (Windows XP, Vista, 7 and 8, 32/64 bit)、Mac (Mac OS X 10.6 or better, Intel 64 bit)、Linux (CentOS/RHEL, Fedora, openSUSE, Ubuntu, Debian，圖示比較華麗)。但是ownCloud行動版本的卻要付費，iOS的費用是最低的$0.99美金，Android的費用則是NT$30。
雖然也可以在手機上開啟網頁版本，但是似乎沒有做行動裝置的最佳化，所以看起來非常像桌面版本，不太容易使用。這個問題不知道有沒有替代方案呢？
(more...)最近我們在大規模地遷移Proxmox VE中的虛擬機器，其中KVM類型的虛擬機器在轉移時常常會遇到許多各種不同的問題，像是硬碟設定或是光碟設定錯誤。我將這些問題的處理方式記錄如下。
When I migrated KVM virtual machines at Proxmox VE, I encountered many problems, such as hard drive or CD/DVD drive misconfigured. This article I describe the solutions for those problems.
最常見的就是硬碟驅動配置錯誤。有段時間我常常先在VirtualBox建立虛擬機器，再轉移到Proxmox VE。這種轉移方式通常只是上傳最重要的硬碟映像檔，像是vmdk或是qcow2 (但是在VirtualBox上運作qcow2的效率其差無比就是了)。
如果只是轉移硬碟映像檔的話，必須特別注意他們的硬碟驅動設定必須一致。如果當初建立的時候使用IDE，在轉移之後建立也就必須使用IDE。
舉例來說，這是VirtualBox的操作介面，你可以看到這台虛擬機器的硬碟是被設定成SATA。
但是在Proxmox VE上，這臺虛擬機器的硬碟卻被設成了IDE。在Windows XP或是Linux卻使用LVM的情況下，往往會造成開機失敗。
因此，在建立虛擬機器的硬碟時，必須特別注意其使用的硬碟驅動器。
如果你已經將硬碟安裝成錯誤的硬碟驅動器，那Proxmox VE網頁介面上是無法直接修改。我建議是使用SFTP直接操作伺服器的檔案系統，作法如下：
這樣就完成了。
前一種情況大多是只轉移硬碟映像檔的時候，這一種情況則是使用Proxmox VE的備份功能vzdump匯出虛擬機器之後、再匯入新的Proxmox VE的情況。細節作法可以看我寫的另一篇「Proxmox VE用備份(vzdump)與還原(restore)複製虛擬機器」。
使用vzdump的時候，虛擬機器的設定會鉅細靡遺地被保留，並還原到新的虛擬機器環境中。問題是在於新的環境中可能使用的Storage ID（儲存空間名稱）不一樣，就會導致無法正常開機的問題。
以上圖為例，當Storage設定錯誤時，發生錯誤訊息就會是：
TASK ERROR: storage 'proxmox-nas' does not exists
這是因為這個Proxmox VE虛擬機器環境下沒有名為「proxmox-nas」的Storage的緣故。
解決方式很簡單，就是把掛載的映像檔取消掉就好了。
這個問題警惕了我們，如果虛擬機器設定完畢之後，記得取消掛載安裝時使用的映像檔設定。
每次遇到虛擬機器的各種問題，我常常聽到的抱怨都是：「為什麼要用這種東西？你就不能裝在實體機器上嗎？」就我個人來看，這種抱怨是一種誤解。
如果你仔細看看這篇敘述的兩種問題，其實是很容易類比到實體機器上──就像是拿著SATA線去接一顆IDE硬碟，或是在光碟機裡面指定放進一片不存在的光碟。儘管實體機器操作中，有些常識的網管可能不會卡在這麼奇怪的問題上，但這的確是可以從實體機器類推到虛擬機器上的情況。
我想說的是，其實虛擬機器的設定跟實體機器沒有這麼大的差別，但比實體機器設定更為容易。以硬碟控制器的問題來說，實體機器的情況可能是一顆舊的IDE硬碟要裝到新的伺服器上，如果伺服器只剩下SATA線，那要裝IDE硬碟還必須搭配張SATA to IDE的轉接卡才能使用，安裝時還得考量到轉接卡阻礙線材空間等問題，處理起來挺費工夫的。但是虛擬機器只要設定幾項參數即可完成調整，方便許多。
虛擬機器除了有助於網管之外，快速還原的能力還能夠用於程式開發上。在「成为一个PHP专家：缺失的环节」一文中建議PHP時使用虛擬機器建立個Linux，以方便隨時重新開始或還原到程式開發的某個狀態。這些都是非常有用的功能。
因此，我會對VirtualBox、Proxmox VE、OpenVZ、KVM等多種開放自由的技術抱持最高的敬意，並繼續擁抱虛擬機器。
(more...)最近我處理的Proxmox VE因為Cluster眾多功能異常，導致很多功能都無法正常使用。這次遇到的問題是備份時被鎖住的問題，解決方法是重新啟動Proxmox VE所有的服務，然後將該節點設為expected。
When Proxmox VE Cluster cannot work properly, the backup function maybe disabled, due to permission is locked to read-only. This article describes how to repair this problem.
我在node（Proxmox VE Cluster中運作的一台伺服器，稱為node）名為「proxmox-master-c」為KVM類型的VMID 260虛擬機器進行備份。遇到的錯誤如下：
INFO: starting new backup job: vzdump 260 --remove 0 --mode snapshot --compress gzip --storage <STORAGE ID> --node <NODE>
INFO: Starting Backup of VM 260 (qemu)
INFO: status = stopped
INFO: update VM 260: -lock backup
INFO: unable to open file '/etc/pve/nodes/proxmox-master-c/qemu-server/260.conf.tmp.3682' - Permission denied
ERROR: Backup of VM 260 failed - command 'qm set 260 --lock backup' failed: exit code 2
INFO: Backup job finished with errors
TASK ERROR: job errors 關鍵在於紅字的地方。要備份時，Proxmox VE會寫一個暫存檔在虛擬機器設定檔的目錄，但是錯誤訊息顯示該目錄有權限問題，只能讀取不能寫入(read-only)。
這是因為Proxmox VE加入了Cluster中，並啟用了Proxmox Cluster file system (pmxcfs)。pmxcfs的特色其中有一項：
read-only when a node looses quorum
意思是，當Proxmox VE運作喪失了quorum元件時，Proxmox VE節點的虛擬機器設定會被轉換成read-only。儘管虛擬機器本身是可以正常運作的，但是卻不能進行任何設定，包括備份。因為權限備份被鎖起來了。
而這個問題另一篇Wiki中有敘述。簡單來說，因為Cluster異常，quorum無法順利讀取，讓整個Cluster中的node彼此之間無法正常連線，導致每個node都只能看到自己的運作狀態，這時候node就會自動鎖起來。
以下方法是我摸索解決方案的一個過程，很多細節我不清楚，有幾台node可以如此解決，可是有幾台不行。我還沒有了解整個原因細節，在此只是記錄一下目前的解決方法。
根據wiki的介紹，最簡單的方式是在有問題的node上輸入指令：
# pvecm expected 1
但是當我要這樣做的時候，卻又有另一個錯誤訊息發生，告訴我cman並沒有正常啟動。我嘗試想要用「service cman start」，但是卻依然不能執行「pvecm expected 1」。
因此我決定參考Re-installing a cluster node的方法，先關掉所有相關服務，再開啟相關服務，最後再執行expected指令。我將這些指令建置成了expected.sh，可以從GitHub上下載，檔案內容細節如下：
#!/bin/sh
service pvestatd stop
service pvedaemon stop
service cman stop
service pve-cluster stop
service pve-cluster start
service cman start
service pvedaemon start
service pvestatd start
pvecm expected 1 執行的時候依然會遇到很多問題，quorum等待過時(time-out)的問題依然沒有改變，如下圖：
儘管如此，執行完之後，有一定機率可以正常啟用整個Cluster。
說是一定機率的原因是，有時候可能要重開機之後再執行一次expected.sh。但是這不一定每次都會成功，我試了好幾台，結果都不一樣。必須注意的是，重開機之後，虛擬機器不會正常地Start on boot，需要手動開啟。
其中有幾台因為網路交換器出了問題（ASUS的，真是堅若磐石）而導致quorum無法正常運作。更換交換器之後就正常運作了。
目前我手邊已經沒有需要做這樣修復的node，所以我接下來就不會繼續深入探究了。就做到這邊吧。
(more...)如果要讓OpenVZ架設的Linux虛擬機器掛載NFS(Network File System)，Host端必須先設定虛擬機器(container)的"nfs:on"。以下介紹詳細作法。
If you want to let OpenVZ container to mount NFS (Network File System), you have to enable "nfs:on" feature on host server first. Following is the details.
如果NFS用戶端設定正確（可以參考鳥哥的NFS用戶端設定教學），可是仍出現錯誤訊息：(Debian上的)
mount.nfs: No such device
或是錯誤訊息：(CentOS上的)
mount: wrong fs type, bad option, bad superblock on 10.9.5.95:/raid0/data/_NAS_NFS_Exports_/email-km,
missing codepage or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
這時候可能是因為OpenVZ尚未開啟NFS的功能的關係。
包括Proxmox VE在內，大部分OpenVZ虛擬機器(OpenVZ Container)在建立時都沒有開啟NFS的功能。如果要讓虛擬機器本身能夠掛載NFS目錄，請依照以下方法來開啟。
要進行設定之前必須先將虛擬機器關機。關機指令為：
# halt
首先先進入Proxmox VE的網頁管理介面，預設連接埠為8006，必須用https進入。
登入之後，找到該虛擬機器的Host伺服器，進入右上角的「Shell」介面。
Proxmox VE提供了Java Applet連線的主控介面(console)，可以在此直接以root身分操作Host端伺服器。
接下來要照OpenVZ的說明設定虛擬機器。該機器的VMID若是101，那麼開啟NFS的指令如下：
vzctl set 101 --features "nfs:on" --save; vzctl start 101
設定完成之後，虛擬機器會一起啟動。
這時候再開啟虛擬機器，掛載NFS的時候，指令就能正常執行。
參考鳥哥的Linux私房菜中NFS客戶端的教學，OpenVZ要使用NFS，通常必須先做以下設定：
Debian或Ubuntu系列請用apt-get安裝：
apt-get install nfs-common
CentOS或RedHat系列請用yum安裝：
yum install -y nfs*
NFS的掛載位置必須參考NFS伺服器的設定。每一台NFS伺服器設定都不一樣，特別是現在各家NAS使用自家作業系統之後，提供的路徑千奇百怪，我在這邊卡了許久，後來升級NAS的韌體才知道NFS掛載路徑。
舉例來說，NFS伺服器設定如下：
那麼NFS掛載的指令就是：
mount -t nfs 10.9.5.95:/raid0/data/_NAS_NFS_Exports_/cluod-rstudio-2013 /tmp/nfs
試著執行看看。如果沒有任何訊息，那就是順利成功了。
我在CentOS遇到以下錯誤訊息：
mount.nfs: rpc.statd is not running but is required for remote locking.
mount.nfs: Either use '-o nolock' to keep locks local, or start statd.
mount.nfs: an incorrect mount option was specified
那麼就必須先開啟rpcbind，指令為：
service rpcbind start
舊版本的CentOS會遇到這個問題。掛載時遇到的錯誤訊息如下：
mount.nfs: Connection refused
這版本的CentOS不是用rpcbind，而是用portmap。所以要先開啟portmap服務：
service portmap start
這樣就能夠正常掛載
修改 /etc/rc.local，加入剛剛測試成功的設定：
mount -t nfs 10.9.5.95:/raid0/data/_NAS_NFS_Exports_/cluod-rstudio-2013 /tmp/nfs
或是加上額外設定需要的「service rpcbind start」或「service portmap start」。
這樣就完成了。
(more...)
Comments