Proxmox Backup to NAS: NFS vs SMB Setup and Restore Checklist

Preparation date: September 17, 2026. Scope: This is a documentation-based implementation and verification guide, not a claim about a completed customer incident. It covers ordinary Proxmox VE VZDump backups written to NAS storage. A Proxmox Backup Server datastore is a different architecture and is called out separately. The short answer is: choose NFS when Proxmox is the main consumer and your NAS can restrict the export to the Proxmox node addresses. Choose SMB/CIFS when the same share must also fit a Windows-oriented operating model or your NAS administration is already built around named users and SMB permissions. The protocol choice matters, but the restore test matters more. A green backup task proves that an archive was written; it does not prove that you can recover a VM on replacement storage. Proxmox backup to NAS verification flow A Proxmox node writes a VZDump backup over NFS or SMB to a NAS, then a separate restore test validates recovery. ...
Post a Comment

vSphere HA Management Network Alarm: Broken Paths vs. Stale Addresses

An HA management-network reachability alarm needs a network diagnosis before an HA reset. A host remaining connected to vCenter does not establish that every peer-to-peer management path is healthy. This is a documentation-based guide, not a reproduced outage report.

Correction, September 12, 2026: The earlier article recommended HA toggles and management-service restarts too broadly and advised a single management VMkernel adapter without considering the intended design. Those generic instructions have been removed.

Separate a broken path from a stale address

ObservationEvidence to collectNext decision
Alarm names a current management addressHost-pair connectivity, VLAN, routes, uplinks, firewall and MTU configurationRepair the demonstrated path problem before resetting HA.
Alarm names an address recently removed or retaggedChange record, current VMkernel inventory, FDM log reference to the old addressCheck the stale-metadata scenario in Broadcom KB 413121.
Several hosts fail togetherShared switch, VLAN or policy changes and start timeInvestigate common infrastructure rather than restarting each host.

Record ESXi and vCenter builds, the complete alarm text, affected peers, and the management network design. Distinguish management connectivity, isolation-address reachability, and vMotion connectivity; success in one does not prove the others. Do not remove management adapters simply because more than one exists.

Read-only investigation first

  1. Preserve the alarm and relevant host/FDM logs before restarting anything.
  2. Map each current management VMkernel address to its VLAN, interface and peer hosts. Compare with a known-good host.
  3. Use the interface-aware connectivity tests appropriate for the deployed ESXi version. Record source and destination; a test from a workstation is not the same path.
  4. Compare physical uplink, VLAN, routing and required firewall rules. A successful ping is only one observation and does not validate all HA traffic.
  5. Check recent interface creation, deletion or management-service retagging against the address named in the alarm.

When HA reconfiguration is justified

Broadcom KB 413121 describes stale FDM network metadata following management-interface changes in vCenter 7.x/8.x. Its resolution refreshes HA configuration by disabling and enabling HA. Apply that guidance only when the symptoms and environment match. It is not a remedy for a real broken VLAN or route.

Plan the protection gap. Running VMs continuing to run while HA is disabled is not the same as retaining HA recovery protection. Obtain a maintenance approval, verify cluster capacity and host health, record existing HA settings, and avoid overlapping host maintenance. If HA cannot be restored, treat it as a degraded-protection incident and escalate rather than repeatedly toggling the cluster.

The broader Broadcom HA configuration requirements are useful when HA cannot configure. Do not restart hostd/vpxa or reboot hosts as an automatic next step; assess management-task and workload impact with the platform owner.

Close only after protection is restored

Verify HA is enabled, host configuration tasks have completed, expected hosts are healthy, and reachability alarms do not recur during the agreed observation window. Compare the final network and HA settings against the intended design. Clearing an alarm is not a failover test. Conduct any recovery drill separately under an approved plan; never create an unplanned production failure to prove this repair.

Related troubleshooting guides

Comments

Post a Comment

Popular posts from this blog

Horizon vdpConnect_Failure: Connection-Stage Triage Before Reinstalling

vdpConnect_Failure is a starting symptom, not a root-cause diagnosis. Before reinstalling Horizon Agent or opening firewall ports, establish whether the failure occurs during authentication, desktop launch, or an established session. This documentation-based triage guide does not report a reproduced incident or a universal fix. Corrected September 12, 2026: The earlier guide suggested restarting the Windows RPC service and treated a local netstat listing as a test for blocked ports. Those instructions have been removed. A socket listing does not demonstrate end-to-end reachability. Classify the failure before making changes Observation First evidence to collect Avoid assuming Authentication never completes Exact login error, identity provider or broker event, timestamp That the display protocol is the failing component. Desktop selection succeeds, launch fails Assigned desktop, chosen protocol, Client/Agent and gateway logs That a successful HTTPS login proves the session path ...
Read more

Horizon Agent Unreachable: Registration and Desktop-Health Triage

Start an “Agent Unreachable” investigation by separating desktop health, Agent registration, and session traffic. Do not begin with a pool rebuild. This documentation-based triage guide helps decide which team should act and what evidence to preserve. Correction, September 12, 2026: The earlier guide mixed display ports with Agent communication, tested Blast against the Connection Server, and offered generic service restarts and image rebuilds. Those instructions have been replaced with path-specific investigation. First-response decision table Check Evidence Investigation owner Is the guest responsive? Approved console access, OS health, resource and disk observations Desktop/virtualization team if the OS is unavailable. Is this one desktop or a whole image family? Affected pool, image revision, Agent version, start time Image owner if failures align with a deployment. Does registration fail? Agent and Connection Server events for the same desktop and time Horizon team, then netw...
Read more

Horizon Protocol Error: Trace the Display-Session Handoff

A desktop can authenticate successfully and still fail to establish its display session. This guide investigates that handoff. Use it after identifying the actual console/client error, not as a claim that every “Protocol Error” means a firewall failure. Correction, September 12, 2026: The previous version combined a general checklist with an unverified incident narrative, conflated gateway and desktop port directions, and recommended blanket endpoint-security exclusions. Those instructions have been removed. This is a documentation-based diagnostic plan. Draw the attempted connection Record the selected protocol, assigned desktop, Client and Agent versions, gateway route, and attempt time. Distinguish a direct internal connection from an external UAG connection or a Connection Server tunnel. Use Omnissa's connection guide to identify where the failed handoff occurs. Stage Question Useful comparison Authentication Did the user receive desktop entitlement? Failed login versus ...
Read more