The error hbr_filter missing required option: gid means ESXi is trying to attach the host-based replication filter to a virtual disk, but the VM configuration does not contain a complete replication group identity. When it appears immediately after cloning a VM, stale vSphere Replication metadata in the clone’s .vmx file is a stronger lead than a removed USB device.
Broadcom documents the same power-on signature as a cloning limitation in which HBR filter entries are not removed correctly from the cloned configuration. Its official workaround removes the orphaned filter references and reloads the VM configuration.
The referenced KB covers specific Cloud Director, Availability, and ESXi environments. On another vSphere release, use the error signature as diagnostic evidence and confirm the VM’s replication state before applying the workaround.
Why the Disk Name Appears in the Error
The stack commonly includes messages such as:
Unable to create virtual SCSI device for nvme0:0
Failed to attach filter 'hbr_filter' to nvme0:0
hbr_filter missing required option: gid
This does not necessarily mean the VMDK data is damaged or that NVMe is unsupported. ESXi opens the virtual disk and attempts to build its filter chain. The incomplete replication filter fails during device creation, so the whole virtual machine cannot power on.
A USB dongle or passthrough device can cause a different power-on failure if the clone still requires unavailable hardware. Remove an obsolete USB device through Edit Settings, but do not expect that action to repair HBR metadata.
Confirm the Clone Is Not Supposed to Replicate
Before editing anything, answer three questions:
- Is the source or clone currently registered in vSphere Replication or a disaster-recovery product?
- Does the protection system still show an active group, recovery, failover, or cleanup operation?
- Is this VM powered off with no snapshot, backup, or replication task running?
If replication is active or intended, disable or repair it through the replication management product. Removing its filter configuration manually can break protection and leave state inconsistent.
For an ordinary independent clone that should not be replicated, stale HBR lines have no useful function.
Preserve the Configuration
Record the VM ID, datastore path, disk list, snapshot state, and registration location. Back up the .vmx file before changing it. A configuration backup is small, but it does not replace a backup of the VM’s data disks.
With the VM powered off, a read-only search on the owning ESXi host can confirm the residue:
grep -n "hbr_filter" cloned-vm.vmx
Also search for disk filter assignments:
grep -n "\.filters" cloned-vm.vmx
Expected stale entries can include global hbr_filter.* values, a disk line such as nvme0:0.filters = "hbr_filter", and per-disk hbr_filter persistence or replication identifiers. The exact controller prefix may be scsi, sata, or nvme.
Remove Only the Orphaned HBR References
Follow Broadcom’s supported sequence: keep the VM off, create a backup of its .vmx, remove or comment the HBR filter lines from that configuration, and reload the VMX. Do not delete the .vmdk, descriptor files, snapshots, or persistent-state files merely because their names appear near the error.
The removal set may include:
hbr_filter.configGen
hbr_filter.gid
hbr_filter.destination
hbr_filter.port
hbr_filter.rpo
hbr_filter.protocol
hbr_filter.quiesce
hbr_filter.opp
hbr_filter.pause
<controller>:<unit>.filters = "hbr_filter"
<controller>:<unit>.hbr_filter.rdid
<controller>:<unit>.hbr_filter.persistent
Edit the actual lines present rather than pasting an assumed controller name. Leave unrelated filters and virtual-disk configuration intact.
Reload Before Power-On
ESXi can retain the registered VM configuration in memory. After editing the file, use the Broadcom procedure for reloading a VMX without unnecessarily deleting VM files. In managed environments, reload through the supported host or vCenter workflow. Removing a VM from inventory and registering it again is a separate operation and should be used only with an exact datastore path and change record.
After reload, confirm that the virtual hardware still references the correct VMDK chain, no unavailable USB device remains marked as required, and no HBR filter lines reappear. Then power on the clone and review the task plus vmware.log for a new error rather than assuming every subsequent issue has the same cause.
If the Error Returns
If the lines return automatically, a replication or availability manager may still own the VM. Stop editing the .vmx and reconcile the inventory in that product. If no stale lines exist, inspect the full task details and host logs for a filter-download, vmkernel-network, or disk-chain problem; hbr_filter failures can have more than one cause.
Do not use an unrelated VMware version upgrade as the first recovery step for a single clone. Broadcom states that the documented cloning limitation is resolved in ESX 9.0.1.0 for its specified environment, but an upgrade requires its own compatibility and lifecycle plan.
The safe fix is narrow: prove the clone should be independent, back up the configuration, remove only orphaned replication-filter references, reload the VMX, and test. That repairs the control-plane metadata without touching the guest data disk.
