Virtualization articles

Hyper-V HyperClear RETbleed Update

brucesherwin — Tue, 19 Jul 2022 16:21:34 GMT

Multiple new speculative execution side channel issues were recently disclosed by both Intel and AMD. These issues were described in security bulletins available here:

These hardware vulnerabilities are officially referred to as CVE-2022-23825 (Branch Type Confusion), CVE-2022-29900 (RETbleed), CVE-2022-29901 (Return Stack Buffer Underflow (RSBA)) and CVE-2022-28693 (Return Stack Buffer Underflow (RRSBA)).

In many ways, these issues are very similar to the Spectre (variant 2) side channel attack which was disclosed in early 2018. Since that time, Microsoft’s core virtualization engineering team has been working hard at developing and optimizing our hypervisor’s comprehensive and highly efficient side channel mitigation, HyperClear.

When I last provided an update in 2019, I indicated that only minor changes were required to protect our customers from a large set of hardware vulnerabilities that could lead to disclosure of private data from microarchitectural buffers within an Intel CPU. I’m happy to share that once again, no significant HyperClear updates were needed to mitigate these new vulnerabilities and help protect our customers.

As described in the first two HyperClear blog posts, our side channel mitigation technique relies on 3 main components to ensure strong inter-VM isolation:

Core Scheduler: to avoid sharing of a CPU core’s private buffers and other resources
Virtual-Processor Address Space Isolation: to avoid speculative access to another virtual machine’s memory or another virtual CPU core’s private state
Sensitive Data Scrubbing: to avoid leaving private data anywhere in hypervisor memory other than within a virtual processor’s private address space so that this data cannot be speculatively accessed in the future

Once again, the Hyper-V HyperClear architecture has proven to be a readily extensible design that helps provide strong isolation boundaries against a variety of speculative execution side channel attacks with negligible impact on performance.

AMD Nested Virtualization Support

chuybregts — Sat, 13 Jun 2020 00:26:50 GMT

Nested Virtualization is not a new idea. In fact, we announced our first preview of Nested Virtualization running on Windows way back in 2015. From that Windows Insider preview to now, Nested Virtualization has been used in a variety of offerings in a variety of ways. Today, you can find Nested Virtualization support in Azure that gives the Azure users flexibility in how they want to setup their environments. An example of Nested Virtualization being used to support our developer community is to accelerate Microsoft’s Android Emulation. Nested Virtualization is being used by IT Pros to set up a home labs. And we can’t forget containers! If you want to use a Hyper-V Containers inside a VM, you guessed it: this is enabled with Nested Virtualization. You can start to see why Nested Virtualization is such a useful technology.

There is one group of users that was unable to take advantage of Nested Virtualization on Windows. These were our users with AMD hardware. Not a week goes by where the team doesn’t get a request for Nested Virtualization support for AMD from our community or from within Microsoft. In fact, it is the number 1 ask on Windows Server’s uservoice page. At the time of this blog post, it was almost 5x more than the next feedback item.

I am happy to announce that the community has been heard and starting with Windows Build 19636, you will be able to try out Nested Virtualization on AMD processors! If you’re on the Windows Insider Fast ring then you can try this out today.

As this is a preview release of Nested Virtualization on AMD, there are some guidance and limitations to keep in mind if you want to try this out.

Ensure your OS build number is 19636 or greater
Right now, this has been tested on AMD’s first generation Ryzen/Epyc or newer processors
For maximum stability and performance use a Windows guest with an OS version that is greater than or equal to the host OS version (19636) for now. Linux KVM guest support will be coming in the future
Create a version 9.3 VM. Here’s an example PowerShell command to ensure a version 9.3 VM is being used: New-Vm -VMName “L1 Guest” -Version 9.3
Follow the rest of the steps in our public documentation

June 12, 2020 edit: changed wording around Guest OS recommendation.

VMware Workstation and Hyper-V

chuybregts — Fri, 29 May 2020 06:19:08 GMT

As a follow up to our previous post on VMware and Hyper-V Working Together, VMware has released a version of VMware Workstation that works with the Windows Hypervisor Platform (WHP). This release adds support for VMware Workstation running side by side with Microsoft’s virtualization based offerings. For a full write up on the changes VMware made and the details on the version required check out their excellent post here.

In Windows 10, we introduced a number of features that utilize the Windows Hypervisior. These include security enhancements like Windows Defender Credential Guard, Windows Defender Application Guard, and Virtualization Based Security as well as developer features like Windows Containers and WSL 2. Prior to the WHP integration, these features needed to be disabled before Workstation was able to launch. Post integration, end users are now able to take advantage of these features and use Workstation!

A big thank you and congratulations go out to the engineering teams of both companies that made this possible. This milestone was reached through their hard work and dedication and I’m excited to see the results of this effort being released to the world!

Hyper-V Powering Windows Features

nickeaton — Thu, 12 Dec 2019 22:31:20 GMT

December 2019

Hyper-V is Microsoft’s hardware virtualization technology that initially released with Windows Server 2008 to support server virtualization and has since become a core component of many Microsoft products and features. These features range from enhancing security to empowering developers to enabling the most compatible gaming console. Recent additions to this list include Windows Sandbox, Windows Defender Application Guard, System Guard and Advanced Threat Detection, Hyper-V Isolated-Containers, Windows Hypervisor Platform and Windows Subsystem for Linux 2. Additionally, applications using Hyper-V, such as Kubernetes for Windows and Docker Desktop, are also being introduced and improved.

As the scope of Windows virtualization has expanded to become an integral part of the operating system, many new OS capabilities have taken a dependency on Hyper-V. Consequently, this created compatibility issues with many popular third-party products that provide their own virtualization solutions, forcing users to choose between applications or losing OS functionality. Therefore, Microsoft has partnered extensively with key software vendors such as VMware, VirtualBox, and BlueStacks to provide updated solutions that directly leverage Microsoft virtualization technologies, eliminating the need for customers to make this trade-off.

Windows Sandbox

Windows Sandbox is an isolated, temporary, desktop environment where you can run untrusted software without the fear of lasting impact to your PC. Any software installed in Windows Sandbox stays only in the sandbox and cannot affect your host. Once Windows Sandbox is closed, the entire state, including files, registry changes and the installed software, are permanently deleted. Windows Sandbox is built using the same technology we developed to securely operate multi-tenant Azure services like Azure Functions and provides integration with Windows 10 and support for UI based applications.

Windows Defender Application Guard

Windows Defender Application Guard (WDAG) is a Windows 10 security feature introduced in the Fall Creators Update (Version 1709 aka RS3) that protects against targeted threats using Microsoft’s Hyper-V virtualization technology. WDAG augments Windows virtualization based security capabilities to prevent zero-day kernel vulnerabilities from compromising the host operating system. WDAG also enables enterprise users of Microsoft Edge and Internet Explorer (IE) protection from zero-day kernel vulnerabilities by isolating a user’s untrusted browser sessions from the host operating system. Security conscious enterprises use WDAG to lock down their enterprise host while allowing their users to browse non-enterprise content.

Application Guard isolates untrusted sites using a new instance of Windows at the hardware layer.

Windows Defender System Guard

In order to protect critical resources such as the Windows authentication stack, single sign-on tokens, the Windows Hello biometric stack, and the Virtual Trusted Platform Module, a system's firmware and hardware must be trustworthy. Windows Defender System Guard reorganizes the existing Windows 10 system integrity features under one roof and sets up the next set of investments in Windows security. It's designed to make these security guarantees:

To protect and maintain the integrity of the system as it starts up
To validate that system integrity has truly been maintained through local and remote attestation

Windows Defender Advanced Threat Detection

Detecting and stopping attacks that tamper with kernel-mode agents at the hypervisor level is a critical component of the unified endpoint protection platform in Microsoft Defender Advanced Threat Protection (Microsoft Defender ATP). It’s not without challenges, but the deep integration of Windows Defender Antivirus with hardware-based isolation capabilities allows the detection of artifacts of such attacks.

Hyper-V Isolated Containers

Hyper-V plays an important role in the container development experience on Windows 10. Since Windows containers require a tight coupling between its OS version and the host that it runs on, Hyper-V is used to encapsulate containers on Windows 10 in a transparent, lightweight virtual machine. Colloquially, we call these "Hyper-V Isolated Containers". These containers are run in VMs that have been specifically optimized for speed and efficiency when it comes to host resource usage. Hyper-V Isolated Containers most notably allow developers to develop for multiple Linux distros and Windows at the same time and are managed just like any container developer would expect as they integrate with all the same tooling (e.g. Docker).

Windows Hypervisor Platform

The Windows Hypervisor Platform (WHP) adds an extended user-mode API for third-party virtualization stacks and applications to create and manage partitions at the hypervisor level, configure memory mappings for the partition, and create and control execution of virtual processors. The primary value here is that third-party virtualization software (such as VMware) can co-exist with Hyper-V and other Hyper-V based features. Virtualization-Based Security (VBS) is a recent technology that has enabled this co-existence.

WHP provides an API similar to that of Linux's KVM and macOS's Hypervisor Framework, and is currently leveraged on projects by QEMU and VMware.

This diagram provides a high-level overview of a third-party architecture.

Windows Subsystem for Linux 2

WSL 2 is the newest version of the architecture that powers the Windows Subsystem for Linux to run ELF64 Linux binaries on Windows. Its feature updates include increased file system performance as well as added full system call compatibility. This new architecture changes how these Linux binaries interact with Windows and your computer’s hardware, but still provides the same user experience as in WSL 1 (the current widely available version). The main difference being that WSL 2 uses a new architecture, which is primarily running a true Linux kernel inside a virtual machine. Individual Linux distros can be run either as a WSL 1 distro, or as a WSL 2 distro, can be upgraded or downgraded at any time, and can run WSL 1 and WSL 2 distros side by side.

Kubernetes Support for Windows

Kubernetes started officially supporting Windows Server in production with the release of Kubernetes version 1.14 (in March 2019). Windows-based applications constitute a large portion of the workloads in many organizations. Windows containers provide a modern way for these Windows applications to use DevOps processes and cloud native patterns. Kubernetes has become the de facto standard for container orchestration; hence this support enables a vast ecosystem of Windows applications to not only leverage the power of Kubernetes, but also to leverage the robust and growing ecosystem surrounding it. Organizations with investments in both Windows-based applications and Linux-based applications no longer need to look for separate orchestrators to manage their workloads, leading to increased operational efficiencies across their deployments. The engineering that supported this release relied upon open source and community led approaches that originally brought Windows Server containers to Windows Server 2016.

These components and tools have allowed Microsoft’s Hyper-V technology to introduce new ways of enabling customer experiences. Windows Sandbox, Windows Defender Application Guard, System Guard and Advanced Threat Detection, Hyper-V Isolated-Containers, Windows Hypervisor Platform and Windows Subsystem for Linux 2 are all new Hyper-V components that ensure the security and flexibility customers should expect from Windows. The coordination of applications using Hyper-V, such as Kubernetes for Windows and Docker Desktop also represent Microsoft’s dedication to customer needs, which will continue to stand for our main sentiment going forward.

Virtualization-Based Security: Enabled by Default

brucesherwin — Wed, 02 Oct 2019 23:57:30 GMT

Virtualization-based Security (VBS) uses hardware virtualization features to create and isolate a secure region of memory from the normal operating system. Windows can use this "virtual secure mode" (VSM) to host a number of security solutions, providing them with greatly increased protection from vulnerabilities in the operating system, and preventing the use of malicious exploits which attempt to defeat operating systems protections.

The Microsoft hypervisor creates VSM and enforces restrictions which protect vital operating system resources, provides an isolated execution environment for privileged software and can protect secrets such as authenticated user credentials. With the increased protections offered by VBS, even if malware compromises the operating system kernel, the possible exploits can be greatly limited and contained because the hypervisor can prevent the malware from executing code or accessing secrets.

The Microsoft hypervisor has supported VSM since the earliest versions of Windows 10. However, until recently, Virtualization-based Security has been an optional feature that is most commonly enabled by enterprises. This was great, but the hypervisor development team was not satisfied. We believed that all devices running Windows should have Microsoft’s most advanced and most effective security features enabled by default. In addition to bringing significant security benefits to Windows, achieving default enablement status for the Microsoft hypervisor enables seamless integration of numerous other scenarios leveraging virtualization. Examples include WSL2, Windows Defender Application Guard, Windows Sandbox, Windows Hypervisor Platform support for 3rd party virtualization software, and much more.

With that goal in mind, we have been hard at work over the past several Windows releases optimizing every aspect of VSM. We knew that getting to the point where VBS could be enabled by default would require reducing the performance and power impact of running the Microsoft hypervisor on typical consumer-grade hardware like tablets, laptops and desktop PCs. We had to make the incremental cost of running the hypervisor as close to zero as possible and this was going to require close partnership with the Windows kernel team and our closest silicon partners – Intel, AMD, and ARM (Qualcomm).

Through software innovations like HyperClear and by making significant hypervisor and Windows kernel changes to avoid fragmenting large pages in the second-level address translation table, we were able to dramatically reduce the runtime performance and power impact of hypervisor memory management. We also heavily optimized hot hypervisor codepaths responsible for things like interrupt virtualization – taking advantage of hardware virtualization assists where we found that it was helpful to do so. Last but not least, we further reduced the performance and power impact of a key VSM feature called Hypervisor-Enforced Code Integrity (HVCI) by working with silicon partners to design completely new hardware features including Intel’s Mode-based execute control for EPT (MBEC), AMD’s Guest-mode execute trap for NPT (GMET), and ARM’s Translation table stage 2 Unprivileged Execute-never (TTS2UXN).

I’m proud to say that as of Windows 10 version 1903 9D, we have succeeded in enabling Virtualization-based Security by default on some capable hardware!

The Samsung Galaxy Book2 is officially the first Windows PC to have VBS enabled by default. This PC is built around the Qualcomm Snapdragon 850 processor, a 64-bit ARM processor. This is particularly exciting for the Microsoft hypervisor development team because it also marks the first time that enabling our hypervisor is officially supported on any ARM-based device.

Keep an eye on this blog for announcements regarding the default-enablement of VBS on additional hardware and in future versions of Windows 10.

VMware Workstation and Hyper-V – Working Together

Ben Armstrong — Tue, 27 Aug 2019 23:51:32 GMT

Yesterday VMware demonstrated a pre-release version of VMware Workstation with early support for the Windows Hypervisor Platform in the What's New in VMware Fusion and VMware Workstation session at VMworld.

In Windows 10 we have introduced many security features that utilize the Windows Hypervisor. Credential Guard, Windows Defender Application Guard, and Virtualization Based Security all utilize the Windows Hypervisor. At the same time, new Developer features like Windows Server Containers and the WSL 2 both utilize the Windows Hypervisor.

This has made it challenging for our customers who need to use VMware Workstation. Historically, it has not be possible to run VMware Workstation when Hyper-V was enabled.

In the future – users will be able to run all of these applications together. This means that users of VMware workstation will be able to take advantage of all the security enhancements and developer features that are available in Windows 10. Microsoft and VMware have been collaborating on this effort, and I am really excited to be a part of this moment!

Cheers,
Ben

5/14: Hyper-V HyperClear Update

brucesherwin — Tue, 14 May 2019 19:54:53 GMT

Four new speculative execution side channel vulnerabilities were announced today and affect a wide array of Intel processors. The list of affected processors includes Intel Xeon, Intel Core, and Intel Atom models. These vulnerabilities are referred to as CVE-2018-12126 Microarchitectural Store Buffer Data Sampling (MSBDS), CVE-2018-12130 Microarchitectural Fill Buffer Data Sampling (MFBDS), CVE-2018-12127 Microarchitectural Load Port Data Sampling (MLPDS), and CVE-2018-11091 Microarchitectural Data Sampling Uncacheable Memory (MDSUM). These vulnerabilities are like other Intel CPU vulnerabilities disclosed recently in that they can be leveraged for attacks across isolation boundaries. This includes intra-OS attacks as well as inter-VM attacks.

In a previous blog post, the Hyper-V hypervisor engineering team described our high-performing and comprehensive side channel vulnerability mitigation architecture, HyperClear. We originally designed HyperClear as a defense against the L1 Terminal Fault (a.k.a. Foreshadow) Intel side channel vulnerability. Fortunately for us and for our customers, HyperClear has proven to be an excellent foundation for mitigating this new set of side channel vulnerabilities. In fact, HyperClear required a relatively small set of updates to provide strong inter-VM and intra-OS protections for our customers. These updates have been deployed to Azure and are available in Windows Server 2016 and later supported releases of Windows and Windows Server. Just as before, the HyperClear mitigation allows for safe use of hyper-threading in a multi-tenant virtual machine hosting environment.

We have already shared the technical details of HyperClear and the set of required changes to mitigate this new set of hardware vulnerabilities with industry partners. However, we know that many of our customers are also interested to know how we’ve extended the Hyper-V HyperClear architecture to provide protections against these vulnerabilities.

As we described in the original HyperClear blog post, HyperClear relies on 3 main components to ensure strong inter-VM isolation:

Core Scheduler
Virtual-Processor Address Space Isolation
Sensitive Data Scrubbing

As we extended HyperClear to mitigate these new vulnerabilities, the fundamental components of the architecture remained constant. However, there were two primary hypervisor changes required:

Support for a new Intel processor feature called MbClear. Intel has been working to add support for MbClear by updating the CPU microcode for affected Intel hardware. The Hyper-V hypervisor uses this new feature to clear microarchitectural buffers when switching between virtual processors that belong to different virtual machines. This ensures that when a new virtual processor begins to execute, there is no data remaining in any microarchitectural buffers that belongs to a previously running virtual processor. Additionally, this new processor feature may be exposed to guest operating systems to implement intra-OS mitigations.
Always-enabled sensitive data scrubbing. This ensures that the hypervisor never leaves sensitive data in hypervisor-owned memory when it returns to guest kernel-mode or guest user-mode. This prevents the hypervisor from being used as a gadget by guest user-mode. Without always-enabled sensitive data scrubbing, the concern would be that guest user-mode can deliberately trigger hypervisor entry and that the CPU may speculatively fill a microarchitectural buffer with secrets remaining in memory from a previous hypervisor entry triggered by guest kernel-mode or a different guest user-mode application. Always-enabled sensitive data scrubbing fully mitigates this concern. As a bonus, this change improves performance on many Intel processors because it enables the Hyper-V hypervisor to more efficiently mitigate other previously disclosed Intel side channel speculation vulnerabilities.

Overall, the Hyper-V HyperClear architecture has proven to be a readily extensible design providing strong isolation boundaries against a variety of speculative execution side channel attacks with negligible impact on performance.

Hyper-V HyperClear Mitigation for L1 Terminal Fault

Virtualization-Team — Fri, 22 Mar 2019 00:17:45 GMT

First published on TECHNET on Aug 14, 2018

Introduction

A new speculative execution side channel vulnerability was announced recently that affects a range of Intel Core and Intel Xeon processors. This vulnerability, referred to as L1 Terminal Fault (L1TF) and assigned CVE 2018-3646 for hypervisors, can be used for a range of attacks across isolation boundaries, including intra-OS attacks from user-mode to kernel-mode as well as inter-VM attacks. Due to the nature of this vulnerability, creating a robust, inter-VM mitigation that doesn’t significantly degrade performance is particularly challenging.

For Hyper-V, we have developed a comprehensive mitigation to this attack that we call HyperClear. This mitigation is in-use by Microsoft Azure and is available in Windows Server 2016 and later. The HyperClear mitigation continues to allow for safe use of SMT (hyper-threading) with VMs and, based on our observations of deploying this mitigation in Microsoft Azure, HyperClear has shown to have relatively negligible performance impact.

We have already shared the details of HyperClear with industry partners. Since we have received questions as to how we are able to mitigate the L1TF vulnerability without compromising performance, we wanted to broadly share a technical overview of the HyperClear mitigation and how it mitigates L1TF speculative execution side channel attacks across VMs.

Overview of L1TF Impact to VM Isolation

As documented here , the fundamental premise of the L1TF vulnerability is that it allows a virtual machine running on a processor core to observe any data in the L1 data cache on that core.

Normally, the Hyper-V hypervisor isolates what data a virtual machine can access by leveraging the memory address translation capabilities provided by the processor. In the case of Intel processors, the Extended Page Tables (EPT) feature of Intel VT-x is used to restrict the system physical memory addresses that a virtual machine can access.

Under normal execution, the hypervisor leverages the EPT feature to restrict what physical memory can be accessed by a VM’s virtual processor while it is running. This also restricts what data the virtual processor can access in the cache, as the physical processor enforces that a virtual processor can only access data in the cache corresponding to system physical addresses made accessible via the virtual processor’s EPT configuration.

By successfully exploiting the L1TF vulnerability, the EPT configuration for a virtual processor can be bypassed during the speculative execution associated with this vulnerability. This means that a virtual processor in a VM can speculatively access anything in the L1 data cache, regardless of the memory protections configured by the processor’s EPT configuration.

Intel’s Hyper-Threading (HT) technology is a form of Simultaneous MultiThreading (SMT). With SMT, a core has multiple SMT threads (also known as logical processors), and these logical processors (LPs) can execute simultaneously on a core. SMT further complicates this vulnerability, as the L1 data cache is shared between sibling SMT threads of the same core. Thus, a virtual processor for a VM running on a SMT thread can speculatively access anything brought into the L1 data cache by its sibling SMT threads. This can make it inherently unsafe to run multiple isolation contexts on the same core. For example, if one logical processor of a SMT core is running a virtual processor from VM A and another logical processor of the core is running a virtual processor from VM B, sensitive data from VM B could be seen by VM A (and vice-versa).

Similarly, if one logical processor of a SMT core is running a virtual processor for a VM and the other logical processor of the SMT core is running in the hypervisor context, the guest VM could speculatively access sensitive data brought into the cache by the hypervisor.

Basic Inter-VM Mitigation

To mitigate the L1TF vulnerability in the context of inter-VM isolation, the most straightforward mitigation involves two key components:

Flush L1 Data Cache On Guest VM Entry – Every time the hypervisor switches a processor thread (logical processor) to execute in the context of a guest virtual processor, the hypervisor can first flush the L1 data cache. This ensures that no sensitive data from the hypervisor or previously running guest virtual processors remains in the cache. To enable the hypervisor to flush the L1 data cache, Intel has released updated microcode that provides an architectural facility for flushing the L1 data cache.

Disable SMT – Even with flushing the L1 data cache on guest VM entry, there is still the risk that a sibling SMT thread can bring sensitive data into the cache from a different security context. To mitigate this, SMT can be disabled, which ensures that only one thread ever executes on a processor core.

The L1TF mitigation for Hyper-V prior to Windows Server 2016 employs a mitigation based on these components. However, this basic mitigation has the major downside that SMT must be disabled, which can significantly reduce the overall performance of a system. Furthermore, this mitigation can result in a very high rate of L1 data cache flushes since the hypervisor may switch a thread between the guest and hypervisor contexts many thousands of times a second. These frequent cache flushes can also degrade the performance of the system.

HyperClear Inter-VM Mitigation

To address the downsides of the basic L1TF Inter-VM mitigation, we developed the HyperClear mitigation. The HyperClear mitigation relies on three key components to ensure strong Inter-VM isolation:

Core Scheduler

Virtual-Processor Address Space Isolation

Sensitive Data Scrubbing

Core Scheduler

The traditional Hyper-V scheduler operates at the level of individual SMT threads (logical processors). When making scheduling decisions, the Hyper-V scheduler would schedule a virtual processor onto a SMT thread, without regards to what the sibling SMT threads of the same core were doing. Thus, a single physical core could be running virtual processors from different VMs simultaneously.

Starting in Windows Server 2016, Hyper-V introduced a new scheduler implementation for SMT systems known as the " Core Scheduler ". When the Core Scheduler is enabled, Hyper-V schedules virtual cores onto physical cores. Thus, when a virtual core for a VM is scheduled, it gets exclusive use of a physical core, and a VM will never share a physical core with another VM.

With the Core Scheduler, a VM can safely take advantage of SMT (Hyper-Threading). When a VM is using SMT, the hypervisor scheduling allows the VM to use all the SMT threads of a core at the same time.

Thus, the Core Scheduler provides the essential protection that a VM’s data won’t be directly disclosed across sibling SMT threads. It protects against cross-thread data exposure of a VM since two different VMs never run simultaneously on different threads of the same core.

However, the Core Scheduler alone is not sufficient to protect against all forms of sensitive data leakage across SMT threads. There is still the risk that hypervisor data could be leaked across sibling SMT threads.

Virtual-Processor Address Space Isolation

SMT Threads on a core can independently enter and exit the hypervisor context based on their activity. For example, events like interrupts can cause a SMT thread to switch out of running the guest virtual processor context and begin executing the hypervisor context. This can happen independently for each SMT thread, so one SMT thread may be executing in the hypervisor context while its sibling SMT thread is still running a VM’s guest virtual processor context. An attacker running code in the less trusted guest VM virtual processor context on one SMT thread can then use the L1TF side channel vulnerability to potentially observe sensitive data from the hypervisor context running on the sibling SMT thread.

One potential mitigation to this problem is to coordinate hypervisor entry and exit across SMT threads of the same core. While this is effective in mitigating the information disclosure risk, this can significantly degrade performance.

Instead of coordinating hypervisor entry and exits across SMT threads, Hyper-V employs strong data isolation in the hypervisor to protect against a malicious guest VM leveraging the L1TF vulnerability to observe sensitive hypervisor data. The Hyper-V hypervisor achieves this isolation by maintaining separate virtual address spaces in the hypervisor for each guest SMT thread (virtual processor). When the hypervisor context is entered on a specific SMT thread, the only data that is addressable by the hypervisor is data associated with the guest virtual processor associated with that SMT thread. This is enforced through the hypervisor’s page table selectively mapping only the memory associated with the guest virtual processor. No data for any other guest virtual processor is addressable, and thus, the only data that can be brought into the L1 data cache by the hypervisor is data associated with that current guest virtual processor.

Thus, regardless of whether a given virtual processor is running in the guest VM virtual processor context or in the hypervisor context, the only data that can be brought into the cache is data associated with the active guest virtual processor. No additional privileged hypervisor secrets or data from other guest virtual processors can be brought into the L1 data cache.

This strong address space isolation provides two distinct benefits:

The hypervisor does not need to coordinate entry and exits into the hypervisor across sibling SMT threads. So, SMT threads can enter and exit the hypervisor context independently without any additional performance overhead.

The hypervisor does not need to flush the L1 data cache when entering the guest VP context from the hypervisor context. Since the only data that can be brought into the cache while executing in the hypervisor context is data associated with the guest virtual processor, there is no risk of privileged/private state in the cache that needs to be protected from the guest. Thus, with this strong address space isolation, the hypervisor only needs to flush the L1 data cache when switching between virtual cores on a physical core. This is much less frequent than the switches between the hypervisor and guest VP contexts.

Sensitive Data Scrubbing

There are cases where virtual processor address space isolation is insufficient to ensure isolation of sensitive data. Specifically, in the case of nested virtualization, a single virtual processor may itself run multiple guest virtual processors. Consider the case of a L1 guest VM running a nested hypervisor (L1 hypervisor). In this case, a virtual processor in this L1 guest may be used to run nested virtual processors for L2 VMs being managed by the L1 nested hypervisor.

In this case, the nested L1 guest hypervisor will be context switching between each of these nested L2 guests (VM A and VM B) and the nested L1 guest hypervisor. Thus, a virtual processor for the L1 VM being maintained by the L0 hypervisor can run multiple different security domains – a nested L1 hypervisor context and one or more L2 guest virtual machine contexts. Since the L0 hypervisor maintains a single address space for the L1 VM’s virtual processor, this address space could contain data for the nested L1 guest hypervisor and L2 guests VMs.

To ensure a strong isolation boundary between these different security domains, the L0 hypervisor relies on a technique we refer to as state scrubbing when nested virtualization is in-use. With state scrubbing, the L0 hypervisor will avoid caching any sensitive guest state in its data structures. If the L0 hypervisor must read guest data, like register contents, into its private memory to complete an operation, the L0 hypervisor will overwrite this memory with 0’s prior to exiting the L0 hypervisor context. This ensures that any sensitive L1 guest hypervisor or L2 guest virtual processor state is not resident in the cache when switching between security domains in the L1 guest VM.

For example, if the L1 guest hypervisor accesses an I/O port that is emulated by the L0 hypervisor, the L0 hypervisor context will become active. To properly emulate the I/O port access, the L0 hypervisor will have to read the current guest register contents for the L1 guest hypervisor context, and these register contents will be copied to internal L0 hypervisor memory. When the L0 hypervisor has completed emulation of the I/O port access, the L0 hypervisor will overwrite any L0 hypervisor memory that contains register contents for the L1 guest hypervisor context. After clearing out its internal memory, the L0 hypervisor will resume the L1 guest hypervisor context. This ensures that no sensitive data stays in the L0 hypervisor’s internal memory across invocations of the L0 hypervisor context. Thus, in the above example, there will not be any sensitive L1 guest hypervisor state in the L0 hypervisor’s private memory. This mitigates the risk that sensitive L1 guest hypervisor state will be brought into the data cache the next time the L0 hypervisor context becomes active.

As described above, this state scrubbing model does involve some extra processing when nested virtualization is in-use. To minimize this processing, the L0 hypervisor is very careful in tracking when it needs to scrub its memory, so it can do this with minimal overhead. The overhead of this extra processing is negligible in the nested virtualization scenarios we have measured.

Finally, the L0 hypervisor state scrubbing ensures that the L0 hypervisor can efficiently and safely provide nested virtualization to L1 guest virtual machines. However, to fully mitigate inter-VM attacks between L2 guest virtual machines, the nested L1 guest hypervisor must implement a mitigation for the L1TF vulnerability. This means the L1 guest hypervisor needs to appropriately manage the L1 data cache to ensure isolation of sensitive data across the L2 guest virtual machine security boundaries. The Hyper-V L0 hypervisor exposes the appropriate capabilities to L1 guest hypervisors to allow L1 guest hypervisors to perform L1 data cache flushes.

Conclusion

By using a combination of core scheduling, address space isolation, and data clearing, Hyper-V HyperClear is able to mitigate the L1TF speculative execution side channel attack across VMs with negligible performance impact and with full support of SMT.

Hyper-V symbols for debugging

Lars Iwer — Fri, 22 Mar 2019 00:16:10 GMT

First published on TECHNET on Apr 25, 2018
Having access to debugging symbols can be very handy, for example when you are

A partner building solutions leveraging Hyper-V,

Trying to debug a specific issue, or

Searching for bugs to participate in the Microsoft Hyper-V Bounty Program .

Starting with symbols for Windows Server 2016 with an installed April 2018 cumulative update, we are now providing access to most Hyper-V-related symbols through the public symbol servers. Here are some of the symbols that are available right now:


   

   SYMCHK: hvhostsvc.dll [10.0.14393.2007 ] PASSED  - PDB: hvhostsvc.pdb DBG:
   

   SYMCHK: passthruparser.sys [10.0.14393.2007 ] PASSED  - PDB: passthruparser.pdb DBG:
   

   SYMCHK: storvsp.sys          [10.0.14393.2312 ] PASSED  - PDB: storvsp.pdb DBG:
   

   SYMCHK: vhdmp.sys [10.0.14393.2097 ] PASSED  - PDB: vhdmp.pdb DBG:
   

   SYMCHK: vhdparser.sys [10.0.14393.2007 ] PASSED  - PDB: vhdparser.pdb DBG:
   

   SYMCHK: vid.dll [10.0.14393.2007 ] PASSED  - PDB: vid.pdb DBG:
   

   SYMCHK: Vid.sys [10.0.14393.2007 ] PASSED  - PDB: Vid.pdb DBG:
   

   SYMCHK: vmbuspipe.dll [10.0.14393.2007 ] PASSED  - PDB: vmbuspipe.pdb DBG:
   

   SYMCHK: vmbuspiper.dll [10.0.14393.2007 ] PASSED  - PDB: vmbuspiper.pdb DBG:
   

   SYMCHK: vmbusvdev.dll [10.0.14393.2007 ] PASSED  - PDB: vmbusvdev.pdb DBG:
   

   SYMCHK: vmchipset.dll [10.0.14393.2007 ] PASSED  - PDB: VmChipset.pdb DBG:
   

   SYMCHK: vmcompute.dll [10.0.14393.2214 ] PASSED  - PDB: vmcompute.pdb DBG:
   

   SYMCHK: vmcompute.exe [10.0.14393.2214 ] PASSED  - PDB: vmcompute.pdb DBG:
   

   SYMCHK: vmconnect.exe [10.0.14393.0    ] PASSED  - PDB: vmconnect.pdb DBG:
   

   SYMCHK: vmdebug.dll [10.0.14393.2097 ] PASSED  - PDB: vmdebug.pdb DBG:
   

   SYMCHK: vmdynmem.dll [10.0.14393.2007 ] PASSED  - PDB: vmdynmem.pdb DBG:
   

   SYMCHK: vmemulateddevices.dll [10.0.14393.2007 ] PASSED  - PDB: VmEmulatedDevices.pdb DBG:
   

   SYMCHK: VmEmulatedNic.dll [10.0.14393.2007 ] PASSED  - PDB: VmEmulatedNic.pdb DBG:
   

   SYMCHK: VmEmulatedStorage.dll [10.0.14393.2214 ] PASSED  - PDB: VmEmulatedStorage.pdb DBG:
   

   SYMCHK: vmicrdv.dll [10.0.14393.2007 ] PASSED  - PDB: vmicrdv.pdb DBG:
   

   SYMCHK: vmictimeprovider.dll [10.0.14393.2007 ] PASSED  - PDB: vmictimeprovider.pdb DBG:
   

   SYMCHK: vmicvdev.dll [10.0.14393.2214 ] PASSED  - PDB: vmicvdev.pdb DBG:
   

   SYMCHK: vmms.exe [10.0.14393.2214 ] PASSED  - PDB: vmms.pdb DBG:
   

   SYMCHK: vmrdvcore.dll [10.0.14393.2214 ] PASSED  - PDB: vmrdvcore.pdb DBG:
   

   SYMCHK: vmserial.dll [10.0.14393.2007 ] PASSED  - PDB: vmserial.pdb DBG:
   

   SYMCHK: vmsif.dll [10.0.14393.2214 ] PASSED  - PDB: vmsif.pdb DBG:
   

   SYMCHK: vmsifproxystub.dll [10.0.14393.82   ] PASSED  - PDB: vmsifproxystub.pdb DBG:
   

   SYMCHK: vmsmb.dll [10.0.14393.2007 ] PASSED  - PDB: vmsmb.pdb DBG:
   

   SYMCHK: vmsp.exe [10.0.14393.2214 ] PASSED  - PDB: vmsp.pdb DBG:
   

   SYMCHK: vmsynthfcvdev.dll [10.0.14393.2007 ] PASSED  - PDB: VmSynthFcVdev.pdb DBG:
   

   SYMCHK: VmSynthNic.dll [10.0.14393.2007 ] PASSED  - PDB: VmSynthNic.pdb DBG:
   

   SYMCHK: vmsynthstor.dll [10.0.14393.2007 ] PASSED  - PDB: VmSynthStor.pdb DBG:
   

   SYMCHK: vmtpm.dll [10.0.14393.2007 ] PASSED  - PDB: vmtpm.pdb DBG:
   

   SYMCHK: vmuidevices.dll [10.0.14393.2007 ] PASSED  - PDB: VmUiDevices.pdb DBG:
   

   SYMCHK: vmusrv.dll [10.0.14393.2007 ] PASSED  - PDB: vmusrv.pdb DBG:
   

   SYMCHK: vmwp.exe [10.0.14393.2214 ] PASSED  - PDB: vmwp.pdb DBG:
   

   SYMCHK: vmwpctrl.dll [10.0.14393.2007 ] PASSED  - PDB: vmwpctrl.pdb DBG:
   

   SYMCHK: vmprox.dll [10.0.14393.2007 ] PASSED  - PDB: vmprox.pdb DBG:
   

   SYMCHK: vpcivsp.sys [10.0.14393.2214 ] PASSED  - PDB: vpcivsp.pdb DBG:

There is a limited set of virtualization-related symbols that are currently not available: storvsp.pdb, hvax64.pdb, hvix64.pdb, and hvloader.pdb.

If you have a scenario where you need access to any of these symbols, please let us know in the comments below or through the Feedback Hub app. Please include some detail on the specific scenario which you are looking at. With newer releases, we are evaluating whether we can make even more symbols available.

Alles Gute,
Lars

[update 2018-04-26]: symbols for vid.sys, vid.dll, and vmprox.dll are now available as well.
[update 2018-10-24]: symbols for passthruparser.sys, storvsp.sys, and vhdparser.sys are now available.

Sneak Peek: Taking a Spin with Enhanced Linux VMs

Virtualization-Team — Fri, 22 Mar 2019 00:16:03 GMT

First published on TECHNET on Feb 28, 2018
**Update: This feature is now generally available. Please see our latest blog post to learn more**

Whether you're a developer or an IT admin, virtual machines are familiar tools that allow users to run entirely separate operating system instances on a host. And despite being a separate OS, we feel there's a great importance in having a VM experience that feels tightly integrated with the host. We invested in making the Windows client VM experience first-class, and users really liked it. Our users asked us to go further: they wanted that same first-class experience on Linux VMs as well.

As we thought about how we could deliver a better-quality experience--one that achieved closer parity with Windows clients--we found an opportunity to collaborate with the open source folks at XRDP , who have implemented Microsoft’s RDP protocol on Linux.

We’re partnering with Canonical on the upcoming Ubuntu 18.04 release to make this experience a reality, and we’re working to provide a solution that works out of the box. Hyper-V’s Quick Create VM gallery is the perfect vehicle to deliver such an experience. With only 3 mouse clicks, users will be able to get an Ubuntu VM running that offers clipboard functionality, drive redirection, and much more.

But you don’t have to wait until the release of Ubuntu 18.04 to try out the improved Linux VM experience. Read on to learn how you can get a sneak peek!

Disclaimer: This feature is under development. This tutorial outlines steps to have an enhanced Ubuntu experience in 16.04. Our TARGET experience will be with 18.04. There may be some bugs you discover in 16.04--and that's okay! We want to gather this data so we can make the 18.04 experience great.

A Call for Testing

We've chosen Canonical's next LTS release, Bionic Beaver, to be the focal point of our investments. In the lead up to the official release of 18.04, we'd like to begin getting feedback on how satisfied users are with the general experience. The experience we’re working towards in Ubuntu 18.04 can be set up in Ubuntu 16.04 (with a few extra steps). We will walk through how to set up an Ubuntu 16.04 VM running in Hyper-V with Enhanced Session Mode.

In the future, you can expect to be able to find an Ubuntu 18.04 image sitting in the Hyper-V Quick Create galley 😊

NOTE: In order to participate in this tutorial, you need to be on Insider Builds, running at minimum Insider Build No. 17063

Tutorial

Grab the Ubuntu 16.04 ISO from Canonical's website, found at releases.ubuntu.com . Provision the VM as you normally would and step through the installation process. We created a set of scripts to perform all the heavy lifting to set up your environment appropriately. Once your VM is fully operational, we'll be executing the following commands inside of it.


   #Get the scripts from GitHub
   

   $ sudo apt-get update
   

   $ sudo apt install git
   

   $ git clone
   
    https://github.com/Microsoft/linux-vm-tools.git
   
   ~/linux-vm-tools
   

   $ cd ~/linux-vm-tools/ubuntu/16.04/


   #Make the scripts executable and run them...
   

   $ sudo chmod +x install.sh
   

   $ sudo chmod +x config-user.sh
   

   $ sudo ./install.sh

Install.sh will need to be run twice in order for the script to execute fully (it must perform a reboot mid-script) . That is, once your VM reboots, you'll need to change dir into the location of the script and run again. Once you've finished running the install.sh script, you'll need to run config-user.sh


   $ sudo ./config-user.sh

After you've run your scripts, shut down your VM. On your host machine in a powershell prompt, execute this command:


   Set-VM -VMName <your_vm_name>  -EnhancedSessionTransportType HvSocket

Now, when you boot your VM, you will be greeted with an option to connect and adjust your display size. This will be an indication that you're running in an enhanced session mode. Click "connect" and you're complete.

What are the Benefits?

These are the features that you get with the new enhanced session mode:

Better mouse experience

Integrated clipboard

Window Resizing

Drive Redirection

We encourage you to log any issues you discover to GitHub . This will also give you an idea of already identified issues.

How does this work?

The technology behind this mode is actually the same as how we achieve an enhanced session mode in Windows. It relies on the RDP protocol , implemented on Linux by the open source folks at XRDP, over Hyper-V sockets to light up all the great features that give the VM an integrated feel. Hyper-V sockets, or hv_sock, supply a byte-stream based communication mechanism between the host partition and the guest VM. Think of it as similar to TCP, except it's going over an optimized transport layer called VMBus. We contributed changes which would allow XRDP to utilize hv_sock.

The scripts we executed did the following:

Installs the "Linux-azure" kernel to the VM. This carries the hv_sock bits that we need.

Downloads the XRDP source code and compiles it with the hv_sock feature turned on (the published XRDP package in 16.04 doesn't have this set, so we must compile from source).

Builds and installs xorgxrdp.

Configures the user session for RDP

Launches the XRDP service

As we mentioned earlier, the steps described above are for Ubuntu 16.04, which will look a little different from 18.04. In fact, with Ubuntu 18.04 shipping with the 4.15 linux kernel (which already carries the hv_sock bits), we won’t need to apply the linux-azure kernel. The version of XRDP that ships as available in 18.04 is already compiled with hv_sock feature turned on, so there’s no more need to build xrdp/xorgxrdp—a simple “apt install” will bring in all the feature goodness!

If you’re not flighting insider builds, you can look forward to having this enhanced VM experience via the VM gallery when Ubuntu 18.04 is released at the end of April. Leave a comment below on your experience or tweet me with your thoughts!

**Update: This feature is now generally available. Please see our latest blog post to learn more**

Cheers,

Craig Wilhite ( @CraigWilhite )

Looking at the Hyper-V Event Log (January 2018 edition)

Lars Iwer — Fri, 22 Mar 2019 00:15:09 GMT

First published on TECHNET on Jan 23, 2018
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 CategoryDescription

Hyper-V-Compute	Events from the Host Compute Service (HCS) are collected here. The HCS is a low-level management API.
Hyper-V-Config	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.
Hyper-V-Guest-Drivers	Look at this section if you are experiencing issues with VM integration components.
Hyper-V-High-Availability	Hyper-V clustering-related events are collected in this section.
Hyper-V-Hypervisor	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.
Hyper-V-StorageVSP	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.
Hyper-V-VID	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.
Hyper-V-VMMS	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.
Hyper-V-VmSwitch	These channels contain events from the virtual network switches.
Hyper-V-Worker	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.
Hyper-V-Shared-VHDX	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.
Hyper-V-VMSP	The VM security process (VMSP) is used to provide secured virtual devices like the virtual TPM module to the VM.
Hyper-V-VfpExt	Events form the Virtual Filtering Platform (VFP) which is part of the Software Defined Networking Stack.
VHDMP	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 .

Alles Gute,

Lars

Migrating local VM owner certificates for VMs with vTPM

Lars Iwer — Fri, 22 Mar 2019 00:14:31 GMT

First published on TECHNET on Dec 14, 2017
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.

What's new in Hyper-V for Windows 10 Fall Creators Update?

scooley — Fri, 22 Mar 2019 00:13:48 GMT

First published on TECHNET on Nov 13, 2017
Windows 10 Fall Creators Update has arrived! While we’ve been blogging about new features as they appear in Windows Insider builds, many of you have asked for a consolidated list of Hyper-V updates and improvements since Creators Update in April.

Summary:

Quick Create includes a gallery (and you can add your own images)

Hyper-V has a Default Switch for easy networking

It’s easy to revert virtual machines to their start state

Host battery state is visible in virtual machines

Virtual machines are easier to share

Quick Create virtual machine gallery

The virtual machine gallery in Quick Create makes it easy to find virtual machine images in one convenient location.

You can also add your own virtual machine images to the Quick Create gallery. Building a custom gallery takes some time but, once built, makes creating virtual machines easy and consistent.

This blog post walks through adding custom images to the gallery.

For images that aren’t in the gallery, select “Local Installation Source” to create a virtual machine from an .iso or vhd located somewhere in your file system.

Keep in mind, while Quick Create and the virtual machine gallery are convenient, they are not a replacement for the New Virtual Machine wizard in Hyper-V manager. For more complicated virtual machine configuration, use that.

Default Switch

The switch named “Default Switch” allows virtual machines to share the host’s network connection using NAT (Network Address Translation). This switch has a few unique attributes:

Virtual machines connected to it will have access to the host’s network whether you’re connected to WIFI, a dock, or Ethernet. It will also work when the host is using VPN
or proxy.

It’s available as soon as you enable Hyper-V – you won’t lose internet setting it up.

You can’t delete or rename it.

It has the same name and device ID on all Windows 10 Fall Creator’s Update Hyper-V hosts.
Name: Default Switch
ID: c08cb7b8-9b3c-408e-8e30-5e16a3aeb444

Yes, the default switch does automatically assign an IP to the virtual machine (DNS and DHCP).

I’m really excited to have a always-available network connection for virtual machines on Hyper-V. The Default Switch offers the best networking experience for virtual machines on a laptop. If you need highly customized networking, however, continue using Virtual Switch Manager.

Revert! (automatic checkpoints)

This is my personal favorite feature from Fall Creators Update.

For a little bit of background, I mostly use virtual machines to build/run demos and to sandbox simple experiments. At least once a month, I accidently mess up my virtual machine. Sometimes I remember to make a checkpoint and I can roll back to a good state. Most of the time I don’t. Before automatic checkpoints, I’d have to choose between rebuilding my virtual machine or manually undoing my mistake.

Starting in Fall Creators Update, Hyper-V creates a checkpoint when you start virtual machines. Say you’re learning about Linux and accidently `rm –rf /*` or update your guest and discover a breaking change, now you can simply revert back to when the virtual machine started.

Automatic checkpoints are enabled by default on Windows 10 and disabled by default on Windows Server. They are not useful for everyone. For people with automation or for those of you worried about the overhead of making a checkpoint, you can disable automatic checkpoints with PowerShell (Set-VM –Name VMwithAutomation –AutomaticCheckpointsEnabled) or in VM settings under “Checkpoints”.

Here’s a link to the original announcement with more information.

Battery pass-through

Virtual machines in Fall Creators Update are aware of the hosts battery state.

This is nice for a few reasons:

You can see how much battery life you have left in a full-screen virtual machine.

The guest operating system knows the battery state and can optimize for low power situations.

Easier virtual machine sharing

Sharing your Hyper-V virtual machines is easier with the new “Share” button. Share packages and compresses your virtual machine so you can move it to another Hyper-V host right from Virtual Machine Connection.

Share creates a “.vmcz” file with your virtual hard drive (vhd/vhdx) and any state the virtual machine will need to run. “Share” will not include checkpoints. If you would like to also export your checkpoints, you can use the “Export” tool, or the “Export-VM” PowerShell cmdlet.

Once you’ve moved your virtual machine to another computer with Hyper-V, double click the “.vmcz” file and the virtual machine will import automatically.

----

That’s the list! As always, please send us feedback via FeedbackHub.

Curious what we’re building next? Become a Windows Insider – almost everything here has benefited from your early feedback.

Cheers,
Sarah

Create your custom Quick Create VM gallery

Lars Iwer — Fri, 22 Mar 2019 00:12:27 GMT

First published on TECHNET on Nov 08, 2017
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


   logo


   symbol

, and


   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


   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization

.
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!

Lars

Update: The official documentation is now live as well -- for more detail on the gallery functionality and how to create your own gallery: This way please: Create a custom virtual machine gallery

A great way to collect logs for troubleshooting

Lars Iwer — Fri, 22 Mar 2019 00:12:12 GMT

First published on TECHNET on Oct 27, 2017
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.

Cheers,
Lars

Copying Files into a Hyper-V VM with Vagrant

Virtualization-Team — Fri, 22 Mar 2019 00:11:28 GMT

First published on TECHNET on Jul 18, 2017

A couple of weeks ago, I published a blog with tips and tricks for getting started with Vagrant on Hyper-V. My fifth tip was to "Enable Nifty Hyper-V Features," where I briefly mentioned stuff like differencing disks and virtualization extensions.

While those are useful, I realized later that I should have added one more feature to my list of examples: the "guest_service_interface" field in "vm_integration_services." It's hard to know what that means just from the name, so I usually call it the "the thing that lets me copy files into a VM."

Disclaimer: this is not a replacement for Vagrant's synced folders . Those are super convienent, and should really be your default solution for sharing files. This method is more useful in one-off situations.

Enabling Copy-VMFile

Enabling this functionality requires a simple change to your Vagrantfile. You need to set "guest_service_interface" to true within "vm_integration_services" configuration hash. Here's what my Vagrantfile looks like for CentOS 7:

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|
config.vm.box = "centos/7"
config.vm.provider "hyperv"
config.vm.network "public_network"
config.vm.synced_folder ".", "/vagrant", disabled: true
config.vm.provider "hyperv" do |h|
h.enable_virtualization_extensions = true
h.differencing_disk = true
h.vm_integration_services = {
guest_service_interface: true #<---------- this line enables Copy-VMFile
}
end
end

You can check that it's enabled by running


    Get-VMIntegrationService

in PowerShell on the host machine:


    PS C:\vagrant_selfhost\centos>  Get-VMIntegrationService -VMName "centos-7-1-1.x86_64"
    

    

    VMName              Name                    Enabled PrimaryStatusDescription SecondaryStatusDescription
    

    ------              ----                    ------- ------------------------ --------------------------
    

    centos-7-1-1.x86_64 Guest Service Interface True    OK
    

    centos-7-1-1.x86_64 Heartbeat               True    OK
    

    centos-7-1-1.x86_64 Key-Value Pair Exchange True    OK                       The protocol version of...
    

    centos-7-1-1.x86_64 Shutdown                True    OK
    

    centos-7-1-1.x86_64 Time Synchronization    True    OK                       The protocol version of...
    

    centos-7-1-1.x86_64 VSS                     True    OK                       The protocol version of...

Note : not all integration services work on all guest operating systems. For example, this functionality will not work on the "Precise" Ubuntu image that's used in Vagrant's "Getting Started" guide. The full compatibility list various Windows and Linux distrobutions can be found here . Just click on your chosen distrobution and check for "File copy from host to guest."

Using Copy-VMFile

Once you've got a VM set up correctly, copying files to and from arbitrary locations is as simple as running


    Copy-VMFile

in PowerShell.

Here's a sample test I used to verify it was working on my CentOS VM:


    Copy-VMFile -Name 'centos-7-1-1.x86_64' -SourcePath '.\Foo.txt' -DestinationPath '/tmp' -FileSource Host

Full details can found in the official documentation . Unfortunately, you can't yet use it to copy files from your VM to your host. If you're running a Windows Guest, you can use


    Copy-Item

with PowerShell Direct to make that work; see this document for more details.

How Does It Work?

The way this works is by running Hyper-V integration services within the guest operating system. Full details can be found in the official documentation . The short version is that integration services are Windows Services (on Windows) or Daemons (on Linux) that allow the guest operating system to communicate with the host. In this particular instance, the integration service allows us to copy files to the VM over the VM Bus (no network required!).

Conclusion

Hope you find this helpful -- let me know if there's anything you think I missed.

John Slack
Program Manager
Hyper-V Team

Hyper-V virtual machine gallery and networking improvements

scooley — Fri, 22 Mar 2019 00:11:22 GMT

First published on TECHNET on Jul 26, 2017
In January, we added Quick Create to Hyper-V manager in Windows 10. Quick Create is a single-page wizard for fast, easy, virtual machine creation.

Starting in the latest fast-track Windows Insider builds (16237+) we’re expanding on that idea in two ways. Quick Create now includes:

A virtual machine gallery with downloadable, pre-configured, virtual machines.

A default virtual switch to allow virtual machines to share the host’s internet connection using NAT.

To launch Quick Create, open Hyper-V Manager and click on the “Quick Create…” button (1).

From there you can either create a virtual machine from one of the pre-built images available from Microsoft (2) or use a local installation source. Once you’ve selected an image or chosen installation media, you’re done! The virtual machine comes with a default name and a pre-made network connection using NAT (3) which can be modified in the “more options” menu.

Click “Create Virtual Machine” and you’re ready to go – granted downloading the virtual machine will take awhile.

Details about the Default Switch

The switch named “Default Switch” or “Layered_ICS”, allows virtual machines to share the host’s network connection. Without getting too deep into networking (saving that for a different post), this switch has a few unique attributes compared to other Hyper-V switches:

Virtual machines connected to it will have access to the host’s network whether you’re connected to WIFI, a dock, or Ethernet.

It’s available as soon as you enable Hyper-V – you won’t lose internet setting it up.

You can’t delete it.

It has the same name and device ID (GUID c08cb7b8-9b3c-408e-8e30-5e16a3aeb444) on all Windows 10 hosts so virtual machines on recent builds can assume the same switch is present on all Windows 10 Hyper-V host.

I’m really excited by the work we are doing in this area. These improvements make Hyper-V a better tool for people running virtual machines on a laptop. They don’t, however, replace existing Hyper-V tools. If you need to define specific virtual machine settings, New-VM or the new virtual machine wizard are the right tools. For people with custom networks or complicated virtual network needs, continue using Virtual Switch Manager.

Also keep in mind that all of this is a work in progress. There are rough edges for the default switch right now and there aren't many images in the gallery. Please give us feedback! Your feedback helps us. Let us know what images you would like to see and share issues by commenting on this blog or submitting feedback through Feedback Hub.

Cheers,
Sarah

Vagrant and Hyper-V -- Tips and Tricks

Virtualization-Team — Fri, 22 Mar 2019 00:11:01 GMT

First published on TECHNET on Jul 06, 2017

Learning to Use Vagrant on Windows 10

A few months ago, I went to DockerCon as a Microsoft representative. While I was there, I had the chance to ask developers about their favorite tools.

The most common tool mentioned (outside of Docker itself) was Vagrant . This was interesting -- I was familiar with Vagrant, but I'd never actually used it. I decided that needed to change. Over the past week or two, I took some time to try it out. I got everything working eventually, but I definitely ran into some issues on the way.

My pain is your gain -- here are my tips and tricks for getting started with Vagrant on Windows 10 and Hyper-V.

NOTE: This is a supplement for Vagrant's " Getting Started " guide, not a replacement.

Tip 0: Install Hyper-V

For those new to Hyper-V, make sure you've got Hyper-V running on your machine. Our official docs list the exact steps and requirements.

Tip 1: Set Up Networking Correctly

Vagrant doesn't know how to set up networking on Hyper-V right now (unlike other providers), so it's up to you to get things working the way you like them.

There are a few NAT networks already created on Windows 10 (depending on your specific build). Layered_ICS should work (but is under active development), while Layered_NAT doesn't have DHCP . If you're a Windows Insider, you can try Layered_ICS. If that doesn't work, the safest option is to create an external switch via Hyper-V Manager. This is the approach I took. If you go this route, a friendly reminder that the external switch is tied to a specific network adapter. So if you make it for WiFi, it won't work when you hook up the Ethernet, and vice versa.

[caption id="attachment_10175" align="aligncenter" width="879"] Instructions for adding an external switch in Hyper-V manager[/caption]

Tip 2: Use the Hyper-V Provider

Unfortunately, the Getting Started guide uses VirtualBox, and you can't run other virtualization solutions alongside Hyper-V. You need to change the " provider " Vagrant uses at a few different points.

When you install your first box, add --provider :


    vagrant box add hashicorp/precise64 --provider hyperv

And when you boot your first Vagrant environment, again, add --provider. Note: you might run into the error mentioned in Trick 4, so skip to there if you see something like "mount error(112): Host is down".


    vagrant up --provider hyperv

Tip 3: Add the basics to your Vagrantfile

Adding the provider flag is a pain to do every single time you run


    vagrant up

. Fortunately, you can set up your Vagrantfile to automate things for you. After running


    vagrant init

, modify your vagrant file with the following:

Vagrant.configure(2) do |config|
config.vm.box = "hashicorp/precise64"
config.vm.provider "hyperv"
config.vm.network "public_network"
end

One additional trick here:


    vagrant init

will create a file that will appear to be full of commented out items. However, there is one line not commented out:

[caption id="attachment_10185" align="aligncenter" width="879"] There is one line not commented.[/caption]

Make sure you delete that line! Otherwise, you'll end up with an error like this:


    Bringing machine 'default' up with 'hyperv' provider...
    

    ==> default: Verifying Hyper-V is enabled...
    

    ==> default: Box 'base' could not be found. Attempting to find and install...
    

    default: Box Provider: hyperv
    

    default: Box Version: >= 0
    

    ==> default: Box file was not detected as metadata. Adding it directly...
    

    ==> default: Adding box 'base' (v0) for provider: hyperv
    

    default: Downloading: base
    

    default:
    

    An error occurred while downloading the remote file. The error
    

    message, if any, is reproduced below. Please fix this error and try
    

    again.

Trick 4: Shared folders uses SMBv1 for hashicorp/precise64

For the image used in the "Getting Started" guide (hashicorp/precise64), Vagrant tries to use SMBv1 for shared folders. However, if you're like me and have SMBv1 disabled , this will fail:


    Failed to mount folders in Linux guest. This is usually because
    

    the "vboxsf" file system is not available. Please verify that
    

    the guest additions are properly installed in the guest and
    

    can work properly. The command attempted was:
    

    

    mount -t cifs -o uid=1000,gid=1000,sec=ntlm,credentials=/etc/smb_creds_e70609f244a9ad09df0e760d1859e431 //10.124.157.30/e70609f244a9ad09df0e760d1859e431 /vagrant
    

    

    The error output from the last command was:
    

    

    mount error(112): Host is down
    

    Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

You can check if SMBv1 is enabled with this PowerShell Cmdlet:


    Get-SmbServerConfiguration

If you can live without synced folders, here's the line to add to the vagrantfile to disable the default synced folder.

config.vm.synced_folder ".", "/vagrant", disabled: true

If you can't, you can try installing cifs-utils in the VM and re-provision. You could also try another synced folder method . For example, rsync works with Cygwin or MinGW. Disclaimer: I personally didn't try either of these methods.

Tip 5: Enable Nifty Hyper-V Features

Hyper-V has some useful features that improve the Vagrant experience. For example, a pretty substantial portion of the time spent running


    vagrant up

is spent cloning the virtual hard drive. A faster way is to use differencing disks with Hyper-V. You can also turn on virtualization extensions, which allow nested virtualization within the VM (i.e. Docker with Hyper-V containers). Here are the lines to add to your Vagrantfile to add these features:

config.vm.provider "hyperv" do |h|
h.enable_virtualization_extensions = true
h.differencing_disk = true
end

There are a many more customization options that can be added here (i.e. VMName, CPU/Memory settings, integration services). You can find the details in the Hyper-V provider documentation .

Tip 6: Filter for Hyper-V compatible boxes on Vagrant Cloud

You can find more boxes to use in the Vagrant Cloud (formally called Atlas). They let you filter by provider, so it's easy to find all of the Hyper-V compatible boxes .

Tip 7: Default to the Hyper-V Provider

While adding the default provider to your Vagrantfile is useful, it means you need to remember to do it with each new Vagrantfile you create. If you don't, Vagrant will trying to download VirtualBox when you


    vagrant up

the first time for your new box. Again, VirtualBox doesn't work alongside Hyper-V, so this is a problem.


    PS C:\vagrant> vagrant up
    

    ==>  Provider 'virtualbox' not found. We'll automatically install it now...
    

    The installation process will start below. Human interaction may be
    

    required at some points. If you're uncomfortable with automatically
    

    installing this provider, you can safely Ctrl-C this process and install
    

    it manually.
    

    ==>  Downloading VirtualBox 5.0.10...
    

    This may not be the latest version of VirtualBox, but it is a version
    

    that is known to work well. Over time, we'll update the version that
    

    is installed.

You can set your default provider on a user level by using the VAGRANT_DEFAULT_PROVIDER environmental variable. For more options (and details), this is the relevant page of Vagrant's documentation.

Here's how I set the user-level environment variable in PowerShell:


    [Environment]::SetEnvironmentVariable("VAGRANT_DEFAULT_PROVIDER", "hyperv", "User")

Again, you can also set the default provider in the Vagrant file (see Trick 3), which will prevent this issue on a per project basis. You can also just add


    --provider hyperv

when running


    vagrant up

. The choice is yours.

Wrapping Up

Those are my tips and tricks for getting started with Vagrant on Hyper-V. If there are any you think I missed, or anything you think I got wrong, let me know in the comments.

Here's the complete version of my simple starting Vagrantfile:

# -*- mode: ruby -*-
# vi: set ft=ruby :

# All Vagrant configuration is done below. The "2" in Vagrant.configure
# configures the configuration version (we support older styles for
# backwards compatibility). Please don't change it unless you know what
# you're doing.
Vagrant.configure("2") do |config|
config.vm.box = "hashicorp/precise64"
config.vm.provider "hyperv"
config.vm.network "public_network"
config.vm.synced_folder ".", "/vagrant", disabled: true
config.vm.provider "hyperv" do |h|
h.enable_virtualization_extensions = true
h.differencing_disk = true
end
end

Making it easier to revert

Virtualization-Team — Fri, 22 Mar 2019 00:10:29 GMT

First published on TECHNET on Apr 20, 2017
Sometimes when things go wrong in my environment, I don't want to have to clean it all up -- I just want to go back in time to when everything was working. But remembering to maintain good recovery points isn't easy.

Now we're making it so that you can always roll back your virtual machine to a recent good state if you need to. Starting in the latest Windows Insider build, you can now always revert a virtual machine back to the state it started in.

In Virtual Machine Connection, just click the Revert button to undo any changes made inside the virtual machine since it last started.

Under the hood, we're using checkpoints; when you start a virtual machine that doesn't have any checkpoints, we create one for you so that you can easily roll back to it if something goes wrong, then we clean it up once the virtual machine shuts down cleanly.

New virtual machines will be created with "Use automatic checkpoints" enabled by default, but you will have to enable it yourself to use it for existing VMs. The option is off by default on Windows Server. This option can be found in Settings -> Checkpoints -> "Use automatic checkpoints"

Note: the checkpoint will only be taken automatically when the VM starts if it doesn't have other existing checkpoints.

Hopefully this will come in handy next time you need to undo something in your VM. If you are in the Windows Insider Program, please give it a try and let us know what you think.

Cheers,
Andy

What's new in Hyper-V for the Windows 10 Creators Update?

scooley — Fri, 22 Mar 2019 00:09:58 GMT

First published on TECHNET on Apr 13, 2017
Microsoft just released the Windows 10 Creators Update . Which means Hyper-V improvements!

New and improved features in Creators Update:

Quick Create

Checkpoint and Save for nested Hyper-V

Dynamic resize for VM Connect

Zoom for VM Connect

Networking improvements (NAT)

Developer-centric memory management

Keep reading for more details. Also, if you want to try new Hyper-V things as we build them, become a Windows Insider .
Faster VM creation with Quick Create

Hyper-V Manager has a new option for quickly and easily creating virtual machines, aptly named “Quick Create”. Introduced in build 15002 , Quick Create focuses on getting the guest operating system up and running as quickly as possible -- including creating and connecting to a virtual switch.

When we first released Quick Create, there were a number of issues mostly centered on our default virtual machine settings ( read more ). In response to your feedback, we have updated the Quick Create defaults.

Creators Update Quick Create defaults:

Generation: 2

Memory: 2048 MB to start, Dynamic Memory enabled

Virtual Processors: 4

VHD: dynamic resize up to 100GB

Checkpoint and save work on nested Hyper-V host
Last year we added the ability to run Hyper-V inside of Hyper-V (a.k.a. nested virtualization). This has been a very popular feature, but it initially came with a number of limitations. We have continued to work on the performance, compatibility and feature integration of nested virtualization.

In the Creator update for Windows 10 you can now take checkpoints and saved states on virtual machines that are acting as nested Hyper-V hosts.
Dynamic resize for Enhanced Session Mode VMs

The picture says it all. If you are using Hyper-V’s Enhanced Session Mode, you can dynamically resize your virtual machine. Right now, this is only available to virtual machines that support Hyper-V’s Enhanced Session mode. That includes:

Windows Client: Windows 8.1, Windows 10 and later

Windows Server: Windows Server 2012 R2, Windows Server 2016 and later

Read blog announcement.
Zoom for VM Connect
Is your virtual machine impossible to read? Alternately, do you suffer from scaling issues in legacy applications?

VMConnect now has the option to adjust Zoom Level under the View Menu.

Multiple NAT networks and IP pinning
NAT networking is vital to both Docker and Visual Studio’s UWP device emulators. When we released Windows Containers, developers discovered number of networking differences between containers on Linux and containers on Windows. Additionally, introducing another common developer tool that uses NAT networking presented new challenges for our networking stack.

In the Creators Update, there are two significant improvements to NAT:

Developers can now use for multiple NAT networks (internal prefixes) on a single host.
That means VMs, containers, emulators, et. al. can all take advantage of NAT functionality from a single host.

Developers are also able to build and test their applications with industry-standard tooling directly from the container host using an overlay network driver (provided by the Virtual Filtering Platform (VFP) Hyper-V switch extension) as well as having direct access to the container using the Host IP and exposed port.

Improved memory management
Until recently, Hyper-V has allocated memory very conservatively. While that is the right behavior for Windows Server, UWP developers faced out of memory errors starting device emulators from Visual Studio ( read more ).

In the Creators Update, Hyper-V gives the operating system a chance to trim memory from other applications and uses all available memory. You may still run out of memory, but now the amount of memory shown in task manager accurately reflects the amount available for starting virtual machines.

Introduced in build 15002 .

As always, please send us feedback!

Once more, because I can’t emphasize this enough, become a Windows Insider – almost everything here has benefited from your early feedback.

Cheers,
Sarah