The Gluster Blog

Gluster blog stories provide high-level spotlights on our users all over the world

Migrating VMs from Windows Server 2008 R2 to Windows Server 2012 R2



I had an existing Windows Server 2008 R2 machine running 12 VMs utilizing local storage, but quickly outgrew the specs of that machine. This meant a migration to new hardware as well as an upgrade to Windows Server 2012 R2 from Windows Server 2008 R2. In addition, I was constructing a poor-man’s SAN utilizing the existing machine as the storage server.

Step 1: Remove Existing VM Snapshots

Prior to migrating, all VM snapshots needed to be removed and re-combined into single VHD files. This process took a rather long period of time to process (while VMs were still functional).

Step 2: Install Windows 2012 R2 on New Server (VM Host)

While the VM snapshots were condensing, I began the OS install on the new VM Host machine. This process is very straight forward and simple (if you are familiar with Windows Server installations). Once the installation was completed, I joined the new machine (Halo-Host-01) to the existing domain (Halo.local).

I simply installed the Hyper-V role and did some very basic system and Hyper-V configuration (dedicating a single NIC to the virtual switch, configuring a dedicated management NIC, and configured the dedicated NIC for the SAN network).

There was no need to delve too deeply into Live Migration and failover configuration as I only had a single VM Host server.

Step 2: Install Windows 2012 R2 on the Existing Server (Storage Server)

This step required a service outage (it was done over a holiday weekend to minimize any disruptions). The existing VM’s were all shutdown gracefully. Once all VMs were stopped it was time to re-install the OS (by performing a clean install of Windows 2012 R2). This process was quick and again a very simple procedure.

Once the OS installation was completed, I configured the dedicated NIC for all LAN traffic as well as the dedicated NIC for SAN traffic. Next, the server (HaloFS) was joined to the domain (Halo.local). Finally, the File and Storage Services roles for iSCSI Target Server was installed (to enable creation of iSCSI disks to be published to the Halo-Host-01.

Step 3: Publish the iSCSI Target on HaloFS

File And Storage Services iSCSI ManagementThe first part of this is to configure the iSCSI Target server on HaloFS. This is accomplished by navigating to the iSCSI Management page within the File and Storage Services menu of the Server Management Console on HaloFS. This is shown to the right.



New iSCSI Virtual Disk MenuOnce there, under the tasks menu (on the right side of the iSCSI Virtual Disks pane) select the New iSCSI Virtual Disk option (as shown to the right).


While navigating the wizard, select the disk and give the new virtual disk a name. On the next page you will specify the size and type of VHD you will be creating.

iSCSI Virtual Disk Type

Since this is a VM Host VHD performance is most important and space is not at a premium. Therefore I choose a fixed disk type. This also comes with a checkbox for “clear the virtual disk on allocation”. This option writes zeros over the entire VHD allocation to ensure no data contamination. It is highly recommended to perform this, but it will take a very long time (depending on the allocation size).


In my case I had selected 1.5 TB of space and it took nearly 24 hours to complete after the wizard was completed.

The next steps of the wizard will walk you through the process of adding the correct initiator association for the VHD.

After the wizard is completed, be prepared to wait for the allocation process to complete.

Step 4: Mount iSCSI Target on Halo-Host-01

Next comes the fun part, mounting the iSCSI Target on the host machine so that we can begin to utilize the storage. In order to do this is is important to follow these steps carefully (as I learned that the use of a dedicated SAN network requires additional manual configuration for the iSCSI Initiator on Halo-Host-01 to function properly).

Server Manager Tools Menu

The first step is to navigate to the iSCSI Initiator tool from the Server Management Console (as shown to the right).

You will be immediately shown the Quick Connect screen. This screen will NOT work in the scenario we have (using a dedicated SAN network for iSCSI traffic). It will show connected if you use it, but the drive will not mount and will remain inaccessible. I spent quite a lot of time trying to resolve my connectivity issue (that I thought I had).

Instead, we will move to the second tab called Discovery. This tab will allow us to discover the iSCSI Targets based on some additional information. The first step is to click the Discover Portal button (just beneath the Target Portals box). I then entered the IP address of the remote SAN IP of the iSCSI Target server (HaloFS in my instance). Before clicking ok, you will need to click the Advanced button.

iSCSI Initiatior Advanced DiscoveryFrom here you will need to select the Microsoft iSCSI Initiator as the Default Adapter. This will then enable the Initiator IP drop down  and you can then select the SAN IP address from the list (as shown).

Assuming you bypassed the security configuration steps on the previous server you may now hit ok to close the window.

The next step here is to make sure the new target is added to the Favorite Targets tab. Only the targets listed on the favorites list will be connected at system boot time.

Finally, verify the mount is visible on the Volumes and Devices tab. If it is not, try using the Auto Configure button. If that still does not work please revisit the previous steps as the Target is not able to be mounted and is indicative of a configuration issue. (Note: This is where the quick connect configured targets will fail to register).

Once all of this is completed the drive can be managed with Disk Management just as any physical drive. The process for formatting and partitioning the drive is the same and is left out due to the simplicity of it but is a mandatory step.

Step 5: Move VM VHDs to New Drive

The next step is to move all of the VHD files from HaloFS to the newly created iSCSI drive. This is done over the LAN in order to enable rapid transfer of the data back to the storage server via the SAN (basically moving the data in a large circle at 1 GB/s). This process takes several hours depending on the size of the VHDs to move.

 Step 6: Move VM Configuration Files and Import

For each VM the existing VM configuration file will need to be migrated to the new host (Halo-Host-01). Once copied over to the new Hyper-V default configuration folder (specified during the initial Hyper-V set up), you will need to run the import Virtual Machine wizard. This will walk you through the process of re-mapping the VHD files to the new location as well as registering them within the Hyper-V management console.

After all of the VMs are imported, they are ready to be restarted. Once they boot you will want to verify they are functioning properly (the virtual switch identifiers my have change and may require the virtual NICs to be updated to look at the new switch for proper network access).

Otherwise, everything is now migrated over onto a new host machine running Windows 2012 R2 utilizing a dedicated SAN for all VM storage from the existing Windows 2008 R2 host with local VM storage.


  • 06 Dec 2020
    Looking back at 2020 – with g...

    2020 has not been a year we would have been able to predict. With a worldwide pandemic and lives thrown out of gear, as we head into 2021, we are thankful that our community and project continued to receive new developers, users and make small gains. For that and a...

    Read more
  • 27 Apr 2020
    Update from the team

    It has been a while since we provided an update to the Gluster community. Across the world various nations, states and localities have put together sets of guidelines around shelter-in-place and quarantine. We request our community members to stay safe, to care for their loved ones, to continue to be...

    Read more
  • 03 Feb 2020
    Building a longer term focus for Gl...

    The initial rounds of conversation around the planning of content for release 8 has helped the project identify one key thing – the need to stagger out features and enhancements over multiple releases. Thus, while release 8 is unlikely to be feature heavy as previous releases, it will be the...

    Read more