Feature Overview

RHEL has now enabled Microsoft WSL2 as a platform for running RHEL instances from a Windows OS.  Today, WSL instances are being tagged as Hyper-V VMs in virt-what, and do not properly detect that they are running as WSL2 a layer below the hypervisor.  Our internal analytic and business insights tools (grokket) use virt-what information for internal reporting of VM Type, and we are missing WSL data from our internal insights as a result.

Goals

Be able to properly distinguish WSL2 RHEL instances from Hyper-V virtual machines to enable the RHEL BU to track growth in our RHEL Developers Pod/Initiatives.

Requirements

Properly detect Hyper-V instances that are actually running as WSL2 workloads within a Windows system.  This can be distinguished by detecting the kernel through a uname command and identifying "microsoft-standard-wsl2" vs. the specific RHEL kernel build as WSL.

(Optional) Use Cases

< How will the user interact with this feature? >

< Which users will use this and when will they use it? >

< Is this feature used as part of current user interface? >

Out of Scope

Background, and strategic fit

This feature will allow us to properly identify trends and growth of the RHEL Developer business when the end users are disadvantaged by being forced to use corporate Windows standard builds for their development/work environments.

Assumptions

< Are there assumptions being made regarding prerequisites and dependencies?>

< Are there assumptions about hardware, software or people resources?>

Customer Considerations

< Are there specific customer environments that need to be considered (such as working with existing h/w and software)?>

<Are there Upgrade considerations that customers need to account for, or that the Feature should address on behalf of the customer?>

<Does the Feature introduce data that could be gathered and used for Insights purposes?>

Documentation Considerations

< What educational or reference material (docs) is required to support this product feature? For users/admins? Other functions (security officers, etc)? >

<What does success look like?>

< Does this feature have doc impact?  Possible values are: New Content, Updates to existing content,  Release Note, or No Doc Impact>

 <If unsure and no Technical Writer is available, please contact Content Strategy. If yes, complete the following.>

• <What concepts do customers need to understand to be successful in [action]?>
• <How do we expect customers will use the feature? For what purpose(s)?>
• <What reference material might a customer want/need to complete [action]?>
• <Is there source material that can be used as reference for the Technical Writer in writing the content? If yes, please link if available. >
• <What is the doc impact (New Content, Updates to existing content, or Release Note)?>

Interoperability Considerations

< Which other products and versions in our portfolio does this feature impact? >

<If other products will be impacted set the ‘LP_Interop’ label on the Feature>

< What interoperability test scenarios should be factored by the layered product(s)? >

Questions