Dynamic Root Disk Frequently Asked Questions (August 2010)

top
1-9. Q: What if the DRD contains more than one disk? Does DRD handle this?
A: Currently, the target disk must be a single physical disk, or SAN LUN, large enough to hold all of the root volume file systems. This
allows a customer to clone the root volume group even if it is spread across multiple disks. Note that this is a one-way, many-to-one
operation.
top
1-10. Q: Can DRD clone all the partitions; s1, s2, & s3?
A: All partitions are created and s1 and s2 are copied. This release of DRD does not copy the HP service partition.
top
1-11. Q: Does DRD work with both LVM and VxVM root disks?
A: Yes, the root group being cloned can be managed by any release of LVM on an OS release supported by DRD. In addition, the root
group can be managed by VxVM 4.1 or VxVM 5.0. See the DRD Installation
webpage for information about the required patches if you
are cloning a VxVM root.
If you are cloning a supported root, you can have non-root groups on the system managed by any release of LVM or VxVM, including
VxVM 5.0. These groups are, of course, not cloned.
top
1-12. Q: Does DRD support vPars?
A: Follow this procedure for DRD usage with vPars and nPars
1. Clone each vPar on the system with the following command. Note that this does not clone custom EFI contents. You must use
EFI commands outside DRD if custom EFI contents are to be copied to the clone.
# drd clone -t /dev/disk/disk5 -x overwrite=true
2. Activate each clone with the following command. This changes the vPars bootpath that is stored in the vPar database. The
bootpath for vpmon on the nPar is not updated when a clone is activated from a running vPar.
# drd activate -x reboot=true
At this point, the bootpath for vpmon on the nPar points to an inactive (original) image even though vpmon is still up and running. The
running vpmon maintains the master copy of the vPar database in memory. This data is synchronized with each running vPars local
copy of /stand/vpdb. When vpmon is booted, the local /stand/vpdb is loaded into memory and serves as the master copy. If a
vPar is down while changes are made that affect the vPar database, subsequent booting of vpmon from that vPar results in the loss of
those changes because the local copy of the vPars database is stale when loaded by vpmon.
NOTE: HP recommendeds that the vpmon bootpath is modified to point to the clone once it is activated, though there is no need to
actually reboot the nPar unless the vpmon executable has been changed.
If running vPars release A.05.06 or later on Integrity, the default bootpath for vpmon can be set from the monitor prompt. This first EFI
boot manager menu entry can be changed without rebooting the nPar. The following monitor command sets the bootpath for the active
clone image corresponding to the vPar previously used to boot vpmon:
MON> mon_bootpath -p [new_bootpath]
From vPars release A.04.05 up to vPars release A.05.06 on Integrity, the mon_bootpath command only allows you to add additional
bootpaths to the nPar EFI boot manager menu. For these releases, you need to change the default boot entry from the EFI menu during
a reboot in nPar mode. Prior to vPars release A.04.05, you need to change the default boot entry from the EFI menu during a reboot in
nPar mode. In all cases, if the alternate or HA bootpaths need to be updated, they need to be updated from the EFI menu during a
reboot in nPar mode.
On PA systems, changes to vpmon bootpaths can be made from a running vPar:
# parmodify -p [partition_number] -b [bootpath] -P [partition_name]
Note that individual bootpath settings for setboot are lost if the disk at the specific path is re-created with any of the following:
The drd clone command
Ignite cold install
Ignite recovery
top