Couple of days ago my colleague told me about one neat feature of VxVM 5.x that could be quite helpful in the field. Imagine a situation when a customer complains about VxVM misconfiguration and blames your team for a slime work. To prove him wrong, you could sift through VxVMs’ command log files to get a list of commands you typed during initial configuration. If a customer did something wrong himself and now is trying to shift the blame upon you these log files could be of invaluable help as well – just show where and when he made the mistake. The log files could me found in /etc/vx/log and are named /etc/vx/log/cmdlog and /etc/vx/log/cmdlog.number for the current and historic command logs respectively. There is a vxcmdlog(1M) command to give you some control over this feature.
One thing to keep in mind is that no every commands script are logged:

Most command scripts are not logged, but the command binaries that they call are logged. Exceptions are the vxdisksetup, vxinstall, and vxdiskunsetup scripts, which are logged.

Last night I was upgrading a domain on our SF6900 box to Solaris 10 and since we use VxVM to mirror our root disk there was no use in preparing dedicated backup neither on tape nor on separate disk because it’s much easier and accurate to split rootdg into two disk groups, e.g. rootdg and rootdgold, and later import rootdgold, i.e. our saved copy of rootdg, to restore every single file. But when I tried to start the volumes it only revealed that not everything went off smoothly:

# vxvol -g rootdgold startall
VxVM vxvol ERROR V-5-1-11804 Volume coredump is empty and cannot be started
VxVM vxvol ERROR V-5-1-11804 Volume oem_home is empty and cannot be started
VxVM vxvol ERROR V-5-1-11804 Volume var is empty and cannot be started
VxVM vxvol ERROR V-5-1-11804 Volume rootvol is empty and cannot be started
VxVM vxvol ERROR V-5-1-11804 Volume swapvol is empty and cannot be started

Looking at the volumes I found that all of them were really in EMPTY state:

/*
* XXX - Don't port this to new architectures
* A 3rd party volume manager driver (vxdm) depends on the symbol romp.
* 'romp' has no use with a prom with an IEEE 1275 client interface.
* The driver doesn't use the value, but it depends on the symbol.
*/
void *romp; /* veritas driver won't load without romp 4154976 */

# bperror -S 96
unable to allocate new media for backup, storage unit has none available
The tape manager (bptm) could not allocate a new volume for backups.
This indicates that the storage unit has no more volumes available in the
volume pool for this backup. Note that NetBackup will not change storage
units during the backup.

All it says is that we’ve ran out of free tapes in our pool. Use the following command to get a list of available recommendations from Symantec.

# bperror -S 96 -r

In absolutely most cases all that you’ll have to do to resolve the issue is just to find an appropriate tape and expire it. Doing so, the expired tape will be automatically placed into the ScratchPool, don’t tell me that you don’t have it ;-), from which it will be lately reused when your backup job starts on the schedule.

Just stumbled upon a strange behavior of vxdmpadm which requires further investigation.
The problem I’ve faced with during an attempt to set certain path “active” to loadbalance the data flow on HDS between its controllers. The built-in help clearly states that:

Looks like I’ll need to investigate deeper to find the culprit but as a workaround just disabled the second path to force a failover to another one I tried to make active.

Update.
As always RTFM rules and I must admin that my apprehension, that with option one could change the state listed in the second column to active, was completely wrong. In the man page it’s lucidly written that pathtype=active is used to change a standby path to active.

Recently I had to restore some data from a tape written by means of Netbackup, so solely for the reference purposes I decided to write this short post.
First we need to mount the tape, I did this using robtest utility, and perfrom a robot’s inventory to make Netbackup aware about a new tape. Keep in mind that sometimes barcode visible on the tape itself could not much with what has been written on the tape during the backup. This discrepancy could be a result of different Netbackup’s barcode rules. To double check, use more e.g. more /dev/rmt/13cbn
After that I ran the following set of commands: