VDI and infrastructure troubleshooting: operator-reported incidents, documentation-based guides, and practical investigation worksheets. Evidence and limitations are stated in each article.
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. ...
Get link
Facebook
X
Pinterest
Email
Other Apps
ESXi /bootbank Alarms After Disk Replacement: What This Incident Did and Did Not Prove
Get link
Facebook
X
Pinterest
Email
Other Apps
Operator-reported incident with documentation-based safety notes. Revised September 12, 2026. The sequence below was supplied by the operator. Exact alarm text, ESXi build, boot-device layout, log extracts, and a measured observation duration were not supplied. The root cause remains unconfirmed.
What was actually reported
vCenter raised an alarm for another hardware object on one host.
A failed physical disk was found and replaced.
Afterward, /bootbank warning emails recurred—sometimes within five minutes, sometimes at roughly hourly intervals.
The operator and hardware maintenance vendor placed the host in maintenance mode and rebooted it.
The emails stopped after some additional time. Continued observation found no further problem, and the host is currently in service according to the operator's account.
This is a recovery observation, not proof that the replaced disk held the bootbank, that a RAID fault caused the warning, or that restarting repaired damaged media. We also cannot distinguish a continuing host fault from delayed or repeated notification using email alone.
The diagram summarizes the reported sequence, not a universal repair procedure. Read the reboot safety gate below.
The most useful missing evidence
Original event versus email delivery: record the event timestamp, last occurrence, alarm state, and notification time. A late email may describe an earlier event.
Disk role: identify the replaced device and determine whether it belongs to boot media, a data datastore, or another subsystem. Do not infer this from physical proximity or replacement timing.
Boot access: preserve relevant host logs and the vendor's findings before a restart removes transient evidence.
Build and topology: record ESXi version, boot layout, controller state, and maintenance changes before matching a knowledge-base article.
Reboot safety gate—not a universal fix
Broadcom documents cases in which connection to bootbank storage is lost and warns that a host may not boot again. Maintenance mode protects workloads during a planned operation; it does not repair the boot device or guarantee restart success.
Before repeating this incident's recovery action, have the platform and hardware owners assess boot-device accessibility and restart risk. Confirm workload evacuation or an approved shutdown plan, spare cluster capacity, out-of-band console access, appropriate configuration recovery material, and a supported recovery/reinstallation path. Preserve evidence and arrange the maintenance window. If safe recovery cannot be assured, escalate before rebooting rather than following the diagram mechanically.
Verification should test the host, not only the mailbox
Compare newly generated host events and current alarm state with email history. Check hardware and storage health, host reconnect behavior, and representative workload operations under the site's normal checks. Select an observation window that covers the earlier recurrence pattern and scheduled activity; this report cannot supply a tested universal duration.
If the warning returns, stop treating the earlier reboot as a proven repair. Preserve the new evidence and decide with the vendor whether the host should be withdrawn from placement again. A rollback here is a safe service/recovery plan, not undoing the disk replacement or repeatedly power-cycling questionable boot media.
What another operator can take from this case
The useful lesson is the distinction between replacing a visibly failed component, restoring service, and proving the root cause. The reported host recovered after maintenance and reboot. Which mechanism caused that recovery was not established. Keep that boundary in the handover so a future incident starts with evidence rather than an assumed “reboot fixes bootbank” rule.
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 ...
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...
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 ...
Comments
Post a Comment