host rebuild--BOINC transfer
4 Jan 2014 5:07:21 UTC
Topic 197329
(moderation:
First--I'm sure I am asking an often-answered question--so let me apologize, but I did try some searchs. I'd be just as happy for links to answers as actual answers.
I've decided that my most recent host has a flawed boot HD and probably also a flawed motherboard, and perhaps a flawed cache SSD. So I have ordered four new components. In about a week I plan to tear apart the existing host, and do a rebuild with the new and recycled components, including a from scratch Windows 7 install.
But I'll have the previous boot (and only) HD plugged in after the initial build to ease copying of that which does not need a full install process. Across the network I also have a backup on a disk on another machine altogether
I am currently running down the Einstein tasks by greatly reducing the queue, but I'd still like to have the rebuilt machine inherit the designation, history, and work-in-process of the old.
Any practical details on how best to do this I'd appreciate.
My vague current intentions:
1. greatly reduce queue depth a week in advance
2. stop work fetch altogether a day in advance
3. report all work
4. copy current state of c:\ProgramData\BOINC with all subdirectories somewhere safe
5. uninstall BOINC on the "old host"
tear things apart, put things together, install Windows, and give the new host the same Windows name as the old host
0. copy the ProgramData\BOINC tree from my hiding place to the new host boot drive
1. download and install BOINC
2. sign up for Einstein (and SETI as a backup)
3. hope that the new host inherits the old host particulars, and even that some downloaded files and settings will be inherited
The new host will have the same CPU, RAM, and video card as the old, so it would be nifty if all those slow-learned parameters which depend on host execution speed were inherited.
Any advice, criticism, or links to already provided answers would be quite welcome.
host rebuild--BOINC transfer
)
Not necessary, since you won't use "that host" ever again.
That won't be necessary either, since you copied the old data directory. It should even continue to work on any unfinished tasks immediately. Just make sure to direct the BOINC installer to the copied data directory (if it's not at the default location).
Gruß
Gundolf
Computer sind nicht alles im Leben. (Kleiner Scherz)
Wouldn't giving the new
)
Wouldn't giving the new machine the same name and then using merge hosts do what you want?
RE: Wouldn't giving the new
)
Yes I have done that before myself.
It doesn't work on every project but it did work here.
All I did was give the new machine the same name as the one I have unplugged right now.
RE: Any practical details
)
Gundolf has already given the best answer but I'll add some more details. The main problem with merging is that you end up with a new installation, new tasks, and a new host ID. This is all unnecessary when it is trivially easy to have all your old settings and history and work in progress (at whatever stage) transferred directly to the refurbished machine.
When you are ready to start the job, just report any completed tasks and stop BOINC. Don't bother changing cache size or work fetch well in advance. However it is useful to set NNT (just as a precaution) on all active projects just before you pull the plug. I have done this precise exercise many times before and occasionally BOINC seems to think a lot more work is needed immediately after the restart. NNT simply avoids any possibility of over-fetch.
As Gundolf mentions, steps 0 and 1 are all that is necessary. You will already be signed up to all your projects since the account_*.xml files are already present in the saved BOINC Data directory. The state file is there too so all your settings, IDs, etc, will all be incorporated as you run the BOINC installer. As long as you put the data directory back in the correct place, the installer will find it. It's just like you were installing a new version of BOINC 'over the top' of an existing installation. All 'in progress' tasks will be found and will be restarted from their saved checkpoints.
Your wishes will be granted :-).
Cheers,
Gary.
RE: ... As long as you put
)
I fully agree with both Gundolf and Gary. Copying the 'old' data folder to the new drive, and re-introducing it to the new BOINC installation, is all that it needed.
Personally, I like to ferret around in the data directory from time to time, and I find BOINC's default location and properties (hidden) to be inconvenient. So, take control - put the copied folder where you want it to be, and call it what you want. Mine tend to end up as D:\BOINCdata - the data doesn't have to be on the same drive as the BOINC program files.
Then, when you run the BOINC installer for the first time on the new boot drive, click the 'Advanced' button (about three screens in) and tell it where you've put the data. The location will be memorised in the new OS registry, so you won't need to keep changing it if you upgrade to a new version of BOINC later. Once BOINC has access to your old data, processing will restart immediately, with no further configuration needed.
The reborn Stoll7 host is up,
)
The reborn Stoll7 host is up, has the graphics card back in, and came up running Einstein promptly after I rebooted after running the BOINC install.
As it happens, there was a CUDA task already over 97% done, so that finished, uploaded, and with a manual "update" request reported and triggered download of a new task, validated, and got credit, all within the first minutes.
Needless to say, I am grateful for the useful advice I got here.
One point we did not discuss directly was any possible dependence of this technique on BOINC version. So, to be on the safe side, I did my initial BOINC install of the version running on all my hosts, 7.0.64, not the latest and greatest 7.2.33. Plenty of time to upgrade later if indicated.
RE: The reborn Stoll7 host
)
I don't think it would have mattered in the slightest if you'd slipped in a version upgrade, but better safe than sorry.
If you had changed the version, BOINC would have noticed and automatically run the CPU benchmarks as it started up. From your description of the surgery required, I doubt the host has changed speed much, but if you had (for example) slipped in an upgraded CPU, it would have been a good idea to run benchmarks to help the task runtime estimates to settle down again.