Auto response no automated response will occur impact

AUTO-RESPONSE: No automated response will occur.
IMPACT: Fault tolerance of the pool may be compromised.
REC-ACTION: Run 'zpool status -x' and replace the bad device.
For each disk in the computer you may see the error message. However, when
you log on and run the
zpool status -x
command, you see the following message:
all pools are healthy
That is because of the ZFS import operation that is done during the first boot
sequence. Bare Metal Restore (BMR) restores storage pools and contents in the
BMR restoration environment and later imports to the client environment during
first boot. That can cause an error message or a warning message during the first
boot operation.
These messages only occur during the first boot operation and you can safely ignore
them.
BMR may not format or clear the ZFS metadata
If you opt for the creation of a ZFS storage pool on small number of disks during a
dissimilar disk restore (DDR), Bare Metal Restore (BMR) does not format or clear
the ZFS metadata on the disks that remain. Because of that, if you attempt to use
those disks to create other storage pools, you may see an error message that states
a disk is in use under the ZFS storage pool.
37 Operational notes
NetBackup Bare Metal Restore operational notes

To work around this issue, use the
-f
option to create a new storage pool on those
disks.
Coexistence of two BMR-supported multi-path solutions can cause
issues
Coexistence of two Bare Metal Restore (BMR)-supported multi-path solutions (EMC
PowerPath and Linux native multi-path) with both actively configured on a client
can cause issues and is not supported by BMR.
A BMR issue can result if a multi-device that is configured over a SAN disk using
the EMC PowerPath name, and the SAN disk is under both EMC PowerPath and
the Linux Native multi-path. In addition, this configuration is unsupported. However,
if the same multi-device is configured over a SAN disk using the Linux native
multi-path name then it works with BMR.
A BMR restore may fail during a Linux DDR scenario between internal
disk and SAN disk
A Bare Metal Restore (BMR) restore may fail during a Linux dissimilar disk restore
(DDR) scenario from internal disk to SAN disk and vice versa.
BMR does not consider the disk ordering in the BIOS. For SAN disk to an internal
system disk, the restore may not work as expected because of the disk ordering
changes in the BIOS. This issue may be more common in GRUB installations.
If you remove SAN disks before restoration, then the restore may work properly
with the existing BIOS ordering.
BMR backups may fail on Citrix XenCenter virtualization due to disk
naming
Bare Metal Restore (BMR) can only support disk naming conventions such as
hdX
,
sdX
,
cXDn
, and so forth.
BMR backups can fail on Citrix XenCenter virtualization for the following reasons:
■
BMR does not recognize disk names such as
xvdX
, which are newly introduced
on Citrix XenCenter virtualization. This issue is due to the Xen para-virtual drivers
that are introduced in this type of virtual environment.