VFC的配置工作在Hyper-V管理器中完成，使用的是新的Virtual SAN Manager(虛擬SAN管理器)選項，詳見上圖。只有HBA以及支持NPIV的固件才能正確為VFC所使用。換句話來說，只有像Emulex HBA這類傳輸能力在4Gb/秒以上的新HBA方能符合要求。顯然SAN光纖也必須同樣支持NPIV。一個HBA只能歸屬于一個虛擬SAN，然而一個虛擬SAN中卻可以包含多個HBA。在虛擬SAN創(chuàng)建完成之后，我們就可以利用Add Hardware(添加硬件)選項中的Settings(設定)子集將虛擬HBA分配給客戶機。光纖通路ID理論上可以使用任何16位長度的16進制數(shù)字，不過官方并不建議用戶使用那些已經(jīng)預留的數(shù)值。微軟公司在默認情況下設定了一些標準值，我們在點擊“Create Addresses”(創(chuàng)建地址)按鈕時這些值會自動生成以供使用。不過到現(xiàn)在我也沒搞清楚為什么光纖通路似乎只有兩組地址可見并直接可用。

在客戶機啟動完成之后，即使我們沒有安裝客戶機O/S，光纖登錄進程也會自動開始。如上圖所示，額外的節(jié)點指明了源Hyper-V服務器(在本實例為中PH03)，但卻無法正確顯示客戶機名稱，而只是標注為“Hyper-V VM Port”(Hyper-V虛擬機端口)。希望這一點在今后的更新中能有所改善，畢竟看不見虛擬機名稱的話管理工作實在很難進行。

要想在Hyper-V客戶機上使用VFC需要滿足兩大條件：

第一，使用指定的O/S——Windows Server 2008、Windows 2008 R2或者Windows 2012都可以;

第二，安裝Windows Server 2012中附帶的集成服務更新。也就是說虛擬光纖通路適配器無法被模擬為本機設備，因此我們不能使用以Linux為代表的其它操作系統(tǒng)。上圖顯示的是我為主機設置的模擬HBA控制器以及磁帶驅動器。

最近我發(fā)現(xiàn)很多博文都在對Windows Server 2012的磁帶驅動器支持能力展開討論。這里我要澄清一下，磁帶驅動器絕對是能夠正常工作的，但目前微軟官方還沒有在任何說明文檔中正式表示他們提供相關支持。

性能表現(xiàn)

我選擇了一款磁帶驅動器，這正是展示W(wǎng)indows Server 2012處理性能的絕佳方式。在將Backup Exec 2012部署到我的Windows 2008 R2客戶機并向LTO2驅動器進行寫入操作時，我發(fā)現(xiàn)測試成績達到12MB/秒，這比我在vSphere 5.0上進行模擬設備測試時的成績要好一些。雖然這與驅動器本身的最大傳輸能力(40MB/秒)還有一定差距，但在小型業(yè)務環(huán)境中已經(jīng)足夠用了。要想得出更有說服力的結論，我們還需要進行大量測試工作，畢竟在Hyper-V服務器上的數(shù)據(jù)遷移管理工作量并不太大。

架構師觀點

虛擬光纖通路的出現(xiàn)為本地SAN設備帶來了有力的技術支持。不過這項新功能在實際使用方面仍然存在各種限制，其中最令人難以接受的就是必須使用最新的硬件以及微軟系統(tǒng)平臺。到目前為止我還沒有看到任何真正成功的VFC實踐經(jīng)驗，例如將多個HBA與單一虛擬SAN相匹配或者將其構建為故障轉移體系，因此具體實施方案還需要用戶耐心等待。

VFC的主要改進方向有兩點：首次，驅動器應該能夠支持其它平臺，尤其是Linux環(huán)境;其次，如果供應商能夠利用虛擬設備進行代碼編寫，那么虛擬SAN裝置(簡稱VSA)應該能夠比目前的iSCSI更好地與光纖通路進行協(xié)作。

最后再說一句，微軟在這些全新存儲功能的細節(jié)說明方面做得并不好。直到現(xiàn)在我們也無法在高端博客之外找到任何實際使用經(jīng)驗，這對于用戶而言顯然不夠貼心。希望這一點能夠盡早得到改觀，讓微軟潛心打造的新功能真正為廣大消費者服務。

tangrong