<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Field Notes on Daniel McDonough</title><link>https://dev.daniel-mcdonough.com/categories/field-notes/</link><description>Recent content in Field Notes on Daniel McDonough</description><generator>Hugo</generator><language>en</language><copyright>© 2026 Daniel McDonough</copyright><lastBuildDate>Wed, 13 May 2026 13:10:39 -0400</lastBuildDate><atom:link href="https://dev.daniel-mcdonough.com/categories/field-notes/index.xml" rel="self" type="application/rss+xml"/><item><title>Veeam Restores on Proxmox local-zfs</title><link>https://dev.daniel-mcdonough.com/posts/veeam-restores-on-proxmox-local-zfs/</link><pubDate>Wed, 13 May 2026 13:10:39 -0400</pubDate><guid>https://dev.daniel-mcdonough.com/posts/veeam-restores-on-proxmox-local-zfs/</guid><description>&lt;p>During some disaster recovery work, I deployed a Proxmox cluster to rapidly restore VMs from Veeam but ran into a restore target issue.&lt;/p>
&lt;p>Veeam&amp;rsquo;s Proxmox plugin can back up VMs running on &lt;code>local-zfs&lt;/code> just fine. Restoring them is the problem: Veeam won&amp;rsquo;t use a ZFS pool as a restore target. It needs Directory-type storage. ZFS storage types create zvols for each disk and restoring directly would obviously lead to complexities, especially when trying to export from Veeam as QCOWs.&lt;/p></description></item><item><title>When a 2-Year-Old Permission Change Broke OSLogin</title><link>https://dev.daniel-mcdonough.com/posts/when-a-2-year-old-permission-change-broke-oslogin/</link><pubDate>Sun, 28 Dec 2025 21:45:00 -0400</pubDate><guid>https://dev.daniel-mcdonough.com/posts/when-a-2-year-old-permission-change-broke-oslogin/</guid><description>&lt;h3 id="context">Context&lt;/h3>
&lt;p>I ran into an unusual OSLogin failure while migrating a long-running server into a new GCP project. The request was to migrate from one old GCP project into multiple new ones, one per environment. This included several VMs with dev and prod versions.&lt;/p></description></item><item><title>Upgrading a Neglected EKS Cluster from 1.17 to 1.30</title><link>https://dev.daniel-mcdonough.com/posts/upgrading-a-neglected-eks-cluster-from-1.17-to-1.30/</link><pubDate>Mon, 08 Jul 2024 19:30:00 -0400</pubDate><guid>https://dev.daniel-mcdonough.com/posts/upgrading-a-neglected-eks-cluster-from-1.17-to-1.30/</guid><description>&lt;p>On July 3rd, 2024, I ended up dealing with one of the messier Kubernetes situations I’ve encountered: upgrading an EKS cluster that had effectively been left behind for years. The push to upgrade wasn’t optional as the cluster version was approaching the end of extended support from AWS, and staying on it meant continuing to pay the higher extended support costs.&lt;/p></description></item></channel></rss>