VMware 中讓 VM 間網路連線更快的調校方式

如果系統架構中，分工越來越明確，像是 AP/DB/File Server 三個角色分開，那 VM 間的通訊速度一定是重點，舉例來說，如果作了一台 NFS Server，你一定會期待在區域網路內要有非常快的速度，但有時候就是事與願違，這邊提供了幾項經驗來改善 VM 間的網路速度:

1.      安裝 VMXNET3 的網卡，以預設的 E1000 網卡和 VMXNET 網卡一比較，安裝完VM Tools 後，速度就有了十倍的差異，E1000是1Gbps，VMXNET3是 10Gbps。

 2. 將 VMCI Device打開 

VMCI Device 是 VMware 裡面 VM 的設定，預設是關閉的，如果有打開的話，會從原本的2Gb/s 速度提升到 6Gb/s，要將 VM 關機才可以開啟。

3. 將有關連的 VM 搬到同一台 Host

       為什麼要這樣作呢? 因為如果 A VM要去存取 B VM的檔案，但是 A 跟 B 在不同 ESXi 上，這樣就要透過兩台 ESXi 的實體網卡跟 Switch 去交換資料，這樣的話就取決於你的網卡有多快，因為我自己的環境網卡只有 1Gbs ，所以網路交換的速度是不可能大過 1Gb/s 的。

        但如果今天 A 跟 B 是在同一台 ESXi 裡面，因為網卡都是虛擬的，所以資料交換在記憶體內就作完了! 速度當然會大大提升!

要怎麼讓兩台機器都一直在一台 ESXi 中呢?

        我們可以透過 DRS 裡面的 Rule 去設定，就像以下的畫面，我把這兩台 VM 設定成一定要一直在一起，這樣他們就不會分家啦~

有打勾才有啟用喔

速度實測

環境: Windows 7 SP1 VM

各準備兩張網卡，一張E1000，一張VMXNET3

檔案大小: 100MB 用實際傳檔做測試

結果發現，E1000 跟 VMXNET3 的差別並沒有非常大，VMCI 也看不太出來，大概是我用的檔案太大，也許以後用大小檔混合會比較準，但是有沒有同實體機就差很多了，速度幾乎快了三倍以上，事實證明如果以上三個都有設定的話，的確對VM間傳輸會有幫助，尤其是保持在同一台實體機器上!

Windows Server 2012 R2 Hyper-V 的新功能

Server 2012 剛出沒多久，大家還在評估要不要裝，2012 R2 就飛也似的發表了，這對剛買 2012 的人真是不是滋味，不過這次在Hyper-V的改善，也可看出微軟在虛擬化還有私有雲這塊的野心，在各種Cloud OS : Open Stack、Cloud Stack的強力追擊下，戰場迅速蔓延到私有雲建置，VMWare的皮要繃緊一點了!

Hyper-V在2012 R2的新增功能如下:

1.   第2代VM (Gen2 VMs)

• 在新增VM的方面，多了一個選擇 " 世代" 的功能，支援了安全開機、SCSI開機還有PXE開機等功能，需要Windows 8或是Server 2012之後才支援，有了這個功能，讓VM的運作還有整體的資源使用更有彈性，也讓VM與實體機器的實際功能上更加接近。

2.     VM直接連結 (VM Direct Connect)

• 以前要連到VM，透過遠端桌面連線(RDP)需要可用的網路才可以，意味著這個 VM 需要一組可以連結到的IP，但開啟遠端桌面連線其實伴隨著一些管理上的風險，Server 2012 R2的這個新功能可以透過VM Bus直接遠端桌面連線到這台VM。

• 以前從Hyper-V管理介面連線到VM，許多RDP的優點像是掛硬碟，複製貼上都不能用，現在只要把加強的工作階段打開，就可以享受這許多新功能，就不用傷腦筋要怎麼傳資料或是剪貼文字到VM中了

3.    VM延伸複製到第三地 (Extend replication to a third site)

• 之前的Hyper-V 3.0的原生Replica複製的目標只限定為一個，但這對於一些服務來說彈性不夠，因此現在增加支援到了第三地複寫，這對於一些公司，就可以非常容易且超級便宜的的實現第二座機房還有DR Site了。

4.    複寫頻率設定 (Replica frequency options)

  

• 之前的Replica頻率只能固定為5分鐘，現在可以設定複寫頻率，有30秒/5分鐘/15分鐘可以選，只要你的線路或硬體夠快，就可以選擇更快的頻率。以前12次複寫失敗，複寫狀態就會變為 Failed，現在如果選擇15分鐘的頻率，這個緩衝時間就會從1小時變為3小時，因此可以視你的線路及硬體的等級做設定。

5.    壓縮快速移轉 (Compression for faster migration)

• 這一代的Live Migration支援將資料壓縮再即時移轉，壓縮的時候可能會用到CPU的Loading(不過大部分人的CPU其實都挺閒的)，另外也支援用SMB方式移轉，但網卡要支援RDMA才可以，如果你用的是10Gb等級網卡，相當推薦用RDMA，據說速度會跟飛的一樣。現在的VM每個都在比記憶體大的，以筆者的環境來說，最大的VM都有96GB的計憶體，32GB的VM也有七八台，要移轉這幾台真的是非常非常久，現在有這種方案，當然值得好好研究一下來。

6.    VM 線上匯出及複製 (Online VM exporting and cloning)

• 這一代已經支援不關機就可以匯出VM還有Clone了，但Clone請用SCVMM 2012 R2來做，遙想 Server 2008 的 Hyper-V 剛出的時候，什麼小動作都需要關機不然就重新啟動，真的進步很多啊~~~~~~

7.      Online VHDX resizing

• 這一代的VHDX，不用關機就可以直接改變大小，以前不能這樣改系統碟，但可以改用SCSI卡掛上去的硬碟，2012 R2把這個限制拿掉了，但只針對VHDX，在用VHD的就趕快轉吧~效能跟擴充性都差挺多的

8.     Storage QoS

• 現在可以設定VM的Storage的Qos，IOPS可以限定最小值跟最大值，有了這個設定就可以確保最重要的服務可以獲得最大的I/O效能，增加了不少彈性。

9.      Dynamic Memory support for Linux

• 以前的 Hyper-V 2.0 裝Linux VM根本是一場惡夢，因為很多東西會有問題，包括裝整合服務，移轉，還有一些奇奇怪怪的問題，Hyper-V 3.0 改善了不少，主流的Linux VM都可以順利執行，但就是動態記憶體還不太支援，導致一開機就吃掉一堆記憶體，這也是跟 VMWare 差最多的地方，這個問題終於在 2012 R2改掉，之前就測試過，VM 的I/O在Hyper-V上比VMWare好很多，現在終於可以拿來做Linux VM的Production了，算是很不錯但遲來的進步。

10.    虛擬硬碟共用(Shared VHDX)

• 這個也是非常不錯的改善，以前要用 VM 來實做容錯移轉叢集(比如說SQL Server Cluster)，是一件很讓人頭痛的事情，原因就在於要有共用磁碟(Cluster Share Volume)，因為虛擬SAN不是那麼的實用(還要設定 SAN Switch 跟Storage切LUN)，所以只能用iSCSI或是SMB 3.0來實做，但是如果環境裡面沒有這兩個Source，就要想破腦袋不然就要用VMWAre或是找實體機器做，現在可以直接用VHDX當作Share Volume，就可以更省資源了!真是早該這樣做了。

其他小變化:

(1)  VM預設沒有光碟機，需要自己新建SCSI卡再新增一個光碟機，這樣也好，VM的資源應該越少越好，多個光碟機有時候在Live Migration時都要檢查一下。

(2) 快照改名了，改為檢查點

新增說明文字

(3) 整合服務多了一個客體服務

其實我不知道這幹嘛的.....

(4) 支援USB pass-through

可以讓插到Host的USB隨身碟更快的讓VM讀到...
好吧算方便但是很小的改進

[VMWare] vCenter無法連結到ESXi主機

前幾天有一台 ESXi 無法連接上，一開始是這樣，這台 Host 下面的 VM 都呈現灰色，但是還是有在運作。

後來就手動 Connect，依舊失敗，出現了以下的錯誤訊息

有去這台 ESXi，重新啟動 vpxa 服務，但還是無法重啟，

也去重新啟動過 Management-agent，還是一樣

之後就去查 VMWare KB，發現可能是以下問題產生的

1. 此台 ESXi 上面的 VM 的 Snapshot 數太多 (不能超過 32 個)
2. 此台 ESXi 的硬碟空間剩餘不多
3. ESXi 的版本跟 vCenter 不同

遺憾的是這三項跟我都不符合，只好開 Case。

更遺憾的是開了 Case，VMWare 工程師也請我查了一堆原因，但都不是真正的原因，所以最後用 vpxa 服務起不來為主因，建議我重開機……

好了，跟大家的預期一樣，重開機之後就好了

這幾年的感想……Hyper-V 跟 VMWare 沒有誰穩的問題，只有運氣好壞的問題….. 是該買幾包乖乖放在 ESXi 主機上了!

附錄

----------------------------------------------------------------------------------

ESXi 5.X 重新啟動 management-agent 還有 vpxa 的方法

GUI 介面:

1. 用 Console 連接
2. 按 F2, root 登入
3. Troubleshooting Options-->Restart Management Agents.
4. F11 確定 restart the services.

SSH 介面: 連接 SSH 到 ESXi (記得先打開 SSH)

----------------------------------------------------

/etc/init.d/hostd restart
/etc/init.d/vpxa restart

但是也可以從 vSphere Client 連接到 ESXi，在 Configuration 裡面，找到 Security Profile，Service 裡面選擇右上方的 Properties，然後在裡面找到 vpxa，就可以 Restart 了。

-----------------------------------------------------------------------------------------

[VMWare] Deploy Virtual Machine from this template 出現 since it is locked 的異常訊息

今天就如往常一樣，要建一個新的 VM，但是從 Template Deploy 的時候出現了異常訊息

此訊息表示無法存取 Template 的 vmdk 檔，因為被鎖定，但 Template 應該是不會有人去存取才是，理論上不會出現鎖定的行為，我就 Google 了一下，試過一些方法:

1. 把 Template 轉成 VM，無法開機，錯誤訊息一樣

2. 建立 Snapshot，然後再去 Snapshot 管理員選擇 Delete all，這個方法也沒用

後來終於發現問題所在，因為我上次用這個 Template Deploy 出來的 VM(之後都簡稱 MyVM)，我去看他的 VMDK，赫然發現這個 MyVM 掛的硬碟竟然是 Template 的 VMDK 檔，真是哪門子的爛 Bug!

還好這個 MyVM 還沒交付給 User，只是個乾淨的 Windows，於是我就把這個硬碟從 MyVM 移除，把原本屬於他的掛上去，然後就正常了。

事情當然還沒結束，身為一個工程師，不能不了解原因就這樣放他過去，不然以後還是會發生，當我把 MyVM 的硬碟移除後，Template 也正常了，結果 Template 的硬碟變成 MyVM 之前的那顆，因為我之前在 Windows 裡面有建一個帳號，結果這個帳號出現在 Template 裡面，讓我只好重做一個乾淨的 Template，所以總結以上，正確的處理方式應該是:

1. 關閉 MyVM，把 Hard Disk Remove
2. 把 Template Convert 為 VM，把Hard Disk Remove
3. 把 Template 的 Hard Disk Copy 到 MyVM 的 Datastore
4. 把 MyVM 的 Hard Disk Copy 到 Template 的 Datastore
5. 把原本 Template 的 VMDK 掛給 MyVM
6. 把原本 MyVM 的 VMDK 掛給 Template
7. MyVM 開機，應該就會跟之前一樣
8. Template 重新 Convert 為 Template

Buttttttttttttttttttttttt，為什麼會出現這個爛 Bug 啊，不能這樣啊，不然以後我從 template Deploy VM 出來都要去檢查 VMDK 位置的話不就太蠢了!

所以我又實驗了一次 Deploy，很幸運的試了出來:

只要你在 Deploy VM from this template 的時候，有改硬碟大小，那這個 VM 就會掛到原本 Template 的 VMDK!

結論是，如果你要改新的 VM 硬碟大小，請 Deploy 成功之後再改……..

[Windows] Windows的機器在超過497天未重開後的詭異事件

      在大家心目中，Server 就是不用常常在重開的，雖說不可能永遠不重開，但是一兩個月不重開也不是什麼大不了的事情，我們單位的 Windows Server 機器占了大多數，所以經驗值累積的比較多，有幾次的事件是這樣:

(1)   有天某人打來說 SQL 資料庫沒辦法跟其他資料庫同步，但是只有跟一台沒辦法同步，一問之下，怪了那台資料庫正常，從其他台連 1433 Port 過去都是通的，唯獨就是從我們的資料庫沒辦法過去 1433 Port，實在太詭異，還好是建置在容錯移轉叢集上，因此先把資料庫的 Instance 移到另外一台上，重開那台 host，神奇的事情發生了，問題竟然解決了!

(2)   有天某個使用者跟我說無法連到一台 VM，我也連不進去，Host 上面的 VM 只有這台有問題，結果最後重開了，結果是一切就正常了……

        其實一直以來我每次開 Case 也有跟微軟工程師說，我覺得你們的 OS 大概一年半左右沒有重開會有問題……(我自己測大概是 490~500 天左右)，之後重開就可以解決，當然微軟的工程師不會說是自己的 Bug 啦~~~~~

    過了一年後，我們又出現這種情形，雖然我們已經很習慣要重開了，但還是不免俗的開了一下 Case，沒想到這次微軟說 Patch 已經出囉，是針對 497 天沒有重開的機器，有可能你的 TCP/IP 的 Port 都處在 TIME_WAIT 的狀態，導致無法連線，主要發生在 Windows Server 2008 跟 Windows Server 2008R2 上，這樣一想起來，真的每次出問題的都是 2008 的機器，所以我們就趁這個機會趕快把這個 Patch 裝上去囉~~~~

強烈建議以下使用者快裝:

(1) 有裝 Hyper-V Cluster 者 --> 不然超過 500 天有可能 HOST 整個死掉

(2) 有裝 SQL Server Cluster 者 --> 有可能某些連線出問題

(3) 重要的網站服務 --> 有可能網站失效 此時你重開 IIS 都沒用

Patch 網址如下:

http://support.microsoft.com/kb/2553549/en-us