System Administration
Showing results for 
Search instead for 
Did you mean: 

problem with volclonedg on large volume

Grande Mario

problem with volclonedg on large volume

Greetings all,

Hope that someone can help me to find out a solution to following problem:

Customer has Tru64 v5.1b Cluster and XP12000 Storage. We are using volclonedg to create a copy of an LSM disk group whose underlying disks have been cloned via XP12000. We clone 4 different dg's and we encounter a problem only on the largest dg who contains more then 60 striped disks. The other dg's contains between 3 to 10 striped disks.
The volclonedg is very slow (runs about 30mins), but it ends successfully and all volumes (including the large datadg) are online, started and accessible on the target system. But if we reboot the target system the disks in the datadg are "online aliased". The strange thing is that the hostid in disks shows the source host and not the target host. The other cloned dg's have the correct target hostid. The volclonedg is executed via rsh from the source host to the target host with following string. A volsave is executed on the source host before the volclonedg is executed:
rsh $REMOTEHOST /usr/sbin/volclonedg -d $LSMCONFDIR/LSM.*."$LOCALHOST" -c $i -l $DISKS >/dev/null 2>&1

Does anyone knows about such kind of problems with volclonedg? Is there a possibility to better troubleshoot it?
Any help would be very appreciated.

Mario Grande
HP Switzerland
Ivan Ferreira
Honored Contributor

Re: problem with volclonedg on large volume

Sorry if I don't help, I don't know very much about LSM, but I just want to ask you if:

You run the freezefs before taking the hardware snapshot?

You run the hwmgr after the hardware disk cloning?
Por que hacerlo dificil si es posible hacerlo facil? - Why do it the hard way, when you can do it the easy way?
Grande Mario

Re: problem with volclonedg on large volume

Hi Ivan,

We do not a freezefs because we do a pairresync and a pairsplit on XP12000 with unactive advFS domains.
The hole procedure is made by a script. These are roughly the steps:

1. Stop application on source and target host
2. Gather fdmns information on targethost
3. umount all relevant mountpoints on source and target host
4. Save LSM config with volsave on sourcehost
5. Deport dg's on targethost
6. pairresync and pairsplit on XP12000
7. Mount all filesets on sourcehost
8. Restore /etc/fdmns entries on targethost
9. Dg import with volclonedg on targethost
10. Mount all filesets on targethost
11. Start application

This procedure is in use and works fine since many months. But we used it without LSM. Now since we have introduced LSM stripe sets to reach better performance we encouter a problem that the dg are available immediately after the volclonedg, but if we reboot the targethost the largest dg isn't any more available because the disks are in the "online aliased" state. That means that they have the wrong hostid in the private region. We can fix it manually but we suppose that something goes wrong with the volclonedg.

Mario Grande