Addie's place on the web...

Step one on the road to using Dev Containers is to get a Linux system running on my Windows laptop. In my setup, the Linux system will be used to run the Dev Containers. But since it is a full-fledged Linux system, I can use it for anything that I want of course.

Let’s get going and start to install a Linux system on top of a Windows laptop.

The laptop

I started to experiment with a Windows 10 laptop, but recently switched to a new computer running Windows 11. Just to make sure you know what I am playing with when writing this document:

• The Windows 10 laptop is a 5-year-old HP ZBook studio G5 with an Intel Core i7-8850H (@ 2.60 GHz) and 16 GB of RAM. I run Windows 10 Enterprise 22H2 (OS build 19045.3570) on that computer.
• The Windows 11 laptop is a brand-new HP ZBook Fury 16 G10 with an Intel Core i7-13850HX (@ 2.10 GHz) and 32 GB of RAM. On this computer I use Windows 11 Enterprise 22H2 (OS build 22621.2428).

Everything documented here works fine on both computers.

Run Linux on a Windows laptop

Running a Linux VM on a Windows laptop requires Windows Subsystem for Linux (WSL). A few years ago, Microsoft updated WSL to version 2 which has many improvements over the initial releases. They provide good documentation showing how to get started with and using WSL. It becomes clear that Microsoft and Canonical have teamed up to get Linux going on Windows. All the documentation and defaults are aimed at installing and using Ubuntu, which is not a bad thing at all. It’s a nice distro and there’s a lot of documentation and community support available for it.

Following the instructions on the WSL documentation site brings up an Ubuntu VM running on WSL. It’s a great way to start using a terminal based Linux system running on your Windows laptop. You can also run Linux GUI applications, but for these posts, I will not look into that. If you’re interested: it’s all documented by Microsoft how to get going with that as well.

The integration of Linux and Windows is great. It’s very easy to access files from either end and it allows you to start Windows applications from your Linux terminal as well.

Visual Studio Code and WSL

Once WSL is up and running, we can use Visual Studio Code to edit files on both Windows and the Linux system. Running code on the Linux system for the first time will result in some changes. First of all, code will download and configure Visual Studio Code Server on the Linux system. There’s nothing to configure, it’s all done by VS Code itself.

Next VS Code will opt to install the WSL extension. This allows VS Code to run on the Linux system itself and provide the UI in Windows. This is the first basic remote working with VS Code option. All the heavy work is done on the Linux system and Windows will take care of the UI work.

Where’s my data?

Let’s start to work with some text files on the Linux VM. I log in to the Linux system using the wsl command on Windows. This brings up a terminal where I can go to /home/LinuxUser. In that folder I enter the command code . (<= don’t forget to enter the dot!), which will launch VS Code and open up the current folder (that’s what the dot is for). All files and folders that I now create here are stored in the Linux VM filesystem, which is a virtual hard drive on the Windows laptop. That virtual hard drive, assuming we use the out of the box creation of the VM, is stored somewhere in your %userprofile%/AppData/Local folder.

It’s also possible to access files on your Windows filesystem from the Linux VM. The Windows disks are mounted in the Linux VM under /mnt. For example, to access a file stored on your Windows desktop, you go to /mnt/c/users/WindowsUser>/Desktop and open the file. And it also works the other way around by accessing files stored on the Linux system from Windows Explorer by going to \\wsl.localhost\Ubuntu\home\LinuxUser on the Windows laptop itself.

Working with files, running software on the Linux VM, that are stored on the Linux filesystem is much faster than files that are stored in a Windows folder. Crossing the boundaries of the operating systems will introduce delays. When installing, for example, a database server, you want to make sure that the database files are kept on the Linux filesystem.

Backup

In general, I have no data stored on my computer only. Code is stored in a GIT repository. And documents are mostly on OneDrive. But what if I store data (for example the database files mentioned before) on my Linux filesystem and want to create a backup of it?

I opted to backup all WSL VMs using a PowerShell script, which looks like this:

# set-executionpolicy remotesigned
#  or
# powershell.exe -ExecutionPolicy Bypass -file "wsl-backup.ps1"

$env:WSL_UTF8 = 1
$wsl = (Get-Command wsl).Definition

Invoke-Expression "& $wsl --shutdown"

$timestamp = $(Get-Date -Format "yyyyMMdd_HHmm")
$distros = $(Invoke-Expression "& $wsl --list --quiet")
foreach ($distro in $distros)
{
    if ($distro -ne "")
    {   
        Invoke-Expression "& $wsl --export $distro $timestamp-$distro.vhdx --vhd"
    }
}

The script will first shutdown all WSL VMs. Once that is done, each VM is exported to a file in the current folder. The VM is exported as a virtual hard drive. This allows me to easily import it again on the same or another computer if I need to.

To prevent data loss when my computer get’s corrupted or stolen, I store the exported files on OneDrive. Currently, these files are big as they represent the full Linux disk including all the unused space in it. Microsoft is working on supporting sparse virtual hard drives with WSL, but that’s not available yet. I also saw an option to use a Hyper-V PowerShell module to shrink the vhd files, but I haven’t put time or effort in this topic yet.

Is it useful?

Running an Ubuntu system on the laptop is nice, but most of the functionality was already available using Git Bash on my Windows system. In my next post I will focus on running containers on a Linux system. Having that capability makes it far more interesting. So, this was just a step to take; done; let’s move on.

Want to respond to this post?

Twitter

Facebook

LinkedIn