When setting up a Proxmox VE environment it is common to end up with a node named pve , which is the default hostname assigned during installation. This becomes a problem when managing multiple Proxmox servers since every node will show up as pve in the web UI. This post covers the complete process for renaming a Proxmox node to a meaningful name including the FQDN, and how to handle the pmxcfs filesystem quirks that make this more involved than a standard Linux hostname change. Understanding How Proxmox Uses the Hostname Proxmox VE derives the node name directly from the short hostname (the part before the first dot). This means a server configured with the FQDN pve-node-1.example.lan will appear in the UI as pve-node-1 . It is important to plan the naming convention carefully upfront. A naming scheme like pve-node-1 , pve-node-2 works well because the short hostname is already fully unique, without relying on the domain portion to differentiate nodes. Proxmox stores its ...
Fixing Application Insights Dependency Injection After Upgrading Microsoft.ApplicationInsights.WorkerService to 3.0.0
As part of our routine monthly maintenance on Azure Functions, we update NuGet packages to stay current and pick up bug fixes. This month that process led to a breaking change when we upgraded Microsoft.ApplicationInsights.WorkerService from version 2.23.0 to 3.0.0 on our .NET 8 Azure Functions. After the upgrade, our Application Insights logging stopped working entirely. Telemetry was no longer being captured, and it became clear that the dependency injection configuration in our Program.cs was the culprit. Here is what we had and how we fixed it. The Problem In version 2.23.0, we configured Application Insights in Program.cs like this: public static void Main(string[] args) { IHost host = new HostBuilder() .ConfigureFunctionsWorkerDefaults() .ConfigureServices(s => { s.AddApplicationInsightsTelemetryWorkerService(options => { options.EnableAdaptiveSampling = false; }); s.ConfigureFunc...