ZanDAhaR <allan (at) zandahar.net> wrote on 01/03/2006 03:52:41 p.m.:
> David Pullman wrote:
> > I also had to do the export/import of rrd files when moving from
RHEL4
> > on an i686 to RHEL 4 on a x86_64 processor type.
> >
> > --David
> >
> > Andy France wrote:
> >>
> >> ZanDAhaR wrote on 28/02/2006 06:56:12 p.m.:
> >>
> >> > Hey guys,
> >> >
> >> > Can't seem to find anything on this but then again I haven't gone
> >> > through all the results that come up on the mailing list search
> >> either.
> >> >
> >> > We moved from BB server to a Hobbit server a while ago but it was
> >> on the
> >> > same box so there was no issue there. We are shuffling some old
> >> hardware
> >> > around and decided to give our hobbit server some more grunt
and also
> >> > add some other odd apps on it. We'll want to progrssively move
the
> >> hosts
> >> > over to the new server so the clients are cool, just update
the ip in
> >> > windows ones, and the ip and hostname in the nix ones
> >> >
> >> > As for the server I'm assuming I can just copy the data dir over
> >> for the
> >> > host I'm moving. I cannot imagine there being anything server
> >> specific
> >> > in any of the status messages or graphs ?
> >>
> >> Watch out if you are changing OS/filesystem at all. Existing RRD
> >> files will need to be exported and imported rather copied if this is
> >> the case (I had to do this for a small-ish migration from Solaris
x86
> >> to Solaris Sparc).
> >>
> >> > So action plan would be, shut down client on XYZ, define it in
> >> bb-hosts
> >> > file on NEWHOBBIT, has it out in the OLDHOBBIT bb-hosts file, copy
> >> > appropriate data folders from OLDHOBBIT to NEWHOBBIT (update
> >> ownership
> >> > if need be), update ip addy and hostname in XYZ client settings,
> >> start
> >> > client XYZ, be happy :)
> >> >
> >> > Any flaws in this thinking or suggestions of easier way even
though I
> >> > cannot imagine one can you please let me know
> >> >
> >> > Thanks
> >> >
> >> > Allan
> >> >
> >>
> >> Andy.
> >>
> >>
> >
> > To unsubscribe from the hobbit list, send an e-mail to
> > hobbit-unsubscribe (at) hswn.dk
> >
> Hmm ok I hadnt thought about that as I don't understand the inner
> workings of RRD etc. We're moving from a Pentium Pro 200 box on Redhat
> 7.2 to a Dual Athlon MP System on Redhat 9 (why RH9 you ask, its the
> ONLY supported OS for another application thats going on there and
if we
> hit any problems if its not RH9 they will not help us, poverty I know)
>
> If I do a uname -m they both say i686, uname -p one says unknown other
> says athlon. Should this be an issue ? Also if they are different
enough
> will the graphs just not work or be corrupted or not update ? Can
> someone please assist me in how to import/export the rrd files then
as I
> have never done that before. Been looking in the rrd docs but still not
> entirely sure what I need/want.
>
> The proxy idea sounds good although I don't know if its going to be
> warranted in this case as we don't have a huge number of hosts to
deal with.
>
> Thanks for the feedback guys
>
> Allan
>
> To unsubscribe from the hobbit list, send an e-mail to
> hobbit-unsubscribe (at) hswn.dk
>
>
As the systems are both Linux, are same-endian (i686). and same FS
(ext3?), I can only surmise that you should be able to just copy the
RRD files.
If they are not compatible then the updates will fail as rrdtool will
not be able to read the existing format.
As far as actually converting them goes, I kind of did it on the fly
so don't have any useful scripts to pass on :-) It's pretty easy and
the RRDTOOL website does provide examples
(http://rrdtool.trexle.net/doc/rrddump.en.html)
HTH,
Andy.
#####################################################################################
This email is intended for the person to whom it is addressed
only. If you are not the intended recipient, do not read, copy
or use the contents in any way. The opinions expressed may not
necessarily reflect those of ZESPRI Group of Companies ('ZESPRI').
While every effort has been made to verify the information
contained herein, ZESPRI does not make any representations
as to the accuracy of the information or to the performance
of any data, information or the products mentioned herein.
ZESPRI will not accept liability for any losses, damage or
consequence, however, resulting directly or indirectly from
the use of this e-mail/attachments.
#####################################################################################