Upgrade Hyper-V to Nano Server with zero VM downtime

A how to guide for upgrading a Hyper-V Cluster to Nano Server with no VM downtime

Hyper-V to Nano Server with no downtime

Upgrading Hyper-V to Nano Server is relatively straight forward.  A Nano Server image should be created for each Hypervisor in your Hyper-V cluster.  Each of those Nano Server images should be customized to mimic the settings and configuration of the Hypervisor that they will be replacing.  You can then copy the customized Nano Server image to the respective Hypervisor, mount it, adjust the windows boot settings – and upon reboot – the Hypervisor will now be running with Nano.  This method combined with evicting and adding back nodes from your Hyper-V cluster allows you to move your Hyper-V cluster to Nano Server with no VM downtime.

If you prefer video format over written documentation I demonstrate upgrading a clustered Hyper-V to Nano Server with zero downtime in the following Techthoughts video:

How to: Moving Hyper-V to Nano Server with no downtime

Disclaimer: An OS upgrade of your cluster is a major change to your environment and you should give careful thought and consideration before performing this in production.  The video above and the steps below highlight how relatively easily this is carried out, but the simplicity of this procedure should not detract from how much planning you should be putting in to this process. Test!

Disclaimer 2: Nano is a significant departure from previous versions of Windows.  In the entirety of my IT career Nano is the most significant change to the Windows OS that I’ve seen.  You should review all the capabilities and limitations of the Nano Server OS and the unique needs of your organization to make a determination if Nano Server makes sense for your environment prior to performing this upgrade.

  1. Create a Nano Image for each Hypervisor node in your cluster
  2. Review the settings of each Hypervisor node in you cluster and customize each Nano image to take on the same IP/settings/etc of the existing Hypervisor node
  3. Create the domain join blob file for each Hyp

 

  1. Live Migrate all VMs and resources off the first Hypervisor Node to be upgraded
  2. Pause the node
  3. Copy newly created Nano Server VHDX to existing Hyp (Ex: C:\Nano\ImageName.vhdx)
  4. Mount C:\Nano\ImageName.vhdx  and take note of the drive letter (right click VHDX and click mount)
  5. Edit D:\Windows\Setup\Scripts\SetupComplete.cmd to run your PowerShell customization script

  6. Copy your PowerShell customization script over to the mounted image (Ex. NanoSetup.ps1)
  7. Copy over the domain join blob file
  8. Evict the node from the cluster
  9. Create the boot files for the server to boot into the new Nano image
    • How to allow server to boot to Nano VHDX
      1. Open an administrator command window
      2. Run the following command to adjust the boot properties of the server to boot off the Nano image:
        • bcdboot D:\Windows
          • D: will be the mounted drive letter of your Nano Server VHDX
  10. Reboot the server
  11. Server will automatically reboot to Nano, it will take up to 10 minutes for the SetupComplete.cmd command to run at which point you should be able to remotely manage your new nano server depending on what customization you created in your configuration
  12. Verify new Nano Server has joined the domain and good DNS records have been created
  13. Establish PSSession and reconfigure Nano back to any desired settings you didn’t create in your PowerShell customization script (team/virtual swtich, etc)
  14. Once satisfied that Hyp is reconfigured back to mirror the original Hypervisor (domain joined/IP’d/Virtual Switches, etc) you can add the node back into the cluster – test the cluster as appropriate
  15. Once new Nano Server node is back in the cluster attempt to Live Migrate a test VM to this new node
  16. Verify test VM is running as expected
  17. Repeat process until all Hyper-V nodes are converted to Nano Server

Rolling back if the upgrade isn’t working as expected

One of the nice benefits of upgrading using this method is the ease of rollback.  Your original server is still very much intact and nothing has changed regarding it or its settings.  If the upgrade isn’t going as planned and you feel the need to roll back simply reboot the machine.

The boot settings you altered previously allow a 30 second option to choose the original OS before it automatically boots to Nano Server.

Select to boot to the original OS.

Once in the original OS you can remove the Nano Server boot option completely if you wish.

Open an administrative command window and type: bcdedit /v

This will give you an output similiar to the following and you will need to find the identifier for the Nano Server boot:

Windows Boot Loader
-------------------
identifier              {1b95f116-1d7d-11e6-80b9-0026b95ebe6d}
device                  vhd=[C:]\Nano\HypV1N.vhdx,locate=custom:12000002
path                    \Windows\system32\boot\winload.exe
description             Windows Server 2016
locale                  en-us
inherit                 {6efb52bf-1766-41db-a6b3-0ee5eff72bd7}
allowedinmemorysettings 0x15000075
osdevice                vhd=[C:]\Nano\HypV1N.vhdx,locate=custom:22000002
systemroot              \Windows
resumeobject            {fb218d27-b690-11e6-8182-806e6f6e6963}
nx                      OptIn
hypervisorlaunchtype    Auto 

 

Once you have the identifier you can delete it with the following command:

bcdedit /delete {1b95f116-1d7d-11e6-80b9-0026b95ebe6d}

Steps to take once all cluster nodes are upgraded to Nano Server

Upgrade Cluster Functional Level

Once all nodes are upgraded to Nano your cluster will still be sitting on the original “functional level” of the original OS.  For example, if all nodes were previously 2012R2 Hyper-V servers, then the cluster will still be at that functional level.

Once you are satisfied with everything you can upgrade the cluster to a 2016 functional level by following the process outlined in the following Technet article:

https://technet.microsoft.com/en-us/windows-server-docs/failover-clustering/cluster-operating-system-rolling-upgrade

Note: The upgrade process is reversible until the “point-of-no-return”, when all cluster nodes are running Windows Server 2016, and when the Update-ClusterFunctionalLevel PowerShell cmdlet is run.

Upgrade Virtual Machine version

With all clustered nodes now running Nano Server and the cluster functional level on Server 2016 you can now think about upgrading the VM versions to take advantage of a lot of new features.

New feature-sets and a guide on how to upgrade your VM version can be found here:

https://technet.microsoft.com/en-us/windows-server-docs/compute/hyper-v/deploy/upgrade-virtual-machine-version-in-hyper-v-on-windows-or-windows-server

Note: This process is not reversible.  Also take note that once a VM version is upgraded it will not be able to run on Hyper-V servers running an older OS

Example of a Nano Server Image for my Hypervisor:

Below you can reference a command I leveraged for created a Nano Server Hypervisor Image:

New-NanoServerImage -MediaPath 'C:\Users\Administrator\Desktop\Nano' `
                    -Edition 'Datacenter' `
                    -DeploymentType Host `
                    -TargetPath 'C:\Users\Administrator\Desktop\HypV1C.vhdx' `
                    -MaxSize 8589934592 `
                    -EnableRemoteManagementPort `
                    -SetupUI ('NanoServer.Containers', 'NanoServer.FailoverCluster', 'NanoServer.Compute', 'NanoServer.SecureStartup', 'NanoServer.OEM-Drivers', 'NanoServer.ShieldedVM', 'NanoServer.SCVMM.Compute', 'NanoServer.DSC', 'NanoServer.Defender') 
                    `-ServicingPackagePath ('C:\Users\Administrator\Desktop\Nano\NanoUpdates\Windows10.0-KB3176936-x64.cab', 'C:\Users\Administrator\Desktop\Nano\NanoUpdates\Windows10.0-KB3192366-x64.cab') `
                    -ComputerName 'HYPV1N' `
                    -SetupCompleteCommand ('tzutil.exe /s "Central Standard Time"') `
                    -LogPath 'C:\Users\Administrator\AppData\Local\Temp\NanoServerImageBuilder\Logs\2016-11-29 13-34'

Be the first to comment

Leave a Reply

Your email address will not be published.


*