Experience Sitecore !

Cannot use a Hyper-V disk VHDX image you've been shared with? It can be your colleague's shared VM or a disk exported from Azure VM. Below I am going to describe the steps required to managed it properly.

The first thing one is likely to perform is either importing this disk or creating a new VM without disk and attaching it later. Despite it seems absolutely valid, that will end up with:

If you see the above error it means you've most likely created a VM of 2-nd Generation of Hyper-V, and attached you drive to it. That won't work, but why?

To answer this question let's define the difference between both generations. The main fact about Generation 1 is that it emulates hardware - all required hardware components must be emulated to make the virtual machine work! Special software that can imitate the behaviour of real hardware is included in Hyper-V, as a result the VM can operate with virtual devices. Emulated hardware (that behaves identical to real hardware) includes drivers to most operating systems in order to provide high compatibility.

Generation 1 the emulation works way less productive compared to native equipment and has numerous limitations. Among those:

• a legacy network adapter
  
• IDE controllers with only 2 devices could be attached to each
• MBR with max disk size of 2TB and not more than 4 partitions.
  

The 2-nd Generation uses:

• UEFI BIOS
• GPT support (without size and partitions legacy limit) and Secure Boot
• because of the above - VMs boot (and operate) much faster
• fewer legacy devices and new faster synthetic hardware used instead
• better CPU and RAM consumption
  

UEFI is not just a replacement of BIOS, UEFI extends support of devices and features, including GPT (GUID Partition Table).

Secure Boot is a feature that allows protection against modifying boot loaders and main system files, done by comparing the digital signatures that must be trusted by the OEM.

The solution is quite simple.

What you need to do is create a 1-st Generation VM (without creating a new disk drive) and reference existing VHDX file. That would work and OS will load (slowly but will do). The laziest person would probably stop at this stage, but we progress ahead with converting it to the 2-nd Generation VM. But, how do we?

All you need to do is convert legacy BIOS to UEFI running the following command executed within a 1-st Generation VM:

mbr2gpt.exe /convert /allowFullOS

Please pay attention to the warning: since now you need to boot in UEFI mode.

Now you can turn off the Windows VM, delete existing 1-st Generation VS from Hyper-V Manager (but not the disk drive!), and then create a new 2-nd Generation VM referencing the converted VHDX disk image. Also make sure the attached hard Drive stands first for at the boot sequence order (Firmware tab) and also you may want unchecking Enable Secure Boot switch from the Security tab.

Now you may successfully start your received Hard Drive with a fast and reliable 2-nd Generation VM that manages resources of your host machine in a much reliable and savvy way!

Why not to run Docker containers from within a Hyper-V virtual machine? 

Well, when you are trying to install Docker Desktop for Windows, it installs correctly. But running it will prompt you about Hyper-V is required for Docker to work.

Programs and Features on its turn shows you that Hyper-V is greyed out, so you cannot install it from there

Not everyone knows, but Hyper-V in fact allows having nested virtual machines. That means running docker is also possible from within a VM. All you need is just running one PowerShell command from outside of your container:

Set-VMProcessor -VMName _YOUR_VM_NAME_TO_ENABLE_ -ExposeVirtualizationExtensions $true

What it does - just adds virtualization features into a virtual processor of outer VM, similar to those you got at you physical CPU. Thus you need to run this command of the VM switched off.

Once done, Sitecore perfectly builds and work if Docker running within a virtual machine. For those who are total beginner and scary to mess the things around their host machines - this could be an option. However there is of course a performance penalty from double virtualization.

Finally, the main trick! Just because you've added virtualization extensions into a virtual processor of your VM, you may run docker in process isolation mode, relatively to the build number of VM's operation system. Will explain it on the following example: imagine, your host machine runs Windows 10 build 1809, but got no problems of running Windows 10 build 1909 in a Hyper-V machine there. Now, you after you enable virtualization extensions to that virtual machine (that runs 1909), you will be able to install docker within that virtual machine, and run 1909-built images in process isolation, natively to that VM: 1909-built images run on 1909- machine! But at the same time you will be able to run those same images only in hyper-v mode on the (outer) host machine, because it has 1809 and cannot run non-matching images in process isolation mode.

Hope this helps!

I've been enjoying Docker for a while, its flexibility and optimized images. However, there are two things, in general, I'd like to improve with the ops process:

1. getting more control over the containers
2. obtaining even more persistence, like the ability to create snapshots, switching between them, and few more features very common for traditional VMs

I have a host machine running Windows 10 x64 Professional, that's why I benefit from Hyper-V coming out-of-the-box with this OS. Saying that I mean creating a chain of checkpoints, switching between them, backing up and restoring images as well as other traditional ops activities - that all happens nicely and rapidly! Not to say that VMs work as effective, as the host does - at least I do not feel any difference.

The downside, however, is an extreme size of VMs - some are taking 50+ gigs of drive space!  That's due to Windows 10 running inside, so obviously looking at docker windows systems I felt quite jealous since Windows Server Core takes about 4 gigs and Nano Server is only half a gig! That's still 100 times more than smallest Alpine image, but still the smallest windows unit option possible.

So wondered if that's possible to have Nano Server, but hosted at local Hyper-V in Windows 10, so that I can not just cluster them as many as I may need without any host machine performance impact, but also mix them with other OS VMs sharing the same network and resources. And of course, get the ability to do checkpoints and remote management (PowerShell in that case since Nano does not have any UI). Going ahead, I confirm that all of the above was achieved, and this article explains how.

Content

1. Defining objectives
2. Preparing virtual drive
3. Setting up a VM
4. Running Nano Server
5. Remote administration
6. The result

1. Defining objectives

  

• Running Nano Server as a guest OS from Hyper-V manager using UI.
• Being able to utilize all Hyper-V features, such as checkpoints, backups and restore
• Run several machines in the same stable and configurable virtual network
• Mixing various types of containers, such as bot GUI and non-GUI Windows OS along with Linux
• Get the minimal Windows-based OS with IIS running
• Being able to manage that OS remotely (with PowerShell since that OS does not have UI)

2. Preparing a virtual drive

While you can manually create Nano server virtual hard drive with a (long) PowerShell command, there is a nice tool that allows you to define what you'd like to get as the result. Here's this tool - NanoServerImageBuilder.msi (2.6MB). Once run it will look up for the prerequisites.

If you miss any of the dependencies, Nano Server Image Builder will identify them, download and install:

After installation, you'll have two options, and since we are going to build a virtual hard drive for VM - select the top one:

At this stage, you need to provide Windows Server 2016 installation ISO.

As the dialogue box kindly advises, the server OS image should contain the NanoServer folder at the root of ISO image:

When choosing an edition - pick up Datacenter as it is the smallest one. From optional packages make sure you check IIS as that's among out achievable lisе:

Give a machine name and admin password:

If you intend to manage your VM from a Hyper-V virtual subnet only (and not from outside networks), leave this unchecked:

As for IP address - we'll use DHCP client, but having static IP is an optional benefit - feel free to choose if you need that.

And that's it! As you see, this tool is just a GUI wrapper over a PowerShell command extracting necessary components and generating a Nano Server virtual hard drive out of traditional Windows Server 2016 ISO image. That actual command is listed below as well:

The tool ends up with creating a VHD-file which is a virtual hard drive containing our Nano Server (and yes, it is half-a-gig in size!), but at the next stage we need to create a new VM and attach created drive to it in order to run a VM:

3. Setting up a VM

As usual, create a new Virtual Machine. Once done, attach the drive and complete the wizard:

4. Running Nano Server

In Hyper-V Manager you are now able to run Nano Sever:

That's the only UI you may be able to see from your image. Enter the Administrator password you provided upon image creation:

The choice of available options with UI is not as impressive at all:

Networking is probably the only useful configuration screen here. Obviously, that's where you configure network parameters such as IP addresses, network mask, DHCP and the rest of them - use it not configured network correctly at the stage of preparing a virtual hard drive.

Done and let's finally turn to the most interesting part - remote management!

5. Remote administration

Just before you start, run the command below in order to find out if WSMan in enabled. The WSMan provider is a set of tools for PowerShell that lets you add, change, clear, and delete WS-Management configuration data on local or remote computers. 

The screenshot below tells me it is up and running there at Nano Server:

Test-WsMan IP_ADDRESS

At the next step, you may need to run these two commands: first enables PowerShell Remoting and the second creates a rule of treating everything as a trusted host (it is safer to use exact IP address instead of *-asterisk wildcard).

Enable-PSRemoting           #     we need to enable PowerShell remoting first
Set-Item WSMan:\localhost\Client\TrustedHosts *        #     adding hosts to trusted

Now let's try to execute PowerShell command remotely (within a context of given Nano Server). This command runs code within curly braces on Nano Server - an example below shows root level of remote C-drive:

Invoke-Command -ComputerName 192.168.181.136 -ScriptBlock { Get-ChildItem C:\ } -credential Administrator

Alternatively, you may "enter" an interactive mode (same that you get by using -it with Docker), and run commands one by one, all in the context of remote Nano Server. Let's, for example, navigate into IIS directory and check what is there:

Enter-PSSession -ComputerName 192.168.181.136 -Credential Administrator

6. The result

You might have seen those default HTM and PNG files, coming with IIS by default at the previous remote output. When starting correctly prepared Nano Server, IIS is also up and running showing the default website. 

From now on I can backup, restore and duplicate the instance that has IIS running straight away and is remotely manageable via PowerShell. I can use it as a base image for further experiments without an impact on the performance of a host machine.

Please bear in mind that Nano Server does not support full .NET Framework, so you can only run .NET Core and static websites from such IIS instance. If you need full .NET Framework - use a similar approach with Windows Server Core.

Hope you find this useful!