<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: problem with volclonedg on large volume in Operating System - Tru64 Unix</title>
    <link>https://community.hpe.com/t5/operating-system-tru64-unix/problem-with-volclonedg-on-large-volume/m-p/3884843#M17871</link>
    <description>Sorry if I don't help, I don't know very much about LSM, but I just want to ask you if:&lt;BR /&gt;&lt;BR /&gt;You run the freezefs before taking the hardware snapshot?&lt;BR /&gt;&lt;BR /&gt;You run the hwmgr after the hardware disk cloning?</description>
    <pubDate>Mon, 23 Oct 2006 09:10:42 GMT</pubDate>
    <dc:creator>Ivan Ferreira</dc:creator>
    <dc:date>2006-10-23T09:10:42Z</dc:date>
    <item>
      <title>problem with volclonedg on large volume</title>
      <link>https://community.hpe.com/t5/operating-system-tru64-unix/problem-with-volclonedg-on-large-volume/m-p/3884842#M17870</link>
      <description>Greetings all,&lt;BR /&gt;&lt;BR /&gt;Hope that someone can help me to find out a solution to following problem:&lt;BR /&gt;&lt;BR /&gt;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. &lt;BR /&gt;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:&lt;BR /&gt;rsh $REMOTEHOST /usr/sbin/volclonedg -d $LSMCONFDIR/LSM.*."$LOCALHOST" -c $i -l $DISKS &amp;gt;/dev/null 2&amp;gt;&amp;amp;1&lt;BR /&gt;&lt;BR /&gt;Does anyone knows about such kind of problems with volclonedg? Is there a possibility to better troubleshoot it?&lt;BR /&gt;Any help would be very appreciated.&lt;BR /&gt;&lt;BR /&gt;cheers&lt;BR /&gt;Mario Grande&lt;BR /&gt;HP Switzerland&lt;BR /&gt;</description>
      <pubDate>Mon, 23 Oct 2006 07:48:24 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-tru64-unix/problem-with-volclonedg-on-large-volume/m-p/3884842#M17870</guid>
      <dc:creator>Grande Mario</dc:creator>
      <dc:date>2006-10-23T07:48:24Z</dc:date>
    </item>
    <item>
      <title>Re: problem with volclonedg on large volume</title>
      <link>https://community.hpe.com/t5/operating-system-tru64-unix/problem-with-volclonedg-on-large-volume/m-p/3884843#M17871</link>
      <description>Sorry if I don't help, I don't know very much about LSM, but I just want to ask you if:&lt;BR /&gt;&lt;BR /&gt;You run the freezefs before taking the hardware snapshot?&lt;BR /&gt;&lt;BR /&gt;You run the hwmgr after the hardware disk cloning?</description>
      <pubDate>Mon, 23 Oct 2006 09:10:42 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-tru64-unix/problem-with-volclonedg-on-large-volume/m-p/3884843#M17871</guid>
      <dc:creator>Ivan Ferreira</dc:creator>
      <dc:date>2006-10-23T09:10:42Z</dc:date>
    </item>
    <item>
      <title>Re: problem with volclonedg on large volume</title>
      <link>https://community.hpe.com/t5/operating-system-tru64-unix/problem-with-volclonedg-on-large-volume/m-p/3884844#M17872</link>
      <description>Hi Ivan,&lt;BR /&gt;&lt;BR /&gt;We do not a freezefs because we do a pairresync and a pairsplit on XP12000 with unactive advFS domains. &lt;BR /&gt;The hole procedure is made by a script. These are roughly the steps:&lt;BR /&gt; &lt;BR /&gt;1. Stop application on source and target host&lt;BR /&gt;2. Gather fdmns information on targethost&lt;BR /&gt;3. umount all relevant mountpoints on source and target host&lt;BR /&gt;4. Save LSM config with volsave on sourcehost&lt;BR /&gt;5. Deport dg's on targethost&lt;BR /&gt;6. pairresync and pairsplit on XP12000&lt;BR /&gt;7. Mount all filesets on sourcehost&lt;BR /&gt;8. Restore /etc/fdmns entries on targethost&lt;BR /&gt;9. Dg import with volclonedg on targethost&lt;BR /&gt;10. Mount all filesets on targethost&lt;BR /&gt;11. Start application&lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;&lt;BR /&gt;cheers&lt;BR /&gt;Mario Grande&lt;BR /&gt;</description>
      <pubDate>Mon, 23 Oct 2006 09:54:27 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-tru64-unix/problem-with-volclonedg-on-large-volume/m-p/3884844#M17872</guid>
      <dc:creator>Grande Mario</dc:creator>
      <dc:date>2006-10-23T09:54:27Z</dc:date>
    </item>
  </channel>
</rss>

