<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Hyper-V on Luther Monson</title>
    <link>https://luth.io/tags/hyper-v/</link>
    <description>Recent content in Hyper-V on Luther Monson</description>
    <generator>Hugo</generator>
    <language>en</language>
    <lastBuildDate>Sat, 22 Aug 2026 19:40:00 -0700</lastBuildDate>
    <atom:link href="https://luth.io/tags/hyper-v/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Five Ways to Not Firewall a Windows Container (and the One That Works)</title>
      <link>https://luth.io/blog/2026/08/windows-container-egress-firewall/</link>
      <pubDate>Sat, 22 Aug 2026 19:40:00 -0700</pubDate>
      <guid>https://luth.io/blog/2026/08/windows-container-egress-firewall/</guid>
      <description>&lt;p&gt;&lt;a href=&#34;https://luth.io/blog/2026/08/ephemerd-one-daemon-every-os/&#34;&gt;ephemerd&lt;/a&gt; runs CI jobs from pull requests. One of the rules is that a job can&#xA;reach the internet but not my LAN. On Linux that&amp;rsquo;s a few iptables rules in the &lt;code&gt;FORWARD&lt;/code&gt; path, and I didn&amp;rsquo;t think about it&#xA;much. On Windows I spent about a week finding out how many ways there are to write a firewall rule that Windows accepts,&#xA;lists and never applies.&lt;/p&gt;&#xA;&lt;p&gt;The setup is Windows Server 2025 (build 26100) with job containers running under Hyper-V isolation. They sit on the default&#xA;HNS NAT network that every Windows container tutorial uses. In ephemerd&amp;rsquo;s case that&amp;rsquo;s &lt;code&gt;10.88.0.0/16&lt;/code&gt; with gateway&#xA;&lt;code&gt;10.88.0.1&lt;/code&gt;. The target is the same as Linux. Block &lt;code&gt;10.0.0.0/8&lt;/code&gt;, &lt;code&gt;172.16.0.0/12&lt;/code&gt;, &lt;code&gt;192.168.0.0/16&lt;/code&gt; and &lt;code&gt;169.254.0.0/16&lt;/code&gt;,&#xA;and allow everything else.&lt;/p&gt;</description>
    </item>
    <item>
      <title>ephemerd: One Daemon, a Fresh Runner Per Job, Every OS</title>
      <link>https://luth.io/blog/2026/08/ephemerd-one-daemon-every-os/</link>
      <pubDate>Tue, 18 Aug 2026 21:05:00 -0700</pubDate>
      <guid>https://luth.io/blog/2026/08/ephemerd-one-daemon-every-os/</guid>
      <description>&lt;p&gt;I have CI that needs Linux amd64, Linux arm64, Windows and macOS. GitHub-hosted runners for all four get expensive fast,&#xA;especially the arm64 and Mac minutes. Self-hosted runners fix the bill and create a different problem. A stock&#xA;&lt;code&gt;actions/runner&lt;/code&gt; on a box you own runs whatever the workflow says. It keeps whatever the last job left behind. And it&amp;rsquo;s&#xA;one fork PR away from somebody running code on your LAN.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Escaping WSL: Booting My Own Linux VM Through Hyper-V&#39;s HCS API</title>
      <link>https://luth.io/blog/2026/06/escaping-wsl-hcs-linux-vm/</link>
      <pubDate>Sun, 14 Jun 2026 20:12:00 -0700</pubDate>
      <guid>https://luth.io/blog/2026/06/escaping-wsl-hcs-linux-vm/</guid>
      <description>&lt;p&gt;I&amp;rsquo;ve been building &lt;a href=&#34;https://github.com/ephpm/ephemerd&#34;&gt;ephemerd&lt;/a&gt;, a daemon that runs self-hosted GitHub Actions runners&#xA;with a fresh environment per job. On a Windows host, Windows jobs run in Hyper-V isolated containers. Linux jobs still&#xA;need a Linux kernel from somewhere. The obvious answer on Windows in 2026 is WSL2, and that&amp;rsquo;s what I used first. It worked&#xA;great from my terminal and fell over the moment ephemerd became a real Windows service.&lt;/p&gt;&#xA;&lt;h3 id=&#34;wsl2-doesnt-do-localsystem&#34;&gt;WSL2 doesn&amp;rsquo;t do LocalSystem&lt;/h3&gt;&#xA;&lt;p&gt;A Windows service that wants to create containers and Hyper-V VMs runs as &lt;code&gt;LocalSystem&lt;/code&gt;. WSL2 doesn&amp;rsquo;t support that context&#xA;at all. You get &lt;code&gt;WSL_E_LOCAL_SYSTEM_NOT_SUPPORTED&lt;/code&gt; and that&amp;rsquo;s the end of the conversation. There&amp;rsquo;s no flag for it. WSL is a&#xA;per-user feature and a service account isn&amp;rsquo;t a user.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
