How to fix: Error response from daemon: container *** encountered an error during CreateContainer: failure in a Windows system call: No hypervisor is present on this system

The problem Last week I provided a Docker on Windows workshop for one of our customers. Some developers got stuck in the installation of Docker on Windows on their Windows 10 development machines. While the Docker on Windows installer succeeded, they got the following issue thrown by the Docker daemon when trying to initialize new Windows containers from the Docker CLI. C:\Program Files\Docker\Docker\Resources\bin\docker.exe: Error response from daemon: container 6314c9d6f09bc751b86d99277 e0840037c78ca5da31a591a0544bb8de1b29179 encountered an error during CreateContainer: failure in a Windows system call: N o hypervisor is present on this system. (0xc0351000) extra info: {“SystemType”:”Container”,”Name”:”6314c9d6f09bc751b86d9 9277e0840037c78ca5da31a591a0544bb8de1b29179″,”Owner”:”docker”,”IsDummy”:false,”IgnoreFlushesDuringBoot”:true,”LayerFolde rPath”:”C:\\ProgramData\\Docker\\windowsfilter\\6314c9d6f09bc751b86d99277e0840037c78ca5da31a591a0544bb8de1b29179″,”Layer s”:[{“ID”:”330e1892-ab72-5af5-9029-2dba818740f2″,”Path”:”C:\\ProgramData\\Docker\\windowsfilter\\7d3353dfd3626f71d85cdd9 2073caa629be47788bf19ad69cead29324bc3284c”},{“ID”:”58769865-f1ab-511f-9f09-6a45f9d324cb”,”Path”:”C:\\ProgramData\\Docker \\windowsfilter\\1136d91f8b39eed82e2883e213665024e93ac70fd955e3cdea909d37108f6bf4″}],”HostName”:”6314c9d6f09b”,”MappedDi rectories”:[],”SandboxPath”:”C:\\ProgramData\\Docker\\windowsfilter”,”HvPartition”:true,”EndpointList”:[“8da1f34c-339b-4 a9f-ba2c-18d42a8780a2″],”HvRuntime”:{“ImagePath”:”C:\\ProgramData\\Docker\\windowsfilter\\7d3353dfd3626f71d85cdd92073caa 629be47788bf19ad69cead29324bc3284c\\UtilityVM”},”Servicing”:false,”AllowUnqualifiedDNSQuery”:true}. A quick Google search did not give the solution we where looking for. So I thought it would be helpful to share the steps we followed to solve this issue. The situation The Docker installer did enable the necessary Hyper-V feature to be able to run Windows containers natively on Windows 10 via Hyper-V (Windows 10 only supports Hyper-V containers).

How to solve: Manifest Unknown pulling a Windows container from Azure Container Registry

Currently I am helping different customers in implementing containerized delivery for their .NET applications on Windows hosts. One important part of the containerized delivery infrastructure is the so-called Container Registry. There are different on-premise and cloud registry products available for storing your company owned Windows Container Images like the Nexus Repository, Artifactory for on-premise situations and the Docker Trusted Registry, Azure Container Registry, AWS Container Registry and Google Container Registry for cloud scenario’s. Because we are creating a new cloud platform based on Microsoft Azure we also decided to make use of the Azure Container Registry for storing our Windows container images. While making the delivery pipeline work, we faced the following issue in pulling earlier pushed container images from the Azure Container Registry. A not very user friendly message.. We pushed our image with the 29 version tag successful to the Azure Container registry as shown below. So what’s going on? I navigated to the Azure portal to

Deep dive into Windows Server Containers and Docker – Part 2 – Underlying implementation of Windows Server Containers

With the introduction of Windows Server 2016 Technical Preview 3 in August 2015, Microsoft enabled the container technology on the Windows platform. While Linux had its container technology since August 2008 such functionality was not supported on Microsoft operating systems before. Thanks to the success of Docker on Linux, Microsoft decided almost 3 years ago to start working on a container implementation for Windows. Since September 2016 we are able to work with a public released version of this new container technology in Windows Server 2016 and Windows 10. But what is the difference between containers and VMs? And how are Windows containers implemented internally within the Windows architecture? In this blogpost we’ll dive into the underlying implementation of containers on Windows. Containers vs VMs Many container introductions start with the phrase that “Containers are lightweight VMs”. Although this may help people to get a conceptual understanding of what containers are,  it is important to notice that this statement is a 100% wrong and can be very

Deep dive into Windows Server Containers and Docker – Part 1 – Why should we care?

With the introduction of Windows Server 2016 Technical Preview 3 in August 2015, Microsoft enabled the container technology on the Windows platform. While Linux had its container technology since August 2008 such functionality was not supported on Microsoft operating systems before. Thanks to the success of Docker on Linux, Microsoft decided 2,5 years ago to start working on a container implementation for Windows. Currently we are able to test this new container technology on Windows Server 2016 and Windows 10. Last September (2016) Microsoft finally announced that it released Windows Server 2016 to the public. But what does that mean for me as a developer or for us as an enterprise organisation? In this deep dive serie of blogposts we’re gonna look at the different aspects of working with Windows Containers, Docker and how containers will change the way we deliver our software. But first, in this first blogpost of this serie, we will answer the question why we should even care about containers… Why should

Powershell script to make use of @CurrentIteration query token in TFS queries

Since the introduction of Visual Studio 2013 update 5, a new query token (@CurrentIteration) is available to automatically identify the current iteration of your iteration path, based on today’s date. By using this query token in queries that are related to the current iteration/sprint, you will save a lot of time in managing those queries (as mentioned in my previous blogpost). However, once upgraded to Visual Studio 2013 update 5 or higher, you have to manually update your queries to make use of this new @CurrentIteration query token. This may cost you a lot of time. For that reason, I’ve made a powershell script to automatically implement the @CurrentIteration query token for the shared queries of your team project (see the code below or the attached zip file). After downloading/unzipping, just specify your own values for the different variables and run the powershell script. EnableCurrentIterationQueryToken  

How to deal with the current sprint/iteration in TFS queries?

During my work as an ALM consultant, I get a lot of questions about how to define a stable iteration (and area) path structure in your TFS Team Project. I thought it would be helpful, to share with you one of the things I always discuss with teams that are working with the SCRUM or Agile process template; dealing with the current sprint/iteration. So what’s the problem? Once teams are working with the Agile planning tools of TFS, most of the (shared) work item queries they are working with, are related to the current sprint/iteration they’re working on. Think of a query which shows us the open defects of the current iteration. Or take for example the set of default SCRUM queries that are delivered when creating a new Team Project based on the SCRUM process template. Because of this overbalance of sprint/iteration related queries, it is important that the defined iteration path structure and

Changing the Default CheckIn Action in TFS

For some weeks ago, I had a team ask me if it was possible to change the default CheckIn action for relating a work item to a check-in in TFS. After finding different solutions, I thought it would be helpful to share with you the different options I found. So what’s the problem? As you will know, when you want to relate a work item with your check-in in TFS, you have to choose between two CheckIn actions: Associate or Resolve. The first one, Associate, is used to just link the work item with the future changeset. The second one, Resolve, also automatically closes the work item on check-in. By default, your Visual Studio client will select the Resolve action on check-in. For some situations this is very helpful. However, when you want to use the Associate action most of the time, it is very annoying and inefficient to change the CheckIn action each time