<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>AzureToZ</title>
    <link>https://azuretoz.com/</link>
    <description>Recent content on AzureToZ</description>
    <generator>Hugo</generator>
    <language>en</language>
    <lastBuildDate>Sat, 04 Jul 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://azuretoz.com/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>HCX Mobility Optimized Networking: Getting Your Migrated VMs Off the Trombone</title>
      <link>https://azuretoz.com/articles/hcx-mobility-optimized-networking/</link>
      <pubDate>Sat, 04 Jul 2026 00:00:00 +0000</pubDate>
      <guid>https://azuretoz.com/articles/hcx-mobility-optimized-networking/</guid>
      <description>&lt;p&gt;If you have ever stretched a network with HCX and migrated a VM into Azure VMware Solution, you have probably hit this: the VM moved, but its traffic acted like it never left. Every packet still detours back through the on-premises gateway before going anywhere, even to reach a resource sitting right next to it in the cloud.&lt;/p&gt;&#xA;&lt;p&gt;That threw me the first time I saw it. It is not a bug, just how a Layer 2 extension behaves once you stretch it. HCX has a feature built specifically to deal with this: &lt;strong&gt;Mobility Optimized Networking&lt;/strong&gt;, or MON. What caught me out is that MON is not one switch. It is two settings that need to agree with each other, and if you flip only one, you tend to swap one bad path for a different, equally annoying one. Below are both settings, what they are actually doing under the hood, and how I ended up tuning them per workload.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Welcome to AzureToZ</title>
      <link>https://azuretoz.com/articles/welcome-to-azuretoz/</link>
      <pubDate>Mon, 15 Jun 2026 00:00:00 +0000</pubDate>
      <guid>https://azuretoz.com/articles/welcome-to-azuretoz/</guid>
      <description>&lt;p&gt;AzureToZ is a tech and coding blog, and at its core is one idea: a good tutorial should take you the whole way. From an empty resource group to a working, verified setup. From &amp;ldquo;I&amp;rsquo;ve never touched this&amp;rdquo; to &amp;ldquo;I&amp;rsquo;ve got it running and I understand what I did.&amp;rdquo; No steps quietly skipped, no &amp;ldquo;the rest is left as an exercise for the reader&amp;rdquo; right where it gets interesting.&lt;/p&gt;&#xA;&lt;p&gt;But it isn&amp;rsquo;t only tutorials. It&amp;rsquo;s also where I write up the interesting things I run into along the way: the quirks, the gotchas, and the small discoveries that don&amp;rsquo;t need a full step-by-step but are worth sharing anyway.&lt;/p&gt;</description>
    </item>
    <item>
      <title>About</title>
      <link>https://azuretoz.com/about/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://azuretoz.com/about/</guid>
      <description>&lt;p&gt;Most of my work sits at the intersection of &lt;strong&gt;Azure, VMware and networking&lt;/strong&gt; - helping organisations modernise infrastructure without disrupting the services that depend on it.&lt;/p&gt;&#xA;&lt;p&gt;I came up through VMware, and that foundation still shapes how I think about architecture, migrations and platform design today. While much of my current work focuses on &lt;strong&gt;Azure networking&lt;/strong&gt; and &lt;strong&gt;Azure VMware Solution&lt;/strong&gt;, the underlying challenge is usually the same: delivering reliable infrastructure that people can depend on.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
