:::
顯示具有 虛擬機器 標籤的文章。 顯示所有文章

想用無限空間沒那麼容易!Google Drive與伺服器整合失敗記錄 / Solution to Integrate Google Drive with Services: not reliable

想用無限空間沒那麼容易!Google Drive與伺服器整合失敗記錄 / Solution to Integrate Google Drive with Services: not reliable

image

最近花了一段時間在研究怎麽把Google Drive (Google雲端硬碟)ZoteroProxmox伺服器整合。整合之後可以運作,但是可能是因為檔案處理速度過慢或是Google Drive API配額的限制,最後都無法順利運作。這篇記錄一下到目前為止的研究進度。

(more...)

快速建立開箱即用的系統!VirtualBox匯入應用裝置教學 / How to Import a OVF Format Virtual Appliance to VirtualBox

快速建立開箱即用的系統!VirtualBox匯入應用裝置教學 / How to Import a OVF Format Virtual Appliance to VirtualBox

image

建立一個應用系統已經不需要從基本的作業系統開始安裝起,現在流行的是使用虛擬應用範本(Virtual Appliance)來建立開箱即可用的應用系統。當然,在不同的虛擬機器管理器(Hypervisor,或稱為Virtual Machine Monitor, VMM)上,使用虛擬應用範本建立虛擬機器的操作方式都有所不同。以前我介紹的大多都是偏伺服器管理的Proxmox VE,這次要為大家介紹的在較為流行的VirtualBox中匯入OVF格式虛擬應用範本(在VirtualBox中,稱為虛擬應用裝置)的做法。

(more...)

Proxmox VE 4.2配置失敗記錄 / Failed to Setup Proxmox VE 4.2

Proxmox VE 4.2配置失敗記錄 / Failed to Setup Proxmox VE 4.2

image

繼前幾天開始研究Proxmox VE 4.2,我也試著將Proxmox VE 4.2以VirtualBox虛擬機器架設,並且測試看看新的虛擬化技術lxc新的高可用叢集Proxmox VE HA Manager,然後看看有沒有其他的功能好用。結果很遺憾,我未能順利成功使用這些功能。我想在這邊記錄一下這些失敗的過程,也許未來的我知道怎麼操作的話,也許看了會有些不同的感觸吧。

(more...)

Proxmox VE 3.4到4.2的更新資訊 / Promxox VE 3.4 to 4.2 Changelog

Proxmox VE 3.4到4.2的更新資訊 / Promxox VE 3.4 to 4.2 Changelog

image

最近發現Proxmox VE已經推出了4.2版,跟我主要使用的3.2跟3.4已經相差已久。4.2版不僅採用了較新的Sencha Ext JS 6,而且還新增了很多功能。我想一邊在回顧Proxmox VE從3.4改版的內容之外,也一邊在這裡做個記錄。

(more...)

Proxmox VE以vmdk作為虛擬機器的硬碟 / Use vmdk format as Virtual Machine's disk in Proxmox VE

布丁布丁吃布丁

Proxmox VE以vmdk作為虛擬機器的硬碟 / Use vmdk format as Virtual Machine's disk in Proxmox VE

pablo

Proxmox VE預設採用qcow2作為虛擬機器的硬碟格式,如果要改用vmdk格式的話,建立虛擬機器時就要調整cache的設定為「Write through」才能讓虛擬機器正常開啟。


用vmdk跑虛擬機器比較好 / It is better to run a Virtual  Machine based on vmdk image disk format

經過多台虛擬機器的架設,我發現以vmdk作為硬碟影像檔格式架設的虛擬機器總是有較好的執行效率與壓縮率,不論是VirtualBox還是Proxmox VE都是如此。

而且qcow2預設不開啟動態配置模式,因此創建影像檔時,檔案大小就會是設定的硬碟大小。例如我建立一顆80GB的硬碟,即使尚未安裝任何作業系統,qcow2硬碟影像檔依然會佔實體硬碟80GB的空間。相較之下,vmdk或是設定了動態配置的vdi格式,一開始的檔案大小通常不會超過10MB,開始安裝作業系統、增加檔案之後,影像檔才會逐漸變大。

image

再考量到現在很多可以直接掛載vmdk的工具,例如WinMount (也可以掛載vdi,但這是一個付費軟體),這樣子要從備份資料中取回需要的資料也很方便。

總而言之,VMware不愧是虛擬技術界的龍頭老大,他們家的vmdk的確是比較好。

Proxmox VE無法開啟vmdk格式虛擬機器的問題 / The error message while start virtual machine based on vmdk

image

我們可以用預設值建立好虛擬機器,而虛擬機器的硬碟是用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」設定,因此只要調整硬碟快取寫入方式就可以解決這個問題。

建立虛擬機器時調整硬碟設定 / The disk configuration while creating virtual machine

image

建立虛擬機器的時候,在設定硬碟的這一個步驟中可以找到快取寫入的設定。(註:Proxmox VE不同版本在這一部上有很大的不同,這是3.4的版本) 預設是使用「Default (No cache)」,請把他修改成「Write through」即可。

其實上面的Bus/Device改成VIRTIO的話,一般來說效能會更好,因為這是虛擬裝置原生的通道,而非模擬出來的IDE或SATA。

修改既有的虛擬機器 / Revise the disk disk configuration for existed Virtual Machine

image

如果是已經建立完成的虛擬機器,那也可以修改硬碟的相關設定。首先我們先開啟該虛擬機器的硬體頁面(hardware),找到vmdk的那一顆硬碟。

image

選擇該硬碟,按下編輯按鈕(edit)。

image

在這邊修改硬碟設定。讓我們把原本的「Default (No cache)」設定改成「Write through」,然後按下OK。

image

這樣子就能夠正常啟動vmdk囉。

如何在沒有CPU虛擬化技術支援下開啟KVM? / How to run KVM virtual machine without CPU Virtualization Technology?

image

我是在自己電腦上以VirtualBox架設Proxmox VE來測試。在這種情況下,一般來說是不能啟動KVM的。這時候得要在「Options」中關閉「KVM hardware virtualization」選項,然後就能順利開啟。當然,這種情況下只能測試用,不能運作實際的作業系統。

要如何將qcow2轉換成vmdk? / How to convert qcow2 format to vmdk?

image

如果我們虛擬機器已經是以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

  • vm-106-disk-2.qcow2:來源的檔案
  • vm-106-disk-2.vmdk:輸出的檔案
  • -O是大寫的o,不是0

image

硬碟越大,轉換所需要的時間越久。轉換完成之後,可以看到原始的qcow2大小為33GB,而轉換成vmdk之後只剩下4.1MB。這就是vmdk的優勢。

如果要運作虛擬機器的話,要記得在虛擬機器的硬體(hardware)中把硬碟改為轉換後的vmdk那一顆硬碟,並且設定快取寫入為「Write through」,就可以正常開啟囉。確認運作正常之後,原始的qcow2就可以刪除了。


結論:虛擬化技術的相容性 / Conclusion: The Compatibility of VMDK image format

Proxmox VE使用的KVM,以及VirtualBox這兩種虛擬化技術都有提供對vmdk的相容。因此我們不僅可以用Turnkey Linux提供的虛擬應用範本,也能夠在VMware的Virtual Application???找到其他的虛擬應用範本。就算是容器虛擬化技術OpenVZ,也能用一些比較複雜的步驟將虛擬機器轉換成vmdk來輸出(雖然是這樣想,但其實難度跟P2V一樣,並沒有真的如上面用qemu-img轉換來得容易)。如果沒有特別的考量的話,以vmdk架設傳統的虛擬機器應該是不二首選,不過這還是無法跟容器虛擬化的OpenVZ與Docker相比就是了。

(more...)

DLLL-CIAS介紹 / DLLL-CIAS Introduction

DLLL-CIAS介紹 / DLLL-CIAS Introduction

image

這篇發佈我在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是什麼? / What is DLLL-CIAS

DLLL-CIAS是政大圖檔所數位圖書館與數位學習實驗室中我所開發的開放原始碼雲端平台方案。主要目的是希望能夠讓經費不多的中小型單位也能夠用現有伺服器資源架設好用的IaaS雲端平台。其他介紹請看「DLLL-CIAS雲端平台架設與使用專題目錄」。

課程投影片 / Course Slide

Google Drive的原始版本投影片 / Slide Original Version on Google Drive

另外值得一提的是,這篇投影片是一開始是以Google Drive投影片製作。

image

雖然Google Drive投影片製作起來並不如Power Point一般的精緻(另一方面也是因為這個版本是供列印用的,所以特別以高對比黑白相間的範本製作),但是Google Drive投影片製作功能卻是相當足夠使用。更重要的是,Google Drive的協同製作跟註解(comment)完全贏過Windows的OneDrive。

這學期我大量使用Google Drive的協同編輯功能,像是跟人一起編修論文計劃書、規劃投影片內容,這份投影片也是從Google Drive開啟編輯起。我先規劃投影片大綱,記錄每一張投影片欲講述的內容,以及相關參考資料的來源。然後各張投影片的內容則是跟實驗室各位助理一起填寫資料,接著我再重整資料內容。當投影片內容確定之後,最後我再下載成Power Point檔案作進一步的排版美化。

image

最後排版而成的版面就是這樣子了。

Google Drive與Power Point轉換編輯注意事項 / Difference Between Google Drive and Power Point

使用Google Drive製作投影片跟Power Point製作投影片有幾個重點差異需要注意:

  • Power Point匯入到Google Drive時樣式容易跑掉,但相反的從Google Drive匯入到Power Point問題卻不大。
  • Google Drive不支援投影片頁碼、不支援陰影、不支援連接線的折線。這幾種功能都是投影片常用的重要特色,請自行斟酌。
  • 請善加利用「投影片母片」(Power Point用詞)、「主投影片」(Google Drive用詞),可以保持投影片格式一致。

有機會我再詳細聊一下Google Drive協同編輯的心得吧。


結語:終於把研習班課程完成了 / Conclusion: The Experience of Workshop

這份投影片發佈之後,研習班的工作總算是告一段落了。

這次研習班跟其他研習班最大的差異,就是在於有很多實作的內容,而不是一直坐著聽老師授課。這次研習班主要兩個實作課程,一個是KALS合作標註閱讀學習,另一個則是這個DLLL-CIAS實作,這兩個實作都讓我煞費苦心。DLLL-CIAS要架設許多虛擬機器伺服器這點顯而易見,而KALS要弄到讓學員能夠在系統上順利操作,這背後其實也修改了許多細節。之前去IMLF 2014時就已經拖延了許多工作,然後之後投入在這研習班上,課程的部分就有點顧不住了,真是對不起老師啊。

雖然期末與這研習班整個像是災難一樣鋪天蓋地而來,但最後總算能夠過去。上課過程中有些兵荒馬亂,感謝各位助理大力相挺,沒有你們我一個人真的完成不了這些東西,這也包括了之前寫的幾篇DLLL-CIAS的細部操作文章

研習班上課過程中,我本來以為這麼硬的內容,應該會讓大家聽到一片瞌睡。結果時候聽完還蠻多人跑來跟我比較他們圖書館使用的VMware方案之間的差異,也有平時不碰技術的人跟我表達這堂課讓他獲益,有些人甚至想要在自己家裡架起這套方案。即使是客套話,我也覺得很開心。

希望下次能夠吸取這次的經驗,然後再帶給大家更好的課程內容吧。

(more...)

RemoteApp雜記 / Memo About RemoteApp

RemoteApp雜記 / Memo About RemoteApp

2014-08-05_131414

這篇記錄一下最近研究RemoteApp的記事。由於不是很正式的教學,所以格式上比較隨意,請大家見諒。

This article is the memo about RemoteApp research.


為什麼個人要用RemoteApp? / Why I Need RemoteApp?

在講RemoteApp之前,我先講一下什麼樣的情況,個人會須要用到這種方案。

現代人的生活很多時候會跟多臺電腦打交道。以我為例,先不論機房有一堆孩子(伺服器)要顧,我自己在實驗室有一臺桌機、平時在外面移動時則是有一臺筆電,回到宿舍時也還是用那一臺筆電工作。因此我自己就有兩臺電腦在使用。

在這個情景底下,我主要使用的是實驗室效能比較好的桌機,而筆電通常是利用遠端桌面連線回到桌機操作。大部分的檔案也是存放在桌機為主。

Windows的遠端桌面連線是Windows少數幾個偉大的設計之一。在網路頻寬允許的情況下,可以讓你的連線裝置彷彿就像是在遠端操作一樣。

但是實際上,遠端桌面連線因為功能太過龐大,有時候我只是想要使用某個應用程式,像是Photoshop,這時候我還是得連線到整個遠端桌面,然後才能開啟Photoshop操作,說來也是一種麻煩。

這就讓我興起了「我可只連線到遠端其中一個應用程式嗎?」的想法,因此就開始進行RemoteApp的小小研究。

遠端桌面連線的RemoteApp / RemoteApp of Remote Desktop Service

這篇所講的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都可以運作。

2014-08-05_134604

RemoteApp Tool不需要安裝,開啟之後就能夠設定要提供連線的應用程式。我自己馬上就建立了一個Line試試看。

image

從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

RemoteApp替代方案:Winflector / RemoteApp Alternative Solution: Winflector

2014-08-04_235245

Winflector是一個類似RemoteApp的替代方案。免費版本可以提供兩個客戶端同時連線。

2014-08-05_141446

一開始一樣是先安裝Server版本,安裝完之後要重新開機。然後接著設定應用程式,這些設定類似RemoteApp。再來設定可以登入的使用者的帳號與密碼,這部分跟Windows的帳戶是分開獨立的。另外連接埠要修改掉被佔用的80,改為其他連接埠之後,才能正常連線。

2014-08-05_131414

Winflector並不會產生像是RemoteApp這樣的連線設定檔,客戶端必須開啟Winflector客戶端程式,輸入伺服器端的IP連線資訊,接著就能夠在Applications看到伺服器端提供的應用程式,點選兩下就能夠直接開啟了。

開啟應用程式的速度不僅很快,而且輸入法、剪貼簿、視窗整合等操作都很流暢,彷彿真的就像是在本機端運作的程式一樣。而Winflector的連線也不會佔用遠端桌面連線的名額,不會把本機端使用者踢掉。

只是有幾點要注意的是事情:

  • 應用程式仍然是在遠端伺服器運作,因此檔案存放的「桌面」是伺服器端的「桌面」,而不是客戶端的桌面。如果是RemoteApp的話,會直接開啟網路上的芳鄰來作為檔案交換的途徑,但是Winflector並沒有提供這種功能。
  • 免費的Winfector只能提供兩個連線。

此外,Line開起來會一片空白,還是無法使用。

總而言之,Winfector意外地讓我很滿意,於是我最近會試著在桌機常駐Winfector的服務,讓筆電來連線使用看看。再試試看有沒有什麼問題。


為什麼團隊需要用RemoteApp? / Why Our Team Need RemoteApp?

個人使用的話,Winfector應該就能夠滿足需求了。就算是遠端檔案無法直接儲存在客戶端,也可以利用Dropbox來同步檔案。可是要在團隊裡面使用的話,這樣子的架構還不能算是完整。

為什麼團隊會需要使用RemoteApp?最大的原因仍然是因為軟體授權不足,或是軟體需要在高等級機器上運作,不方便安裝在筆電等效能較差的電腦上。

Citrix的XenApp / Citrix’s XenApp

2014-08-05_150131

現在學校大多是使用Citrix的XenApp方案,這個方案其實也挺不錯的。它類似RemoteApp,但是運作RemoteApp的伺服器是以XenServer建構而成的Windows虛擬機器,而非實體的Windows。在每次要使用XenApp的時候,伺服器端會自動建立一個可以運作應用程式的虛擬機器,提供XenApp連線。然後在關閉XenApp之後把虛擬機器移除掉。因此每次開啟XenApp,看到的都會是預設軟體的樣子,使用者無法自訂軟體。

在檔案傳輸方面,XenApp會在連線時,把使用者本機端的硬碟作為網路上的芳鄰連線過去。使用XenApp開啟檔案時會看到磁碟機有幾個是網路上的硬碟,這才是本機端的硬碟。至於XenApp裡面看到的桌面跟C磁碟機都是虛擬機器本身的裝置,關閉XenApp之後就會消失。

在這樣的架構下,XenApp一樣有連線人數的限制,端看學校購買的授權數量,決定可以同時可以使用的連線人數。另一方面,XenApp的架構也是一個付費方案,所以就不是我的優先選擇。

Linux的X Window / Linux’s X Window

image

說到遠端桌面,大家是不是太專注在Windows上,而忘記了Linux本身就有強大的X Window呢?

其實X Window所提供的X11 Forwarding本身就能達到「只開啟應用程式」的效果。這篇SSH X11 Forwarding介紹的很詳細當然,鳥哥則是對X Window System則有較詳細的介紹鳥哥則是對X Window System則有較詳細的介紹。我也在Ubuntu上運作成功。做法是:

  1. 先在伺服器Ubuntu上安裝SSH:sudo apt-get install –y sshd
  2. 設定好Ubuntu的網路,確認客戶端Windows 7可以連線到Ubuntu
  3. 客戶端Windows 7上安裝Xming,要重開機
  4. 開啟PuTTY,設定連線到Ubuntu,啟用Enable X11 forwarding
    2014-08-05_151611
  5. 登入SSH,進入命令列
  6. 以指令開啟要執行的應用程式,例如gedit
  7. 稍等片刻,客戶端Windows就會出現原本只能執行在Linux上的gedit

image

雖然步驟繁多,但是能在Windows開啟Linux的應用程式這點還是挺令人感到新奇的。不過實際上操作一下,發現問題有幾點:

  • 剪貼簿運作正常,可以在Linux應用程式與Windows應用程式裡面複製貼上
  • 無法使用Windows的輸入法,但可以複製貼上過去
  • 檔案系統依然是Linux上的檔案系統

儘管如此,由於X Window並沒有限制連線數量,只要硬體效能足夠,應該可以提供大量使用者連線操作才是。

在Linux上運作Windows的程式 / Run Windows Application on Linux

如果要走X Window的方式提供遠端應用程式服務,那另一個問題在於,我們平常用的還是Windows的應用程式,而不是Linux的應用程式。

事實上,Linux有許多可以運作Windows應用程式的方法,以下兩個方案是最常見的做法:

  • Wine:GPL開放原始碼軟體
  • CrossOver:付費軟體,有提供限時試用版

這兩種方案都是使用轉換技術,講Windows的架構轉換成可以在Linux執行的環境,以在Linux開啟Windows的應用程式。雖然Wine是開放原始碼的軟體,但是使用上似乎有諸多問題。不同Wine版本、不同的Linux發佈版、不同的Windows應用程式版本之間對應會有許多問題。反觀CrossOver似乎評價就比較正面(也許是因為付費了,稱讚一下也好?)。

如果有這些軟體搭配的話,我在想可能的架構就可以變成:

  • 在Linux伺服器上架設Wine環境
  • 安裝Windows應用程式
  • 客戶端上連線到Linux伺服器,開啟以Wine轉換的Windows應用程式

這樣子理想上就能達到不限人數的遠端應用程式的目標。不過我們還有其他問題還沒解決,一個是輸入法,另一個是檔案傳輸。輸入法的部分,這是另一個世界,我還得去研究看看;但是檔案傳輸的部分則比較簡單,我想可以用SFTP或是ownCloud來解決。

使用SSH交換遠端應用的檔案 / File Sharing with RemoteApp Server By SSH

最簡單的做法是使用SFTP連線到Linux伺服器。也就是說,連線到Linxu伺服器時,我們同時使用了三種服務:

  • SSH command
  • SSH X11 Forwarding
  • SFTP

這三種都是走SSH連線,這樣做最單純。


小結:離實用仍有段距離 / Conclusion: Non-Ideal Solution

總歸上述,目前比較可能可以使用的方案有兩個:

  • Winflector:Windows應用程式支援良好,但是限制人數2人
  • Linux X Windows System:不限制人數,但是Windows應用程式支援堪慮

不論是那一種方案,其實都不甚理想。市面上也有許多付費的VDI應用方案,但我還是希望先能找到以自由軟體發佈的替代方案為主。

再等等看吧。

(more...)

用ownCloud掛載NFS時避開資料夾權限檢查的問題 / Disable ownCloud permission check when mounting NFS

用ownCloud掛載NFS時避開資料夾權限檢查的問題 / Disable ownCloud permission check when mounting NFS

image

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 / My ownCloud Version

ownCloud是一種類似Dropbox的開放原始碼網站系統,我們最近也嘗試在自己單位中架設ownCloud來提供雲端硬碟的服務。

以Turnkey Linux架設OpenVZ虛擬機器的ownCloud / Establish ownCloud from Turnkey Linux OpenVZ Container

ownCloud的系統基礎是由PHP與MySQL組成,但是對於已經具備雲端平台的我們來說,當然不會從頭開始架設,而是直接選擇Turnkey LinuxownCloud OpenVZ虛擬機器來架設,ownCloud版本是4.90.8。

image

啟用ownCloud / Enable ownCloud

用Turnkey Linux架設虛擬機器很快,首先先把樣板上傳到Proxmox VE,開啟Console或用SSH登入到虛擬機器上,做一些密碼設定及取消Turnkey Linux自動更新的設定之後,就能夠用網頁直接連接了。

以下是啟用ownCloud之後遇到的問題與解法。


ownCloud掛載NFS / Mounting NFS for ownCloud

image

由於ownCloud運作於虛擬機器上,我不想讓單一虛擬機器擁有過大的檔案,造成備份及還原時的困擾。因此我決定將ownCloud儲存使用者資料的資料夾掛載到另外的NFS伺服器上。整個架構圖如上圖所示,但是細節部分需要注意的事情很多,以下一一敘述。

啟用OpenVZ虛擬機器掛載NFS的功能 / Enable OpenVZ Container Mount NFS Feature

Proxmox VE這種OpenVZ虛擬機器(container)要掛載NFS,必須在主機端(host)為虛擬機器開啟nfs:on的設定。細節請看我之前寫的介紹。

至於ownCloud擺放使用者資料的資料夾,Turnkey Linux預設的位置是在「/var/www/owncloud/data」。因此只要掛載這個資料夾即可。

掛載後無法啟用ownCloud的問題 / ownCloud Would Not Work After Mounting

image

接著開啟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.

安全性限制 / Security Limit

image

這是因為掛載NFS之後,data資料夾的權限會被改成777,而非預設的700。基於安全性限制,在data資料夾為777的權限之下,ownCloud將無法正常運作。

我們試著找了些方法,可是並沒辦法順利迴避資料夾權限檢查的問題。最後索性直接修改ownCloud的程式碼來略過權限檢查的問題。

修改util.php關閉資料夾權限檢查 / Modify util.php to Disable Permission Check

最後我們找到了ownCloud權限檢查的位置,這是在/var/www/owncloud/lib/util.php當中的一段敘述。我們將util.php關於資料夾權限檢查的部份註解掉之後,ownCloud就能夠順利運作了。

util.php已經上傳到GitHub,註解的行數介於241行~283行,請自行下載,替換原本ownCloud的/var/www/owncloud/lib/util.php吧。


小結:ownCloud的網頁與桌面免費,行動版要收費 / Conclusion: ownCloud Free for Web and Desktop, but Paid for Mobile

安裝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

8 - 1

雖然也可以在手機上開啟網頁版本,但是似乎沒有做行動裝置的最佳化,所以看起來非常像桌面版本,不太容易使用。這個問題不知道有沒有替代方案呢?

(more...)

解決Proxmox VE KVM虛擬機器硬碟與光碟常見問題 / The solution for KVM virtual machine’s hard drive and ISO mount misconfiguration in Proxmox VE

解決Proxmox VE KVM虛擬機器硬碟與光碟常見問題 / The solution for KVM virtual machine’s hard drive and ISO mount misconfiguration in Proxmox VE

proxmox-logo

最近我們在大規模地遷移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.


硬碟驅動錯誤 / Hard Drive Misconfigured

Image 3

最常見的就是硬碟驅動配置錯誤。有段時間我常常先在VirtualBox建立虛擬機器,再轉移到Proxmox VE。這種轉移方式通常只是上傳最重要的硬碟映像檔,像是vmdk或是qcow2 (但是在VirtualBox上運作qcow2的效率其差無比就是了)。

從VirtualBox到Proxmox VE的配置 / Configuration From VirtualBox to Proxmox VE

如果只是轉移硬碟映像檔的話,必須特別注意他們的硬碟驅動設定必須一致。如果當初建立的時候使用IDE,在轉移之後建立也就必須使用IDE。

2014-03-04_063543

舉例來說,這是VirtualBox的操作介面,你可以看到這台虛擬機器的硬碟是被設定成SATA

Image 5

但是在Proxmox VE上,這臺虛擬機器的硬碟卻被設成了IDE。在Windows XP或是Linux卻使用LVM的情況下,往往會造成開機失敗。

Image 6

因此,在建立虛擬機器的硬碟時,必須特別注意其使用的硬碟驅動器。

解決方式:修改硬碟控制器 / Solution: Modify Hard Drive Controller

如果你已經將硬碟安裝成錯誤的硬碟驅動器,那Proxmox VE網頁介面上是無法直接修改。我建議是使用SFTP直接操作伺服器的檔案系統,作法如下:

  1. 先以正確的硬碟驅動器新增一個硬碟映像檔,檔案大小不拘。
  2. 以SSH登入Proxmox VE:預設連接埠22。
  3. 進入KVM的硬碟擺放位置:以VMID為260的虛擬機器為例,路徑位置就是/var/lib/vz/images/260
  4. 新建立的硬碟映像檔檔名通常會是「vm-260-disk-2.vmdk」,而用錯誤方式建立的硬碟映像檔通常會是「vm-260-disk-1.vmdk」。
  5. 記住新映像檔檔名,把新的硬碟映像檔刪除,再把舊的硬碟映像檔換個名字
  6. 回到Proxmox VE網頁介面,刪除舊硬碟映像檔的設定,只留下新建立正確的硬碟設定

這樣就完成了。


CD/DVD光碟掛載錯誤 / CD/DVD Drive ISO Mount Misconfigured

Image 7

前一種情況大多是只轉移硬碟映像檔的時候,這一種情況則是使用Proxmox VE的備份功能vzdump匯出虛擬機器之後、再匯入新的Proxmox VE的情況。細節作法可以看我寫的另一篇「Proxmox VE用備份(vzdump)與還原(restore)複製虛擬機器」。

使用vzdump的時候,虛擬機器的設定會鉅細靡遺地被保留,並還原到新的虛擬機器環境中。問題是在於新的環境中可能使用的Storage ID(儲存空間名稱)不一樣,就會導致無法正常開機的問題。

Image 8

以上圖為例,當Storage設定錯誤時,發生錯誤訊息就會是:

TASK ERROR: storage 'proxmox-nas' does not exists

這是因為這個Proxmox VE虛擬機器環境下沒有名為「proxmox-nas」的Storage的緣故。

解決方式:取消掛載映像檔 / Solution: Unmount ISO

Image 9

解決方式很簡單,就是把掛載的映像檔取消掉就好了。

  1. 指定該硬碟,按下Edit
  2. 設定Do not use any media,或是重新掛載正確的ISO映像檔,按下OK即可

這個問題警惕了我們,如果虛擬機器設定完畢之後,記得取消掛載安裝時使用的映像檔設定。


結論:不要害怕使用虛擬機器 / Conclusion: Embrace Virtual Machine

每次遇到虛擬機器的各種問題,我常常聽到的抱怨都是:「為什麼要用這種東西?你就不能裝在實體機器上嗎?」就我個人來看,這種抱怨是一種誤解。

如果你仔細看看這篇敘述的兩種問題,其實是很容易類比到實體機器上──就像是拿著SATA線去接一顆IDE硬碟,或是在光碟機裡面指定放進一片不存在的光碟。儘管實體機器操作中,有些常識的網管可能不會卡在這麼奇怪的問題上,但這的確是可以從實體機器類推到虛擬機器上的情況。

我想說的是,其實虛擬機器的設定跟實體機器沒有這麼大的差別,但比實體機器設定更為容易。以硬碟控制器的問題來說,實體機器的情況可能是一顆舊的IDE硬碟要裝到新的伺服器上,如果伺服器只剩下SATA線,那要裝IDE硬碟還必須搭配張SATA to IDE的轉接卡才能使用,安裝時還得考量到轉接卡阻礙線材空間等問題,處理起來挺費工夫的。但是虛擬機器只要設定幾項參數即可完成調整,方便許多。

虛擬機器除了有助於網管之外,快速還原的能力還能夠用於程式開發上。在「成为一个PHP专家:缺失的环节」一文中建議PHP時使用虛擬機器建立個Linux,以方便隨時重新開始或還原到程式開發的某個狀態。這些都是非常有用的功能。

因此,我會對VirtualBox、Proxmox VE、OpenVZ、KVM等多種開放自由的技術抱持最高的敬意,並繼續擁抱虛擬機器。

(more...)

修復Proxmox VE Cluster無法備份的問題 / Repair Proxmox VE Cluster cannot backup problem

修復Proxmox VE Cluster無法備份的問題 / Repair Proxmox VE Cluster cannot backup problem

2014-03-02_215010

最近我處理的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.


錯誤訊息 / Error Message

我在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)。

為什麼被設定成只能讀取的權限了 / Why Permission is Read-only Permission?

這是因為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就會自動鎖起來。

警告 / Warning

以下方法是我摸索解決方案的一個過程,很多細節我不清楚,有幾台node可以如此解決,可是有幾台不行。我還沒有了解整個原因細節,在此只是記錄一下目前的解決方法。

Wiki的解決方式 / The solution from Wiki

根據wiki的介紹,最簡單的方式是在有問題的node上輸入指令:

# pvecm expected 1

但是當我要這樣做的時候,卻又有另一個錯誤訊息發生,告訴我cman並沒有正常啟動。我嘗試想要用「service cman start」,但是卻依然不能執行「pvecm expected 1」。

我的解決方式 / My solution

因此我決定參考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)的問題依然沒有改變,如下圖:

2014-03-02_215458

儘管如此,執行完之後,有一定機率可以正常啟用整個Cluster。

其他注意事項 / Other Note

說是一定機率的原因是,有時候可能要重開機之後再執行一次expected.sh。但是這不一定每次都會成功,我試了好幾台,結果都不一樣。必須注意的是,重開機之後,虛擬機器不會正常地Start on boot,需要手動開啟。

其中有幾台因為網路交換器出了問題(ASUS的,真是堅若磐石)而導致quorum無法正常運作。更換交換器之後就正常運作了。

目前我手邊已經沒有需要做這樣修復的node,所以我接下來就不會繼續深入探究了。就做到這邊吧。

(more...)

OpenVZ掛載NFS的虛擬機器設定 / OpenVZ container configuration to mount NFS

OpenVZ掛載NFS的虛擬機器設定 / OpenVZ container configuration to mount NFS

image

如果要讓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:mount.nfs: No such device / Mount NFS Error

image

如果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目錄,請依照以下方法來開啟。

開啟虛擬機器的NFS功能 / Enable Container’s NFS Feature

Step 1. 將虛擬機器關機 / Shutdown Container

要進行設定之前必須先將虛擬機器關機。關機指令為:

# halt
Step 2. 進入Host端命令列 / Enter Host Shell

首先先進入Proxmox VE的網頁管理介面,預設連接埠為8006,必須用https進入。

image

登入之後,找到該虛擬機器的Host伺服器,進入右上角的「Shell」介面。

image

Proxmox VE提供了Java Applet連線的主控介面(console),可以在此直接以root身分操作Host端伺服器。

Step 3. 設定"nfs:on" / Setting "nfs:on"

接下來要照OpenVZ的說明設定虛擬機器。該機器的VMID若是101,那麼開啟NFS的指令如下:

vzctl set 101 --features "nfs:on" --save; vzctl start 101

image

設定完成之後,虛擬機器會一起啟動。

Step 4. 完成掛載設定

image

這時候再開啟虛擬機器,掛載NFS的時候,指令就能正常執行。


NFS掛載指令與設定 / NFS Mount Configuration

參考鳥哥的Linux私房菜中NFS客戶端的教學,OpenVZ要使用NFS,通常必須先做以下設定:

Step 1. 安裝nfs-common / Install nfs-common

Debian或Ubuntu系列請用apt-get安裝:

apt-get install nfs-common

CentOS或RedHat系列請用yum安裝:

yum install -y nfs*
Step 2. 測試NFS掛載指令 / Test NFS Mount Command

NFS的掛載位置必須參考NFS伺服器的設定。每一台NFS伺服器設定都不一樣,特別是現在各家NAS使用自家作業系統之後,提供的路徑千奇百怪,我在這邊卡了許久,後來升級NAS的韌體才知道NFS掛載路徑。

舉例來說,NFS伺服器設定如下:

  • IP網址:10.9.5.95
  • NFS的掛載路徑:/raid0/data/_NAS_NFS_Exports_/cluod-rstudio-2013
  • 本機的掛載路徑:/tmp/nfs(請預先用mkdir建立好該目錄)

那麼NFS掛載的指令就是:

mount -t nfs 10.9.5.95:/raid0/data/_NAS_NFS_Exports_/cluod-rstudio-2013 /tmp/nfs

試著執行看看。如果沒有任何訊息,那就是順利成功了。

Step 2-1. 錯誤: rpc.statd / Mount Error: rpc.statd

我在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

Step 2-2. 錯誤:mount.nfs: Connection refused / Mount Error: Connection refused

舊版本的CentOS會遇到這個問題。掛載時遇到的錯誤訊息如下:

mount.nfs: Connection refused

這版本的CentOS不是用rpcbind,而是用portmap。所以要先開啟portmap服務:

service portmap start

這樣就能夠正常掛載

Step 3. 開機自動掛載 / NFS Mount On Boot

修改 /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...)