共用方式為

透過網路隔離複製虛擬機器

  • 發行項

虛擬 Lab Management 是軟體開發週期中的一個新興的領域。 Visual Studio Lab Management 是 Visual Studio 中的一項產品，將虛擬 Lab Management 帶給開發人員和測試人員。 使用 Visual Studio Lab Management，開發小組就可以在他們的開發和測試實驗室中利用虛擬化技術，從虛擬機器構成複雜的多層環境。 然後他們可以部署應用程式組建並在那些環境上執行測試。

在開發和測試實驗室中使用虛擬化的其中一個動機是只要複製幾個檔案，就可以建立已部署之虛擬機器的相同複本或「複製品」(clones)。 複製在許多情節中都非常有用。 例如，需要測試人員的環境複本以重現問題的開發人員可以建立該環境的複製品。 在測試小組中，每個個別測試人員都可以複製環境的複本，然後與小組的其餘人員協調其測試成果。 複製可節省開發人員和測試人員的時間，因為他們無須在他們所建立的每一個環境中重複安裝作業系統和其他軟體。

需求

  • Visual Studio Ultimate, Visual Studio Premium, Visual Studio Test Professional

即使複製虛擬環境非常簡單，不過您還是必須考量複製的一些結果。 複製環境中的電腦之電腦名稱與原始環境中的電腦相同。 在某些情況下，連它們的 IP 位址和 MAC 位址都相同。 這可能導致其中一個複本失去網路連線，或是以某個複本為目標的網路流量卻流向另一個複本。 最後，可能會產生非預期的結果，就是您將應用程式部署到特定的複製品，並在另一個複製品上進行測試。

注意事項注意事項

只有在 SCVMM 環境中才能使用網路隔離。這個功能並不能用於標準環境。

Visual Studio Lab Management 透過一種稱為「網路隔離」(network isolation) 的技術，解決這些問題並協助安全複製虛擬環境。 本主題討論網路隔離的運作方式並比較有與沒有網路隔離的複製作業。 第一個範例說明在沒有網路隔離下的複製品之間可能發生各種形式的衝突。 後續的範例則使用 Visual Studio Lab Management 檢查多個方案以防止衝突。

網路衝突

圖 1 顯示您可以使用 Lab Management 建立的一般虛擬環境。 此環境稱為原始環境，有兩部虛擬機器：Web 伺服器和 DB 伺服器。 這些電腦在三層 Web 應用程式中分別做為 Web 的角色和資料庫伺服器。 在本範例中，我們假設開發小組的成員建立了此環境，並將其 Web 應用程式的最新組建部署到此環境中。 我們也假設在部署組建之後，已在此環境中擷取稱為最新組建的快照。 快照是指環境的時間點狀態。 您可以隨時從這個儲存狀態還原到執行狀態並繼續執行。 此圖顯示原始環境中兩部虛擬機器的電腦名稱、IP 位址和 MAC 位址。

原始環境

原始主機中 VM 的「Web 伺服器」和「資料庫伺服器」。

圖 2 顯示除原始環境以外的複製環境。 在複製之後，當兩個環境都啟動時，可能會發生下列類型的網路衝突：

  1. 電腦名稱衝突

  2. IP 位址衝突

  3. MAC 位址衝突

一般網路上的原始和複製環境

包含複製品 VM 且發生名稱衝突的兩部主機

每一個衝突的確切結果都根據數個因素而定：虛擬機器中的作業系統、實驗室中的網路基礎結構等等。 在圖 2 中，我們假設已在原始環境的每一部虛擬機器中設定靜態 IP 位址和靜態 MAC 位址。 因此，當環境被複製時，複製的虛擬機器會具有相同的 IP 和 MAC 位址。

電腦名稱衝突

電腦名稱是由使用者所指派的易記名稱，用於識別網路中的電腦。 通常會使用兩個通訊協定將電腦名稱解析為其 IP 位址：NetBIOS 和網域名稱伺服器 (DNS)。 當兩部具有相同電腦名稱的電腦在同一個網路區段上啟動時，NetBIOS 會偵測名稱衝突並警告使用者。 一般說來，只有在電腦位於同一個網路區段時，NetBIOS 才能偵測到衝突。 如果電腦不在同一個網路區段上，或是警告遭到忽略，在 DNS 中會發生下一個層級的衝突。 DNS 是供電腦註冊其名稱的中央儲存機制。 當兩部具有相同電腦名稱的電腦試圖在 DNS 中註冊時，第二台電腦可能會覆寫第一台電腦所建立的項目。 在此情況下，將無法透過名稱解析與第一台啟動的電腦連線。

有一些簡單的方式可避免或修正電腦名稱衝突。 您可以使用一種稱為 sysprep 的機制，在建立每個複製品的同時將其自訂，而非建立相同的環境複本。 Sysprep 是 Windows 作業系統的一部分。 當您使用 sysprep 複製環境時，環境的每部虛擬機器都會取得與原始環境不同的唯一電腦名稱、IP 位址和 MAC 位址。 然而，複製品已不再相同。

每一個複製品中都有唯一電腦名稱 (無論是透過 sysprep 完成或透過使用者手動操作以避免衝突) 的影響，視安裝在虛擬機器中的軟體而定。 如果要了解此情況，請查看範例。 當應用程式部署在環境上時，Web 伺服器上會建立 web.config 檔案。 在這個檔案中，我們已將電腦名稱 db-server 設定為連接字串的一部分。 以下顯示該檔案的程式碼片段：

<?xml version="1.0"?>
<configuration>
  <appSettings>
    <add key="ConnectionString" 
      value="Persist Security Info=True;User ID=dbuser;  
        Password=password;Initial Catalog=Store;Data Source=db-server"/>
  </appSettings>
</configuration>

當我們在複製的環境中變更資料庫伺服器的電腦名稱時，我們也必須如下手動變更 web.config 檔案，才能使用新名稱 (db-server2 是提供給複製環境中虛擬機器的新電腦名稱)。

<?xml version="1.0"?>
<configuration>
  <appSettings>
    <add key="ConnectionString" 
      value="Persist Security Info=True;User ID=dbuser;  
        Password=password;Initial Catalog=Store;Data Source=db-server2"/>
  </appSettings>
</configuration>

此外，當 SQL Server 的電腦名稱變更時，它需要額外的步驟。 以下顯示用來達成此目的的 SQL 指令碼的程式碼片段：

sp_dropserver db-server
sp_addserver db-server2, local
GO

上一個範例顯示如果電腦名稱變更，應用程式必須如何重新設定。 可以理解的是，此程序視應用程式而定。 如果應用程式將電腦名稱寫入資料庫中的項目，則必須以類似方式變更那些項目。 在某些情況下，您可能必須在電腦名稱變更時安裝應用程式。 我們會在一開始使用複製作業，顯然是想要避免執行這類的重新設定和重新安裝。 這使得更自動化且與應用程式無關的方案更加必要，可放心容許多個複製品同時存在，又沒有電腦名稱衝突。

IP 位址衝突

網際網路通訊協定 (IP) 位址用於電腦透過 TCP 網路彼此通訊。 網路上的 DHCP 伺服器會靜態或動態指派 IP 位址。 電腦中的每個已連接網路介面都有一個 IP 位址。 如果複製利用靜態 IP 位址設定的虛擬機器，並將其放在與原始虛擬機器相同的網路上，則除了電腦名稱衝突之外，還會產生 IP 位址衝突。 變更其中一個複製品的 IP 位址，您就可以手動修正此衝突。 變更 IP 位址的影響，也根據安裝在虛擬機器上的應用程式如何使用靜態 IP 位址而定。

當您開始複製以動態 IP 位址設定的虛擬機器時，會出現短期的網路衝突。 在複製第一部虛擬機器之後，要連接至網路的第二部虛擬機器會立即偵測到此衝突，並藉由更新其 IP 位址來進行更正。 每次複製的環境還原到原始環境中所擷取的快照時，也會存在類似的短期衝突。 這些衝突的時間通常不會長到足以影響應用程式。

MAC 位址衝突

媒體存取控制 (MAC) 位址是指派給電腦中每個網路介面的位址。 如果是實體機器，介面卡的製造商會將它指派給每個網路介面。 如果是虛擬機器，有兩個指派 MAC 位址的方式：靜態或動態 MAC。 您可以指定 MAC 位址用於虛擬機器的網路介面。 這稱為靜態 MAC。 或者，您可以讓 Hypervisor 動態指派 MAC 位址。 這稱為動態 MAC。 每次啟動虛擬機器時，MAC 位址集區中的 Hyper-V 都會指派動態 MAC 位址。 每一部主機都有一個產生 MAC 位址的配置，使它們不會與另一部主機上的虛擬機器產生衝突。

如果原始環境中的虛擬機器使用靜態 MAC 位址，則複製環境中的虛擬機器將會有相同的 MAC 位址。 這樣很快會導致 MAC 衝突。 重複的 MAC 位址較難以偵測，因為電腦不一定都會回報這些位址。 即使回報了這些位址，Windows 事件檢視器中還是會記錄這類的訊息。 對使用者而言，重複的 MAC 位址有兩種可能的結果。 一種結果是全部或其中一個複製品失去網路連線。 另一種結果是定址到一部電腦的網路封包可以改為到達另一台電腦。 當原始電腦及其複製品具有相同的 MAC 位址時，它們的 IP 位址也相同。 即使使用 DHCP 取得動態 IP 位址時，DHCP 伺服器仍會指派相同的 IP 位址給它們，因為它們的 MAC 位址相同。

在某種程度上，您可以使用動態 MAC 位址避免 MAC 衝突。 不過，當複製的環境還原到原始環境中所擷取的快照時，那些虛擬機器的整個狀態都會復原，包括 MAC 位址在內。 這樣也會導致 MAC 衝突，且先前所述的相同問題會存在到複製的虛擬機器重新啟動為止。 重新啟動複製的環境會導致 Hypervisor 利用本身範圍內的值釋出並更新 MAC 位址。

偵測和解析我們剛說明之各種形式的衝突，然後手動修正 OS/應用程式，以在解析之後繼續工作，對於經常使用虛擬 Lab Management 的使用者而言極為重要、耗費時間，而且容易發生錯誤。 在許多情況下，變更任何參數都會變更虛擬環境，足以導致 Bug 複製的遺失或類似的生產環境問題。 將應用程式安裝到虛擬環境中一次，然後放心複製該環境以建立多個相同複本的原則所需之方法，比預期一般使用者可以做到的方法更為複雜。

網路隔離

到目前為止已確認兩項需求。 第一項需求是複製環境中的虛擬機器具有的電腦名稱、IP 位址和 MAC 位址，必須與原始環境相同。 但是同時必須可從環境外獨立定址這些複製品。 例如，如果某人要從他們的桌面連接到每個複本、如果某應用程式要部署在特定複本上，或是如果某測試要在特定複製品上執行，上述需求是必要的。 這樣會導致第二項需求，複製環境中的虛擬機器必須具有唯一的電腦名稱、IP 位址和 MAC 位址，不可與原始環境相同。 完成這兩項需求的邏輯方式是讓每一部虛擬機器都有兩個介面：電腦名稱、IP 位址和 MAC 位址在每個複製品中都相同的私用介面；以及這些值在每個複製品中都不重複的公用介面。

若要防止私用介面發生網路衝突，它們必須連接至每個複製品中的私人網路。 私人網路是指受限於環境中虛擬機器的虛擬網路。 由於此網路的顯示範圍不會超過環境的界限，因此即使在另一個複製品中使用相同的電腦名稱、IP 位址和 MAC 位址，都不可能發生衝突。 如果想要從環境外存取，所有的公用介面都必須連接至一般公用網路。 公用網路或實驗室網路是指環境的虛擬機器可以在其中與實驗室的用戶端及其他電腦互動的網路。

圖 3 顯示私用介面和公用介面如何解決網路衝突。

包含 VM 且使用私用和公用通訊埠的兩部主機

Visual Studio Lab Management 中的網路隔離

Visual Studio Lab Management 針對 SCVMM 環境實作網路隔離的作法，是在每部虛擬機器中引進兩個網路介面。 其中一個網路介面是連接至私人網路的私用介面，另一個網路介面則是連接至公用網路的公用介面。

Lab Management 軟體與安裝在每部虛擬機器上的代理程式可確保原始環境與複製環境可以同時存在而沒有衝突。

私人網路上的私用介面

以下描述為如何指派電腦名稱、IP 位址和 MAC 位址給環境之私用介面的摘要。

**電腦名稱：**私人網路上的電腦名稱可透過 NetBIOS 解析，不需要 Lab Management 軟體額外進行任何處理。 設定為使用 NetBIOS 電腦名稱的應用程式將會在每個複製品中如預期般運作。 在我們的範例中，Web 伺服器電腦是指使用其名稱的 DB 伺服器電腦。 這些名稱在原始和複製環境中都相同。 因此，在複製環境中無需變更 web.config 檔案。

由於私人網路上沒有 DNS 伺服器，因此當虛擬機器使用完整網域名稱 (FQDN) 而非 NetBIOS 名稱彼此參考時，我們需要解決此狀況。 例如，如果 web.config 檔案參考 DB 伺服器為 db-server.lab.contoso.com，當私人網路上沒有 DNS 時，就會無法將該名稱解析為 IP 位址。 為了解決這個問題，虛擬機器上執行的實驗室代理程式會在 HOSTS 檔案中加入對應於相同環境之其他虛擬機器的項目。 HOSTS 檔案是向作業系統指出名稱必須解析為特定 IP 位址的另一種方式。 在我們的範例中，Web 伺服器上的 HOSTS 檔案將會有下列項目：

192.168.23.2 db-server.lab.contoso.com

**IP 位址：**從 192.168.23.1 到 255 範圍內的靜態 IP 位址會指派給每部虛擬機器的私人網路介面。 例如，Web 伺服器的私用介面取得 192.168.23.1，而 DB 伺服器的私用介面則取得 192.168.23.2。 Lab Management 會確保 Web 伺服器和 DB 伺服器在每個複製品中都取得相同的靜態 IP 位址。 因此，即使利用 DB 伺服器的 IP 位址設定 Web 伺服器上的 web.config 檔案，也無需在複製環境中重新設定。 在任何設定了網路隔離的環境中，私用介面會從這個開頭為 192.168.23.1 的相同範圍取得 IP 位址。 此範圍中所需的位址數目上限與環境中的虛擬機器數目上限相同。 由於這組 IP 位址無法從私人網路外路由傳送，因此只要公用網路上未使用相同的範圍，都可以安全使用預先定義的範圍。

**MAC 位址：**隨機靜態 MAC 位址會指派給網路隔離環境中每部虛擬機器的私人網路介面。 在我們的範例中，原始 Web 伺服器中的私用介面獲得 00-15-5D-07-57-01 之類的 MAC 位址。 Lab Management 會確保此 Web 伺服器在複製環境中也取得相同的 MAC 位址。 由於這組 MAC 位址無法從私人網路外路由傳送，因此只要它們不在 Hypervisor 於該主機上使用的範圍內，都可以安全使用隨機位址。

公用網路上的公用介面

以下描述為如何指派電腦名稱、IP 位址和 MAC 位址給環境之公用介面的摘要。

**電腦名稱：**我們不要 NetBIOS 解析公用網路上的電腦名稱，因為這麼做會導致電腦名稱衝突。 為防止這種情況，Lab Management 在每一部虛擬機器的公用介面上停用 NetBIOS 廣播。 類似於 NetBIOS，我們也不要虛擬機器在 DNS 中登錄它們的 NetBIOS 電腦名稱。 Lab Management 也對每個公用介面停用 DNS 登錄。 在沒有 NetBIOS 和預設 DNS 登錄的情況下，我們仍然希望虛擬機器有唯一名稱可在公用網路上使用。 Lab Management 會代表每部虛擬機器產生唯一別名，並在 DNS 中將該別名登錄為 'A' 記錄。 在我們的範例中，可以使用類似 VSLM-195ea870-34d87df83883add23-47ab86ff.lab.contoso.com 的唯一別名登錄原始環境中的 Web 伺服器。 複製環境中的相同 Web 伺服器則使用類似 VSLM-87ead667a-8787adde877919aaa-2001874d0.lab.contoso.com 的不同名稱進行登錄。

**IP 位址：**每部虛擬機器上的公用網路介面設定為從 DHCP 伺服器取得動態 IP 位址。 這樣可確保原始和複製環境中的虛擬機器具有唯一的 IP 位址。 例如，原始環境中的 Web 伺服器可能會取得 IP 位址 172.52.20.140，而在複製環境中的相同 Web 伺服器則可能取得 IP 位址 172.52.20.205。

**MAC 位址：**如果要防止 MAC 衝突，可以將每部虛擬機器上的公用網路介面設定為從 Hypervisor 取得動態 MAC 位址。 這樣會確保我們範例中的 Web 伺服器電腦在原始和複製環境中取得不同的 MAC 位址。 不過，如先前所述，當複製環境還原到原始環境中所擷取的快照時，複製的虛擬機器之 MAC 和 IP 位址會假設與原始環境相同的值。 例如，當複製的環境還原到最新組建快照時，Web 伺服器的 IP 位址會變成 10.86.51.61 (請參閱圖 3)，這與原始環境中的值相同。 MAC 位址也發生相同的情況。 IP 位址衝突會暫時存在直到被 DHCP 更新為止，然而 MAC 衝突卻會存在直到虛擬機器重新啟動為止。 由於此限制，對公用介面使用從 Hypervisor 動態指派的 MAC 位址並不是可行的方案。

為了解決此問題，Lab Management 會使用自己的 MAC 位址集區。 此集區中的唯一 MAC 位址會指派給虛擬機器的公用介面。 每當複製的環境還原到快照時，Lab Management 都會自動變更 MAC 位址以防止衝突。 如果要了解如何使其生效，請考量原始環境中 Web 伺服器的 MAC 位址為 1D-D8-B7-1C-00-05，而複製環境中 Web 伺服器的 MAC 位址為 1D-D8-B7-1C-00-07。 當複製環境還原到原始環境中擷取的快照時，Web 伺服器的 MAC 位址會暫時變成 1D-D8-B7-1C-00-05。 Lab Management 會將此位址改回 1D-D8-B7-1C-00-07 以防止網路衝突。

與網路隔離的一般互動

接下來，我們將討論當環境內的兩部虛擬機器彼此通訊時會發生什麼情況：

  1. Web 伺服器使用 NetBIOS 或 HOSTS 檔案，將電腦名稱 "db-server" 解析為 db-server 之私用介面的 IP 位址 (192.168.23.2)。

  2. Web 伺服器在此 IP 位址上與 db-server 通訊。

當環境外的用戶端必須與複製環境中的 Web 伺服器通訊時，會遵循下列流程：

  1. 用戶端查詢 Lab Management 軟體以取得複製環境中 Web 伺服器的唯一別名。

  2. Lab Management 軟體以唯一別名回應。

  3. DNS 伺服器將唯一別名解析成 Web 伺服器之公用介面的 IP 位址 (10.86.51.63)。

  4. 用戶端在此 IP 位址上與 Web 伺服器通訊。

網路隔離的替代方法

使用兩個介面並不是網路隔離的唯一方法。 有一個極類似的方法是使用雙向 NAT。 NAT 是建立裝置 (需要與公用網路上的裝置通訊) 之私人網路的常見方法。 即使一般 NAT 中的通訊必須一律源自私人網路，雙向 NAT 仍將此視為向前邁進，並容許由私人網路或公用網路上的電腦啟始通訊。

若要使用此方法實現網路隔離，必須在環境中引進雙向 NAT 伺服器。 將特殊虛擬機器加入履行雙向 NAT 伺服器角色的環境即可完成上述動作。 建立網路隔離環境時，會以兩個介面方法中的相同方式，指派虛擬機器的公用和私人 IP 位址。 不過，對應會儲存在雙向 NAT 伺服器上的 NAT 表格中，而不是將公用 IP 位址指派給虛擬機器中的網路介面。

使用雙向 NAT 公用存取 VM

環境內的兩部虛擬機器使用雙向 NAT 方法彼此通訊的步驟，與兩個介面方法中的步驟完全相同：

  1. Web 伺服器使用 NetBIOS 或 HOSTS 檔案，將電腦名稱 db-server 解析為 db-server 之私用介面的 IP 位址 (192.168.23.2)。

  2. Web 伺服器在此 IP 位址上與 db-server 通訊。

當環境外的用戶端必須與複製環境中的 Web 伺服器通訊時所採取的步驟有些微差異，差異如下：

  1. 藉由實作 NAT 方法，用戶端可以查詢 Lab Management 軟體以取得複製環境中 Web 伺服器的唯一別名。 (Visual Studio Lab Management 不實作 NAT 方法)。

  2. Lab Management 軟體以唯一別名回應。

  3. DNS 伺服器將唯一別名解析成 Web 伺服器的公用 IP 位址 (10.86.51.63)。

  4. 此 IP 位址實際上對應到雙向 NAT 伺服器上的介面。 用戶端會與雙向 NAT 伺服器通訊，但卻假設正在與 Web 伺服器通訊。

  5. NAT 伺服器會擷取儲存在其組態表格中的對應，並將公用 IP 位址 (10.86.51.63) 轉譯成私人 IP 位址 (192.168.23.1)。

  6. NAT 伺服器將訊息從私人網路上的用戶端轉寄至 192.168.23.1，這是 Web 伺服器的 IP 位址。

這種方法上勝過兩個介面方法的益處，在於不需以任何方式修改環境中的虛擬機器。 無需在每一部虛擬機器中引進額外的網路介面。 將額外的網路介面引進虛擬機器可能會導致部分應用程式中斷。

這種方法的另一個益處是達成網路隔離的整個邏輯都已封裝在額外的虛擬機器中。 其他每部虛擬機器中不一定都要有代理程式。 透過額外的虛擬機器路由所有封包，也提供一個額外的控制點，可支援更進階的網路隔離功能，例如：

  • **僅向外柵欄：**不允許由環境外的用戶端所啟始的網路封包到達環境內的虛擬機器。

  • **僅向外但特定連接埠例外：**不允許由環境外的用戶端所啟始的網路封包到達環境內的虛擬機器，除非它們的目標是特定的連接埠。

在 NAT 伺服器上引進防火牆，即可在雙向 NAT 方法中輕易實作這些功能。雙向 NAT 方法的主要缺點在於部分應用程式無法跨 NAT 運作。 例如，當用戶端和伺服器被 NAT 伺服器所分隔時，在 Windows 應用程式中普遍使用的 DCOM 和 .NET 遠端通訊協定就無法運作。 這就是為何 Visual Studio Lab Management 使用雙介面方法的原因。 雙向 NAT 方法的另一個缺點是每個環境中都要有一個額外的虛擬機器，這會在虛擬環境中進行建立或其他作業期間帶來額外的負荷。

其他衝突

到目前為止，我們已說明如何透過網路隔解決電腦名稱、IP 位址和 MAC 位址衝突。 複製環境時，也可能發生其他形式的衝突。 每當有虛擬環境外的外部元件相依性時，複製該環境時有可能會發生衝突。 在本節中，我們查看兩種常見的案例，其中可能會發生這類的衝突。

Active Directory 衝突

Windows 電腦和應用程式常會依賴 Active Directory (AD) 取得目錄服務或使用者驗證及授權。 主要使用 AD 群組原則管理 Windows 電腦是很常見的作法。 使用我們的範例時，假設原始環境中的 Web 伺服器和 DB 伺服器加入受 AD 管理的網域。 AD 裝載於環境外。 當我們複製此環境時，我們有兩個相同的 Web 伺服器複製品；然而，AD 中只有一個項目。 這顯然不是我們所要的，並可能會導致數個問題。 例如，如果某個使用者動作將其中一個 Web 伺服器複製品從網域分離，也會分離另一個複製品。 在一個環境中所做的變更無意中會影響另一個環境。

如果要防止 Active Directory 衝突，必須在環境內的虛擬機器上裝載 AD 伺服器。 該 AD 伺服器不可與環境外的其他目錄有任何信任關係。

要在網路隔離環境內設定 AD，有一些其他的考量。 首先，AD 虛擬機器不可連接至公用網路。 在兩個介面方法中，這表示 AD 虛擬機器不可以有公用介面。 在雙向 NAT 方法中，這表示 NAT 表格不可有 AD 虛擬機器的對應。

第二，由於 AD 位於獨立樹系中，因此環境內必須有一部 DNS 伺服器。 環境中的其他虛擬機器必須在私人網路上使用此 DNS 伺服器，才能與 AD 適當通訊。 舉例而言，虛擬機器可能無法加入私人 AD 中的網域，除非已在私用介面上正確進行 DNS 伺服器設定。

當您設定環境以包含 AD 虛擬機器時，Visual Studio Lab Management 會自動將 AD 從公用網路中斷連接，並以 DNS 設定來設定虛擬機器的私用介面。

可能有一些狀況中無法在環境內裝載 AD。 例如，當開發中的應用程式必須使用公司 AD 與其他現有的公司應用程式整合時，就可能發生這種情況。 當電腦加入環境外的網域時，沒有已知的方案可安全複製環境。

資料庫衝突

另一個常見的虛擬環境用法是關於在環境外裝載應用程式的資料庫。 一般而言，當資料庫夠大，且利用每個環境複製資料庫並不可行時，就會這麼做。 當開發中的應用程式是簡單網頁用戶端，可與他處裝載的資料庫互動時，也可能發生這種情況。 在這類情況下，當兩個相同的複製品與資料庫互動時，資料庫伺服器無法區分兩個用戶端的身分識別。

摘要

建立相同的虛擬環境複製品之能力對於虛擬 Lab Management 中的數個情節非常重要。 然而，建立相同的複製品時，會發生一些電腦名稱、IP 位址和 MAC 位址衝突。 用來修正這些衝突的簡單技術 (如變更電腦名稱或 IP 位址) 通常需要重新設定或重新安裝應用程式，以及有效地使建立相同複製品的意圖失效。 網路隔離可讓您同時建立和執行兩個複製品以解決此問題。

後續步驟

**規劃 SCVMM 環境：**了解何時在 SCVMM 環境中使用不同的選項，例如使用執行中的虛擬機器、預存虛擬機器、範本、預存環境以及網路隔離。 請參閱 建立與管理 SCVMM 環境指引。

**建立網路隔離環境：**如果您已準備好要建立網路隔離環境，請使用本主題。 請參閱 建立和使用網路隔離的環境。

請參閱

概念

自動化系統測試