Earlier this year at Microsoft Build 2018, we announced a third container base image for applications that have additional API dependencies beyond nano server and Windows Server Core. Now the time has finally come and the Windows container image is available for Windows Insiders.
Why another container image?
In conversations with IT Pros and developers there were some themes coming up which went beyond the
windowsservercore container images:
Quite a few customers were interested in moving their legacy applications into containers to benefit from container orchestration and management technologies like Kubernetes. However, not all applications could be easily containerized, in some cases due to missing components like proofing support which is not included in Windows Server Core.
Others wanted to leverage containers to run automated UI tests as part of their CI/CD processes or use other graphics capabilities like DirectX which are not available within the other container images.
With the new
windows container image, we’re now offering a third option to choose from based on the requirements of the workload. We’re looking forward to see what you will build!
How can you get it?
If you are running a container host on Windows Insider build 17704, you can get this container image using the following command:
docker pull mcr.microsoft.com/windows-insider:10.0.17704.1000
To simply get the latest available version of the container image, you can use the following command:
docker pull mcr.microsoft.com/windows-insider:latest
Please note that for compatibility reasons we recommend running the same build version for the container host and the container itself.
Since this image is currently part of the Windows Insider preview, we’re looking forward to your feedback, bug reports, and comments. We will be publishing newer builds of this container image along with the insider builds.
Hyper-V has changed over the last few years and so has our event log structure. With that in mind, here is an update of Ben’s original post in 2009 (“Looking at the Hyper-V Event Log”).
This post gives a short overview on the different Windows event log channels that Hyper-V uses. It can be used as a reference to better understand which event channels might be relevant for different purposes.
As a general guidance you should start with the Hyper-V-VMMS and Hyper-V-Worker event channels when analyzing a failure. For migration-related events it makes sense to look at the event logs both on the source and destination node.
Below are the current event log channels for Hyper-V. Using “Event Viewer” you can find them under “Applications and Services Logs”, “Microsoft”, “Windows”.
If you would like to collect events from these channels and consolidate them into a single file, we’ve published a HyperVLogs PowerShell module to help.
|Event Channel Category
||Events from the Host Compute Service (HCS) are collected here. The HCS is a low-level management API.
||This section is for anything that relates to virtual machine configuration files. If you have a missing or corrupt virtual machine configuration file – there will be entries here that tell you all about it.
||Look at this section if you are experiencing issues with VM integration components.
||Hyper-V clustering-related events are collected in this section.
||This section is used for hypervisor specific events. You will usually only need to look here if the hypervisor fails to start – then you can get detailed information here.
||Events from the Storage Virtualization Service Provider. Typically you would look at these when you want to debug low-level storage operations for a virtual machine.
||These are events form the Virtualization Infrastructure Driver. Look here if you experience issues with memory assignment, e.g. dynamic memory, or changing static memory while the VM is running.
||Events from the virtual machine management service can be found here. When VMs are not starting properly, or VM migrations fail, this would be a good source to start investigating.
||These channels contain events from the virtual network switches.
||This section contains events from the worker process that is used for the actual running of the virtual machine. You will see events related to startup and shutdown of the VM here.
||Events specific to virtual hard disks that can be shared between several virtual machines. If you are using shared VHDs this event channel can provide more detail in case of a failure.
||The VM security process (VMSP) is used to provide secured virtual devices like the virtual TPM module to the VM.
||Events form the Virtual Filtering Platform (VFP) which is part of the Software Defined Networking Stack.
||Events from operations on virtual hard disk files (e.g. creation, merging) go here.
Please note: some of these only contain analytic/debug logs that need to be enabled separately and not all channels exist on Windows client. To enable the analytic/debug logs, you can use the HyperVLogs PowerShell module.
Whenever I want to replace or reinstall a system which is used to run virtual machines with a virtual trusted platform module (vTPM), I’ve been facing a challenge: For hosts that are not part of a guarded fabric, the new system does need to be authorized to run the VM.
Some time ago, I wrote a blog post focused on running VMs with a vTPM on additional hosts, but the approach highlighted there does not solve everything when the original host is decommissioned. The VMs can be started on the new host, but without the original owner certificates, you cannot change the list of allowed guardians anymore.
This blog post shows a way to export the information needed from the source host and import it on a destination host. Please note that this technique only works for local mode and not for a host that is part of a guarded fabric. You can check whether your host runs in local mode by running
Get-HgsClientConfiguration. The property
Mode should list
Local as a value.
Exporting the default owner from the source host
The following script exports the necessary information of the default owner (“
UntrustedGuardian“) on a host that is configured using local mode. When running the script on the source host, two certificates are exported: a signing certificate and an encryption certificate.
Importing the UntrustedGuardian on the new host
On the destination host, the following snippet creates a new guardian using the certificates that have been exported in the previous step.
Please note that importing the “UntrustedGuardian” on the new host has to be done before creating new VMs with a vTPM on this host — otherwise a new guardian with the same name will already be present and the creation with the PowerShell snippet above will fail.
With these two steps, you should be able to migrate all the necessary bits to keep your VMs with vTPM running in your dev/test environment. This approach can also be used to back up your owner certificates, depending on how these certificates have been created.
Have you ever wondered whether it is possible to add your own custom images to the list of available VMs for Quick Create?
The answer is: Yes, you can!
Since quite a few people have been asking us, this post will give you a quick example to get started and add your own custom image while we’re working on the official documentation. The following two steps will be described in this blog post:
- Create JSON document describing your image
- Add this JSON document to the list of galleries to include
Step 1: Create JSON document describing your image
The first thing you will need is a JSON document which describes the image you want to have showing up in quick create. The following snippet is a sample JSON document which you can adapt to your own needs. We will publish more documentation on this including a JSON schema to run validation as soon as it is ready.
To calculate the SHA256 hashes for the linked files you can use different tools. Since it is already available on Windows 10 machines, I like to use a quick PowerShell call:
Get-FileHash -Path .contoso_logo.png -Algorithm SHA256
The values for
thumbnail are optional, so if there are no images at hand, you can just remove these values from the JSON document.
Step 2: Add this JSON document to the list of galleries to include
To have your custom gallery image show up on a Windows 10 client, you need to set the
GalleryLocations registry value under
There are multiple ways to achieve this, you can adapt the following PowerShell snippet to set the value:
If you don’t want to include the official Windows 10 developer evaluation images, just remove the fwlink from the GalleryLocations value.
Have fun creating your own VM galleries and stay tuned for our official documentation. We’re looking forward to see what you create!
Did you ever have to troubleshoot issues within a Hyper-V cluster or standalone environment and found yourself switching between different event logs? Or did you repro something just to find out not all of the important Windows event channels had been activated?
To make it easier to collect the right set of event logs into a single evtx file to help with troubleshooting we have published a HyperVLogs PowerShell module on GitHub.
In this blog post I am sharing with you how to get the module and how to gather event logs using the functions provided.
Step 1: Download and import the PowerShell module
First of all you need to download the PowerShell module and import it.
Step 2: Reproduce the issue and capture logs
Now, you can use the functions provided as part of the module to collect logs for different situations.
For example, to investigate an issue on a single node, you can collect events with the following steps:
Using this module and its functions made it a lot easier for me to collect the right event data to help with investigations. Any feedback or suggestions are highly welcome.